Посібник для розробників TEE

Автор: prateek, roshan, сиддхартха & лінгвін (Marlin), krane (Asula)компіляція: Shew, божественний БогRealmX

З моменту оголошення Apple про запуск приватного хмарового сховища та надання NVIDIA конфіденційних обчислень в GPU, довіра виконання середовища (TEE) стала дедалі популярнішою. Їх гарантована конфіденційність допомагає захищати дані користувачів (можливо, включаючи особисті ключі), а ізоляція забезпечує, що виконання програм, розгорнутих на них, не буде піддаватися втручанню - незалежно від того, чи це людина, інші програми чи операційна система. Тому не дивно, що в області Crypto x AI широко використовують TEE для створення продуктів.

Як і будь-яка нова технологія, TEE перебуває в експериментальному етапі оптимізму. Ця стаття сподівається надати основний покажчик концепцій розробникам та загальному читачеві, щоб вони зрозуміли, що таке TEE, модель безпеки TEE, поширені вразливості та найкращі практики безпечного використання TEE. * (Зверніть увагу *: для полегшення зрозуміння тексту ми навмисно замінили терміни TEE на більш прості еквіваленти).

Що таке TEE

TEE - це ізольоване середовище в процесорі або центрі обробки даних, де програми можуть працювати без будь-яких перешкод від інших частин системи. Щоб уникнути втручання інших частин системи в TEE, нам потрібний ряд проектувань, головним чином - суворий контроль доступу, тобто контроль доступу системи до програм та даних внутрішньої пам’яті TEE. Наразі TEE є скрізь - у телефонах, серверах, ПК та хмарному середовищі, тому доступ до нього дуже простий та ціна на нього відповідна.

Зміст вище може звучати неясним і абстрактним, насправді різні сервери та постачальники хмарних послуг реалізовують TEE по-різному, але його основна мета полягає в тому, щоб уникнути втручання інших програм в TEE.

!

Більшість читачів, можливо, використовує біометричну інформацію для входу до пристроїв, наприклад, розблокування смартфона за допомогою відбитка пальця. Але як ми можемо забезпечити так, щоб зловмисні додатки, веб-сайти або операційні системи джейлбрейк не мали доступу до цих біометричних даних та не крадли їх? Насправді, окрім шифрування даних, у пристроях TEE електричні схеми не дозволяють жодній програмі отримувати доступ до області пам’яті та процесора, яку займають чутливі дані.

Апаратний гаманець є ще одним прикладом сценарію використання TEE. Апаратний гаманець підключається до комп’ютера і взаємодіє з ним в пісочниці, але комп’ютер не має прямого доступу до фрази-пароля, яку зберігає апаратний гаманець. У обох випадках користувачі вірять, що виробники пристроїв зможуть правильно розробити мікросхеми і надати відповідне програмне забезпечення для оновлення фірмвару в TEE, щоб запобігти експорту або перегляду конфіденційних даних, що знаходяться в TEE.

Модель безпеки

На жаль, існує багато різних реалізацій TEE, а для цих різних реалізацій (IntelSGX, IntelTDX, AMDSEV, AWSNitroEnclaves, ARMTrustZone) потрібна окрема модель безпеки для моделювання та аналізу. У решті цього документу ми будемо головним чином розглядати IntelSGX, TDX та AWSNitro, оскільки ці системи TEE мають більше користувачів та повноцінні доступні засоби розробки. Ці системи також є найбільш поширеними системами TEE у мережі Web3.

Загалом, робочий процес програм, що розгортаються в TEE, виглядає наступним чином:

1. Розробники написали деякий код, який може бути відкритим або закритим.
2. Після цього розробник упаковує код в файл зображення Enclave (EIF), який може виконуватися в TEE
3. EIF розміщений на сервері з TEE. У деяких випадках розробники можуть безпосередньо використовувати особистий комп’ютер з TEE для хостингу EIF та надання послуг.
4. Користувач може взаємодіяти з додатком через попередньо визначений інтерфейс.

!

Очевидно, тут є 3 потенційні ризики:

• Розробник: На що саме призначений код для підготовки EIF? Код EIF може не відповідати бізнес-логіці, яку проект хоче висвітлювати публічно, і може здійснювати крадіжку конфіденційних даних користувачів
• Сервер: Чи працює TEE-сервер з очікуваним файлом EIF? Або чи дійсно EIF виконується в TEE? На сервері також можуть виконуватися інші програми в TEE
• Постачальник: Чи є безпечним дизайн TEE від TEE? Чи є якісь задні ворота, які можуть витікати всі дані TEE до постачальника?

На щастя, у сучасному TEE вже є рішення для усунення вищезазначених ризиків, а саме репродуктивні збірки(Reproducible Builds) та віддалені атестації(Remote Atteststations).

Так що таке повторне побудова? Сучасний розробка програмного забезпечення часто потребує великої кількості залежностей, таких як зовнішні інструменти, бібліотеки або фреймворки тощо, і ці залежні файли також можуть мати потенційні проблеми. Зараз npm та інші рішення використовують хеш-код коду для залежних файлів як унікальний ідентифікатор. Коли npm помічає, що деякий залежний файл не збігається з записаним хешем, це означає, що файл був змінений.

