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

Ці системи можуть забезпечити апаратний рівень безпеки для повсякденних пристроїв та інтегрувати методи аутентифікації Web2 в середовища Web3, дозволяючи нам вийти за рамки традиційних 12-словних фраз-насінь. Сьогодні я поясню різні системи управління ключами, якими розробники можуть користуватися, а також конкретні випадки використання, де вони найбільш корисні.

Переміщуючись за межі 12 слів

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

Без абстракції облікового запису (AA) більшість існуючих рішень ґрунтуються на багатосторонній обчислювальній операції (MPC), щоб розподілити ключі на кілька частин та створити поріг для здійснення транзакцій. Ці рішення часто стверджують, що вони самостійно зберігаються. Однак це не цілком точно. Наприклад, Binance зберігає одну частину ключа, діючи як кастодіан у випадку, якщо користувачі втратять свої пристрої. Ця конфігурація означає, що, незважаючи на заяви, користувачі не мають повного контролю над своїми ключами, і все ще існує залежність від централізованої сутності для відновлення ключа.

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

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

1. Повністю програмовані рахунки: абстракція рахунків

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

З AA кошти зберігаються в розумних контрактах, а власність на рахунку визначається цими розумними контрактами. Рахунки, сумісні з EIP-4337, мають дві частини у своїх транзакціях.

1. Перша частина – це верифікація, коли право власності на обліковий запис підтверджується он-чейн.
2. Друга частина - виконання, яке виконує повідомлення.

Обидва компоненти є повністю програмованими; наприклад, ви можете визначити два ключі (i, ii), і перший ключ (i) може виконувати негайні транзакції, тоді як другий ключ (ii) може виконувати транзакції лише після часового блокування. Це означає, що ми можемо визначити потужність ключів, додати часове блокування або дозволити інші умови для виконання транзакції.

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

У криптопросторі існує багато методів аутентифікації (тобто систем керування ключами), які можуть увімкнути схеми контролю доступу на основі ролей, і використання лише одного ключа не може вирішити всі проблеми, пов'язані з керуванням ключами. Найважливішими аспектами систем керування ключами є: де зберігається ключ і хто його автентифікує.

Переваги та недоліки різних систем управління ключами

Я коротко підсумую ключі доступу (Consumer Secure Enclaves), рішення на основі MPC, хмарні рішення TEE, кастодіальні рішення, традиційні 12 слів і сесійні ключі. Після цього пояснимо кращі комбінації.

1. Традиційні 12 слів - (secp256k1) -

Біткойн та Ефір підтримують secp256k1Алгоритм еліптичної кривої криптографії (ECC) для створення приватних ключів та зберігання їх на пристроях користувачів. Цей метод широко використовується в EOAs і також може бути застосований дорозумні рахунки. Щоб його використовувати, додаток гаманця генерує приватний ключ за допомогою алгоритму випадкового генерування ключа, а потім зберігає приватний ключ у спільному сховищі.

Використання secp256k1 має кілька переваг: воно не спричиняє додаткових витрат газу, є недорогим і легким у перевірці на ланцюгу через попереднє обчислення ecrecover. Воно також самостійне, оскільки лише користувач може отримати доступ до ключа.

Проте є деякі недоліки:

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

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

2. Парольные ключи (безпечні області споживачів)

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

Розробники створили спеціальний мікрочіп під назвою Secure Enclave для управління цими конфіденційними операціями окремо. Secure Enclave функціонує подібно до апаратного гаманця; Він працює незалежно, безпечно обробляючи конфіденційні дані, і навіть власник пристрою не може отримати доступ до його вмісту. На щастя, Secure Enclave підтримує криптографічні операції, такі як створення приватних ключів і підписання ними повідомлень. На жаль, Secure Enclave не підтримує криву, яку підтримує Ethereum (secp256k1), натомість він підтримує криву p256. Щоб увімкнути нативну перевірку P256, ми (@getclave"">@getclave команда) запропонувала РІП-7212і майже всі великі ролапи тепер підтримують його.

