Что большинство разработчиков блокчейна ошибаются в безопасности TEE и конфиденциальности смарт -контракта
2 июля 2025 г.Таблица ссылок
Аннотация и I. Введение
II Тур молнии
Iii. Методология систематизации
IV Раствор слоя-один
V. Slayer-Two Solution
VI Дискуссия
VII. Исследовательские проблемы
VIII. Заключительные замечания и ссылки
Приложение А.Ключевые управления
Приложение B.Анонимность и конфиденциальность
Приложение C.Фон
Приложение D.Протокол голосования на основе TCSC
Iii. Методология систематизации
Чтобы найти общие аспекты (например, предлагаемые функциональности, модель проектирования, модель противника), мы извлекаем повторяющиеся модели проектирования из общедоступных публикаций и проектов, сосредоточив внимание на систематизации и оценке желательных свойств (основная цель TCSC) и потенциальные ловушки базовых систем. Наша методология систематизации следует за идеей в [52]: классификация и оценка. Сначала мы делаем классификацию для текущих систем, а затем определяем структуру для их оценки. Детали представлены, как показано ниже.
А. Системная классификация
Мы классифицируем существующие системы по двум основным категориям: решение Layer-One (L1) и раствор-слоя-второго слоя (L2). Решение Layer-One выполняет контракт внутри футболки в блокчейне, требуя каждого узла блокчейна для оборудования футболки. Вместо этого, решение-решение, решение, выпускает вычисления контрактов из блокчейна. Он выполняет большинство смарт-контрактных вычислений вне цепи. Для четкого понимания мы проводим сравнение исходного блокчейна (например, Ethereum), раствора L1, раствора L2. Как и в tab.ii, Ethereum запускает интеллектуальные контракты (в EVM) и консенсусные процедуры в той же машине распределенных узлов. Все операции по контракту и транзакции публично поддаются проверке из -за их общей прозрачности. Решение Layer-One выполняет такие операции (выполнение контракта и консенсус) на одной и той же машине, но операции по контракту отделены от консенсусных процедур. Напротив, решение-слой-два раствора заставляет обоих их работать независимо. Контракты выполняются за пределами сети блокчейнов, в то время как консенсус происходит внутри каждого узла.
Б. Желательная собственность
В идеале, перемещение выполнения смарт -контракта в Tees обеспечивает дополнительную конфиденциальность, а также поддерживать первоначальные преимущества систем блокчейна. Поэтому мы определили желательные свойства в двух основных категориях:Содержание конфиденциальностииблокчейнвнутреннийособенностьПолем
Содержание конфиденциальности.Свойство конфиденциальности является наиболее выдающейся особенностью в TCSC.
А1. Спецификация скрыта.Исходный код смарт -контракта скрыт во время развертывания и последующей синхронизации и выполнения.
A2 Входная конфиденциальность.Входные данные, прикрепленные к конфиденциальному интеллектуальному контракту, скрыты от общественности.
A3. Вывода конфиденциальность.Выходы, возвращаемые из конфиденциального интеллектуального контракта, должны быть частными.
A4 Процедура конфиденциальность.Процедура выполнения скрыта от несанкционированных сторон. Служба не может выучить знания операции внутри футболки.
A5. Адресовать неофорпимость.Адрес псевдонимичность не влечет за собой сильные гарантии конфиденциальности [53], [54]. Это свойство не позволяет противнику изучить адресализацию адреса, наблюдая за действиями пользователей.
A6 Адресовать анонимность.Личность абонента контракта (пользователь, который вызывает умный контракт) скрыт от набора анонимности [24] (см. Приложение B).
Блокчейн внутренняя особенность.Смарт-контракты с использованием TEE Унаследованы функции, приведенные оригинальными системами блокчейна. Мы суммируем эти функции следующим образом.
A7 Код неизменность.Как только контракт будет успешно развернут, его исходный код не может быть изменен.
A8. (Конфиденциальная) согласованность состояния.Выполнения, происходящие на определенной высоте блокчейна, выведут один и тот же результат на разных узлах.
A9 Контрактная совместимость.Умный контракт может позвонить в другой контракт и быть вызванным другими.
A10. Высокая доступность.Умный контракт непрерывно доступен без единой точки отказа.
A11. Децентрализованное исполнение.Умный контракт работает по децентрализованной сети.
A12. Автоматическое выполнение.Умный контракт может быть автоматически выполнен после удовлетворения условий.
A13. Газовый механизм.Операции, работающие по смарт -контракту, будут взиматься с платы за газ [2].
A14. Явный вызов.Каждый вызов будет отформатирован как транзакция и храниться на блокчейне.
A15. Публичная проверка.Процедура исполнения и результата контракта общедоступна.
A16. Консенсус -проверка.Консенсусная процедура в (конфиденциальном) государстве публично проверяется.
C. Оценка системы
По сути, все системы TCSC имеют один и тот же принцип:TEE будет обрабатывать данные от пользователей.После этого зашифрованные потоки данных изФутболка для блокчейна.АTEE играет решающую роль.Таким образом, эта часть определяет структуру для оценки базовых систем блокчейна из четырех аспектов:Хозяин футболка, Security,TEE -программа, иУПРАВЛЕНИЕ КЛЮЧ.Эта структура направлена на то, чтобы определить потенциальные недостатки дизайна и подводные камни на основе модели угроз и рабочего процесса данных.
Модель угроз.Наша модель угроз в основном фиксирует три типа злоумышленников, которые указаны следующим образом.
T1. Пользовательский противник (активный/пассивный).Злоумышленник может управлять сетью между пользователями и узлами хоста TEE.
T2. Борьба с футболкой (активный/пассивный).Противник может управлять хостами TEE или управлять сетью между платформами TEE и Blockchain.
T3. Блокчейн противник (активный/пассивный).Противник может отбросить, изменять и задержать сообщения блокчейна. Но большинство (или две трети) узлов блокчейна считаются честными.
Обратите внимание, что противники не обязательно являются исключительными. В некоторых случаях противники в разных типах могут сговориться.
Соображения безопасности.В этом разделе определяется четыре метрики, касающиеся безопасности системы в соответствии с рабочим процессом данных: подходы к повышению безопасности хоста TEE, контрмеры для смягчения внутренних проблем TEE, методов предотвращения недостатков программы или ошибок внутри TEE и решений для очистки дилеммы безопасности ключей TEE.
Tee Host Security.TEE и ее взаимодействие с внешней средой (например, с пользователями или блокчейном) эксплуатируются и контролируются хостом (например, узлом блокчейна L1). У злонамеренного хозяина есть способности прервать выполнение тройника, задержать и изменять входные данные или даже отбросить любые индивидуальные или исходящие сообщения. Следующие показатели обсуждают подходы к повышению безопасности хозяина TEE.
П1 Механизм наказания хозяина.Штрафные механизмы, чтобы уменьшить риск совершения зла с помощью хозяина.
П2 Механизм стимулирования хозяина.Стимулирующие механизмы для продвижения хозяина тройника вести себя честно.
P3. Устойчивость к разлому хозяина.Решения, направленные на то, чтобы система постоянно работала, несмотря на неисправности или сбои.
П.4 Аутентификация хоста.Методы проверки идентичности и возможности хоста TEE.
Сигона.У футболки неизбежные слабости. Например, футболка уязвима для атак по боковым каналам [55], [56]. Эти врожденные слабости непосредственно создают серьезные проблемы для проектирования и реализации контрактных систем с помощью TEE. Эта часть определяет подходы защиты от этих угроз.
P5 Tee Attestation Security.Методы предотвращения аттестации TEE не были нарушенными.
P6 Ограничение памяти футболки.Методы оптимизации размера памяти, чтобы предотвратить переполнение конфиденциальных данных.
P7. Ти -физические атаки.Подходы к предотвращению физических атак, таких как уязвимость призрака или уязвимость крида [57].
P8 Tee Relyed Timer.Подходы к предоставлению доверенного таймера при запуске футболки.
See Program Security.Даже футболка безопасна, как предполагалось, программная ошибка может разрушить конфиденциальность контракта в реальном мире. Эта часть фокусируется на измерениях, чтобы предотвратить недостатки или ошибки TEE.
P9 Измерение рабочей нагрузки.Подход измерения рабочей нагрузки для предотвращения атаки бесконечной петли.
P10. Обнаружение недостатков.Формальные методы, используемые для моделирования и проверки исходного кода интеллектуальных контрактов для снижения уязвимостей.
P11. Ограничение пользователя.Ограничение на запросы пользователей, направленное на то, чтобы избежать утечки данных в результате анализа дифференциальнойриальности [58].
P12. Подтверждение данных блокчейна.Методы для тройника проверили, были ли подтверждены входные данные из блокчейна, чтобы предотвратить атаку отката [59].
P13. TEE Вывод конфликты.Методы, чтобы избежать нескольких футболок для получения результата конфликта.
TEE Key Security.Различные ключи (ср. Приложение A) участвуют в выполнении контракта, включая внутренние ключи TEE, такие как клавиши аттестации и ключи службы TEE для шифрования/дешифрования штата. Поскольку клавиши обслуживания напрямую влияют на защиту состояний контракта, ключевая оценка безопасности в этом SOK в основном фокусируется на генерации, обмене и хранении ключа обслуживания TEE.
P14. Распределенный ключевой протокол.Ключи конфиденциальных контрактов управляются распределенным протоколом.
P15. Протокол поворота ключа.TEE заменяет старый ключ со свежим ключом для будущего шифрования контракта.
P16. Независимый контракт ключ.Каждый контракт связан с уникальным ключом, независимым от футболки.
P17. Независимый ключ.Каждая футболка имеет уникальный ключ, и разные контракты имеют один и тот же ключ.
Краткое изложение систематизации.АСистемная классификацияПоказывает общий вид систем TCSC. Желательная собственность фокусируется на оценке контрактной службы, предоставляемой системой блокчейна с помощью TEE.Модель угрозописывает потенциальные угрозы и системы системы.Соображения безопасностиПокажите оценку индикатора для современных систем с помощью TEE. В следующем разделе IV-B и V-B мы пытаемся ответить на следующие вопросы: (i) Каковы потенциальные ловушки в каждом аспекте безопасности; (ii) оказывают ли эти ловушки значительные воздействия на безопасность; (iii) разработчики/разработчики рассматривают эти ловушки и, соответственно, создают возможные средства правовой защиты в своих системах; (iv) Каковы средства правовой защиты и они решают задачи. Обратите внимание, что сотни систем TCSC были предложены как в отрасли, так и в научных кругах. Исчерпывающий анализ нежелательный и невозможный. Мы выбрали только проекты, которые предоставляют общедоступные технические отчеты или академические документы.
Авторы:
(1) Руджия Ли, Южный университет науки и технологии, Китай, Университет Бирмингема, Великобритания и этот автор внес свой вклад в эту работу;
(2) Цинь Ван, CSIRO DATA61, Australia и этот автор внес свой вклад в эту работу;
(3) Ци Ван, Южный университет науки и техники, Китай;
(4) Дэвид Галиндо, Университет Бирмингема, Великобритания;
(5) Марк Райан, Университет Бирмингема, Великобритания.
Эта статья есть
Оригинал