!

А може бути повторно побудований може бути розглянутий як набір стандартів, мета полягає в тому, щоб будь-який код, який запускається на будь-якому пристрої, мав однакові хеш-значення, якщо будується відповідно до заздалегідь визначеної процедури. Звичайно, в практиці ми також можемо використовувати продукти поза хешем як ідентифікатор, який ми називаємо кодом вимірювання (code measurement).

Nix - це поширений інструмент для повторної побудови. Коли вихідний код програми стає відкритим, будь-хто може перевірити код, щоб переконатися, що розробники не вставили в нього ніякого аномального вмісту, і будь-хто може використовувати Nix для побудови коду та перевірити, чи він має ті самі кодові метрики / хеші, що й продукційний код, що розгортається в середовищі розробки. Але як ми можемо знати кодові метрики програми в TEE? Це пов’язано з поняттям «віддаленого доказу».

!

Віддалене доведення - це підписане повідомлення від платформи TEE (довірена сторона), в якому міститься вимірювання коду програми, версія платформи TEE тощо. Віддалене доведення дозволяє зовнішнім спостерігачам знати, що певна програма виконується в безпечному місці, до якого ніхто не має доступу (справжня версія TEE).

!

Повторне будівництво та віддалене доведення дозволяють будь-якому користувачеві знати фактичний код, який виконується у TEE, і інформацію про версію платформи TEE, що запобігає зловживанням розробників або серверів.

Але у випадку TEE все одно потрібно довіряти їх постачальнику. Якщо постачальник TEE зловживає, він може безпосередньо підробити віддалене підтвердження. Тому, якщо розглядати постачальника як потенційний засіб атаки, слід уникати виключної залежності від TEE, краще поєднувати їх з ZK або протоколом консенсусу.

Чарівність TEE

На нашу думку, особливо популярність TEE, особливо для розгортання AI Agent, передусім полягає в наступних особливостях:

• Продуктивність: TEE може запускати модель LLM, його продуктивність та вартість подібні до звичайних серверів.** ZkML потребує великої обчислювальної потужності для генерації доказу zk LLM.
• Підтримка GPU: NVIDIA надає підтримку обчислення TEE у своїх останніх серіях GPU (Hopper, Blackwell та інші)
• Коректність: LLM є недетермінованим; кілька введень одного і того ж підказкового слова можуть давати різні результати. Тому кілька вузлів (включаючи спостерігачів, які намагаються створити доказ шахрайства) можуть ніколи не збігтися в результаті роботи LLM. У цьому випадку ми можемо довіряти тому, що LLM, що запускається в TEE, не може бути підманутим зловмисником, програми в TEE завжди виконуються відповідно до написаного, це робить TEE більш підходящим для забезпечення надійності результатів розуміння LLM, ніж opML або консенсус
• Конфіденційність: Дані у 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 може виконуватися спарювальний двигун, який обробляє шифровані транзакції, але не забезпечує гарантії справедливого упорядкування (протидія витісненню максимальної вигоди), оскільки маршрутизатор/шлюз/хост все ще може відкидати, затримувати чи пріоритизувати пакети на основі IP-адреси джерела.

архітектурні дефекти

Стек технологій, який використовується в програмі TEE, повинен бути обраним обережно. Під час створення програми TEE можуть виникнути такі проблеми:

• Додатки з великою поверхнею атаки: **** Під поверхнею атак додатків розуміється кількість кодових модулів, які потрібно забезпечити повною безпекою. Код з великою поверхнею атак дуже складно перевірити, і в ньому можуть бути сховані помилки або вразливості. Це зазвичай суперечить досвіду розробників. Наприклад, додатки TEE, які залежать від Docker, мають набагато більшу поверхню для атак, ніж ті, що не підтримують Docker. Порівняно з TEE-додатками, які використовують найлегший операційний систему, Enclaves, що залежать від зрілих операційних систем, мають більшу поверхню для атак
• Портативність та активність: У Web3 додатки повинні бути стійкими до цензури. Будь-хто може запустити TEE і взяти під контроль неактивних учасників системи, зробивши програми в TEE портативними. **Найбільшим викликом тут є портативність ключів. Деякі TEE-системи мають механізми похідних ключів, але якщо використовувати механізми похідних ключів в TEE, то інші сервери не зможуть генерувати ключі внутрішніх програм TEE локально, **що зазвичай обмежує програми TEE до однієї машини, що недостатньо для забезпечення портативності.
• Ненадійний корінь довіри : наприклад, як перевірити, чи належить певна адреса до цього Агента штучного інтелекту, якщо він працює в 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 очікуванням, на основі віддаленого доказу.

Конкретне підтвердження можна здійснити на ланці (IntelSGX, AWSNitro), використовуючи докази ЗК (IntelSGX, AWSNitro) для перевірки поза ланцюжком, або користувач може самостійно перевірити або звернутися до служби хостингу (наприклад, t16z або MarlinHub).

3. Рекомендації, засновані на випадку використання