І найкраща частина про Secure Enclaves полягає в тому, що ми можемо створити приватний ключ всередині Secure Enclaves лише з біометричною аутентифікацією, що забезпечує одноразовий досвід з включення за допомогою найкращої доступної безпеки на сучасних пристроях - на рівні апаратного забезпечення. Але вона також має деякі недоліки:

• Верифікація P256 без RIP-7212 є дорогим та збільшує ризик помилок.
• Оскільки ключ не може бути вилучений, тут відсутня можливість відновлення (Passkeys дозволяє обмежену відновлюваність, але цього недостатньо)
• Якщо веб-домен ключа, або додаток Secure Enclave (SE) перестає працювати, користувачі не можуть отримати доступ до приватного ключа, оскільки Secure Enclave розроблений для ізоляції та незалежності. Без відповідного додатка або веб-домену немає способу отримати або взаємодіяти з приватним ключем, що залишає користувачів не в змозі виконувати необхідні криптографічні операції. - Я поясню, як вирішити цю проблему.

3. Рішення з управління ключами на основі SSS

SSS (Shamir's Secret Sharing) розв'язки створюють спосіб усунути одну точку відмови, яку мають традиційні системи управління ключами. Вони, по суті, розбивають ключі на різні частини і встановлюють поріг для доступу до ключа. Розподіляючи ці частини, SSS забезпечує, що жодна окрема сутність не має повного ключа, тим самим підвищуючи безпеку.

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

Таким чином, користувачі делегують управління своїм гаманцем іншим сторонам з кворумом. MPC (Multi-Party Computation) дуже потужний для делегування відповідальності з управління ключами різним сторонам, але він також має деякі недоліки:

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

Ще одним важливим недоліком SSS є те, що він відновлює приватний ключ, зазвичай у браузері. Це великий ризик безпеки, коли текстовий ключ доступний на стороні клієнта. TSS ніколи не відновлює ключ і використовує MPC для федерування підпису через ключові частки.

4. Хмарні рішення TEE

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

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

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

Хмарні TEE виглядають перспективно в теорії, але в минулому ми бачили вразливості, такі як sgx.failв хмарних TEEs. Однак перевага TEEs полягає в тому, що навіть якщо є таємний вхід або вразливість, зловмиснику знадобиться фізичний доступ до TEE, тому апаратне забезпечення споживача (Secure Enclave - Passkeys) настільки потужне, оскільки апаратне забезпечення споживача зберігає ключ всередині Secure Enclave користувачів, і тільки власник може отримати доступ до ключа, тоді як Cloud TEE зберігає ключі всередині хмари, що робить його вразливим до атак.

Не ваша безпечна локація, не ваші монети.

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

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

Session Keys: новий спосіб надання обмежених дозволів

Ми вже говорили про постійні ключі. Що, якщо ми зможемо згенерувати тимчасовий ключ, який має обмежений доступ до активів і зникає через деякий час, який вирішить користувач? Session Key дозволяє нам це зробити:

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

Як і в світі Web3, ми визначаємо ключі сеансу як фреймворк, який потенційно може змінити спосіб взаємодії користувачів з додатками. Метою ключів сеансу є дозвіл користувачам встановлювати попередні схвалення на певний час в різних сценаріях та робити транзакції без підпису. Але як це працює?

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

Найкращі комбінації аутентифікації та управління ключами для різних використань

Я пояснив різні системи управління ключами та їхні переваги та недоліки. За допомогою AA ми можемо поєднати ці системи управління ключами та створити потужні структури з мінімальними компромісами. Давайте пояснимо це C.1) Passkey + відновлення з встановленою часовою блокадою - Clave - фінтех-додаток, який зберігає цінні кошти.

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

Існує кілька варіантів відновлення, таких як соціальне відновлення, універсальне відновлення (на основі ZK-Email) та відновлення на основі MPC. Однак, на мою думку, для фінтех-додатка, який призначений для повного самостійного зберігання, соціальне відновлення вирішує більшість проблем. У Clave ми створили модуль соціального відновлення і працюємо над Універсальним відновленням.

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

Неналежні фінансові застосунки, такі як соціальні-Fi-застосунки та децентралізовані ігри, потребують простішого способу проведення транзакцій, ідеально - без необхідності підписувати кожну транзакцію користувачами. Як? От тут є відповідь:

1. Passkey + відновлення з таймлоком + ключі сеансу — мобільний соціальний додаток

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

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

Ключі сесії є кращою альтернативою цьому. Користувачі можуть перевірити, як довго буде активною сесія і до яких активів може мати доступ сесія, що зменшує потребу довіряти додатку. Після закінчення часу сесії користувачам не потрібно хвилюватися про схвалення = Більше не потрібновідкликати готівкуподобаються додатки :)

2. Підписувач на основі MPC або хмарної TEE + самокерований підписувач для втечі

Недоліком MPC або шарів управління ключами сторонніх осіб на основі Cloud TEE є те, що більшість з них не є самостійними та мають значні централізовані компоненти. Однак деякі додатки вимагають вбудованих гаманців без додаткових витрат на газ, що вимагає рішень на основі MPC або Cloud TEE. Додавання додаткового підписанта для «різкого виходу» може вирішити проблему цензури, яку мають ці системи управління ключами, а також пом'якшити потенційні правові проблеми, з якими можуть стикнутися ці додатки. Потрібен розумний гаманець, щоб побудувати це, оскільки обертання ключа неможливе з ОЕЗ.

Вже є кілька додатків, які використовують цю архітектуру управління ключами.

3. 12 слів + апаратний підписник для максимізації безпеки - Децентралізований браузерний додаток для дослідження додатків

Користувачі DeFi полюбляють досвід розширення браузера, а зміна поведінки користувача - одна з найскладніших речей у сучасному світі. Так чому б не побудувати кращу альтернативу? Поєднання апаратного підписувача (Secure Enclave або Passkey Signer) з 12-слівними фразами доступними через розширення також може вирішити проблему витоку особистих ключів. Цей підхід покращує безпеку, не потребуючи зміни поведінки користувачів. Кілька команд у сфері AA працюють над цим. (наприклад.@myBraavos)

Розумні рахунки не настільки розумні

Уявіть, що ви є користувачем, який спочатку створив EOA з @MetaMaskа потім виявив альтернативу, наприклад Zerion. Ви вирішуєте використовувати@zerion, і все, що вам потрібно зробити, це імпортувати свою фразу-насіння — просто. Тепер уявіть, що ви намагаєтеся зробити те саме на Starknet, де всі гаманці є смарт-рахунками. Ви не можете, оскільки Braavos та Argent не сумісні. Ця проблема також існує в екосистемі EIP-4337 та@zkSyncрідний AA.

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

Додатково, «виходи з політики злості» повинні бути стандартною функцією, оскільки центральні учасники в майже всіх системах управління ключами можуть бути вимкнені. Користувачам повинно бути легше змінювати підписанти або перемикати розумні контракти, а самохостинг повинен бути стандартним варіантом для користувачів. Існує два модульних стандарти розумного облікового запису: ERC-6900 та ERC-7579. Обидва намагаються досягти подібної мети - зробити розумні облікові записи розумнішими.

Особлива подякаДерек ,Конрад, іNoamза відгуками та коментарями!

Disclaimer:

1. Цю статтю було перепубліковано з [X]. Усі авторські права належать оригінальному автору [2077Дослідження]. Якщо є заперечення проти цього передруку, будь ласка, зв'яжіться з Навчання Gateкоманда, і вони швидко займуться цим.
2. Відмова відповідальності за зобов'язання: Погляди та думки, висловлені в цій статті, належать виключно автору і не є інвестиційними порадами.
3. Команда Gate Learn перекладала статтю на інші мови. Копіювання, поширення або плагіат перекладених статей заборонено, якщо не зазначено інше.