Залежно від цільового використання та структури додатка, наступні поради можуть допомогти зробити ваш додаток більш безпечним.

Переконайтеся, що взаємодія користувача з TEE завжди відбувається через безпечний канал

Сервер, на якому знаходиться TEE, в суті є ненадійним. Сервер може перехоплювати та змінювати комунікацію. У деяких випадках допустимо, що сервер читає дані, але не змінює їх, тоді як у інших випадках навіть читання даних може бути неприйнятним. Для зменшення цих ризиків важливо встановити безпечний канал з кінця в кінець з шифруванням між користувачем та TEE. Як мінімум, переконайтеся, що повідомлення містить підпис для перевірки його автентичності та джерела. Крім того, користувачі мають завжди перевіряти віддалене підтвердження від TEE, щоб переконатися, що вони спілкуються з правильним TEE. Це забезпечує цілісність та конфіденційність комунікації.

Наприклад, Oyster може підтримувати безпечне видачу TLS за допомогою записів CAA та RFC8657. Крім того, він надає протокол TEE, який називається Scallop, який не залежить від WebPKI.

Знаєте, що пам’ять TEE є митьовою

Пам’ять TEE є тимчасовою, що означає, що при вимкненні TEE її вміст (включаючи шифровані ключі) буде втрачено. Якщо немає безпечного механізму для збереження цієї інформації, важливі дані можуть залишитися недоступними назавжди, що може призвести до фінансових або операційних проблем.

Мережа багатосторонніх обчислень (MPC) з децентралізованою системою зберігання, такою як IPFS, може бути використана як рішення для цієї проблеми. Мережа MPC розбиває ключі на кілька вузлів, забезпечуючи, що жоден окремий вузол не має повного ключа, але при цьому дозволяючи мережі відновлювати ключі при потребі. Дані, зашифровані за допомогою цього ключа, можуть безпечно зберігатися на IPFS.

У разі потреби мережа MPC може надати ключі новому серверу TEE, який працює з тим же зображенням, за умови виконання певних умов. Цей підхід забезпечує гнучкість та потужну безпеку, що дозволяє зберігати доступність та конфіденційність даних навіть в ненадійному середовищі.

!

Існує ще один варіант розв’язання, ** а саме TEE передає відповідні угоди різним серверам MPC, які підписують та об’єднують угоди та остаточно розміщують їх у ланцюжку. Цей метод має набагато меншу гнучкість, його не можна використовувати для зберігання ключів API, паролів або довільних даних (немає довірених сторонніх служб зберігання). **

!

Зменшити атакувальну поверхню

Для важливих випадків використання, варто намагатися якомога більше зменшити зовнішню залежність за рахунок жертви зручності розробника. Наприклад, Dstack поставляється з мінімальним ядром на основі Yocto, в якому містяться лише модулі, необхідні для роботи Dstack. Навіть варто розглянути використання застарілих технологій, таких як SGX (перевищує TDX), оскільки ця технологія не потребує завантажувальної програми або операційної системи в якості частини TEE.

Фізична ізоляція

Через фізичну ізоляцію TEE від можливого втручання людей можна додатково підвищити безпеку TEE. Хоча ми можемо сподіватися на фізичну безпеку, розмістивши TEE-сервери в центрах обробки даних та хмарних провайдерах, проекти, такі як Spacecoin, досліджують цікавий альтернативний варіант - космос. Робота SpaceTEE базується на заходах безпеки, таких як вимірювання інерціального моменту після запуску для перевірки, чи не відхиляються супутники від очікуваного траєкторії під час входу в орбіту.

Багатократний доказувач

Точно так само, як Ethereum залежить від реалізацій кількох клієнтів для зниження ризику помилок, які впливають на всю мережу, multiprovers використовує різні схеми реалізації TEE для підвищення безпеки та еластичності. Шляхом виконання однакових обчислювальних кроків на різних платформах TEE, багатократна перевірка забезпечує, що вразливість в одній реалізації TEE не загрожує всій програмі. Хоча цей підхід вимагає, щоб обчислювальний процес був детермінованим або визначався угодою між різними схемами реалізації TEE в недетермінованих сценаріях, він також надає значні переваги, такі як ізоляція від відмов, зайвість та перехресна перевірка, що робить його відмінним вибором для програм, які вимагають надійності.

!

Погляд у майбутнє

TEE очевидно став дуже захоплюючою галуззю. Як зазначено раніше, широке використання штучного інтелекту та постійний доступ до чутливих даних користувачів означає, що великі технологічні компанії, такі як Apple та NVIDIA, використовують TEE в своїх продуктах та постачають його як частину своїх продуктів.

З іншого боку, криптографічна спільнота завжди надавала велику увагу безпеці. З розширенням розробників додатків та використанням ланцюжків ми бачимо, що Триваюча Обмежена Середовищна Ізоляція (TEE) стає популярним рішенням, що забезпечує належну збалансованість між функціональністю та основними припущеннями про довіру. ** Хоча TEE не мінімізує довіру так, як повний ZK рішення, ми очікуємо, що TEE стане шляхом поступового поєднання продуктів компаній Web3 з великими технологічними компаніями вперше. **