Вирішення проблем управління ключами Nostr - Журнал Bitcoin - Криптіх

Це редакційна стаття Шінобі, педагога-самоучки в сфері біткойн і ведучого подкастів біткойн, орієнтованого на технології.

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

Як я обговорював у попередній статті, пари відкритих/приватних ключів користувача є невід’ємною частиною того, як Nostr працює як протокол. Немає імен користувачів або будь-яких типів ідентифікаторів, якими керує сервер ретрансляції, які можна пов’язувати з окремими користувачами. Це просто ті ключі користувачів, які повністю під їхнім контролем.

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

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

Як ти з цим справляєшся? Просто перевірте їхній обліковий запис у Twitter? Ну, тоді це не дуже децентралізована система, зрештою, якщо вам потрібно використовувати централізовану платформу, де вони не контролюють свою особу, щоб підтвердити свою особу Nostr.

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

Nostr потребує справжньої криптографічної схеми, яка пов’язує обертання одного ключа з іншим. Є пропозиція від забудовника fiatjaf для базової схеми, яка потенційно може вирішити цю проблему. Основна ідея полягала б у тому, щоб взяти довгий набір адрес, отриманих з одного головного початкового числа, і створити набір «налаштованих» ключів, подібних до того, як дерева Taproot прикріплюються до ключа Bitcoin. Taproot бере корінь дерева Merkle дерева Taproot і «додає» його до відкритого ключа, щоб створити новий відкритий ключ. Це можна відтворити, додавши корінь дерева Merkle до закритого ключа, щоб отримати відповідний закритий ключ для нового відкритого ключа. Ідея Fiatjaf полягає в тому, щоб зв’язати зобов’язання в зворотному порядку від кінця до початку, щоб кожен налаштований ключ фактично містив доказ того, що для його створення використовувався наступний налаштований ключ.

Отже, уявіть, що починається з ключа Z, останнього в ланцюжку. Ви можете налаштувати це за допомогою чогось, а потім повернутися назад і створити налаштовану версію ключа Y за допомогою налаштованого ключа Z (Z’ + Y = Y’). Звідси ви візьмете Y’, а потім використаєте його для налаштування X (Y’ + X = X’). Ви повинні зробити це аж до клавіші A, щоб отримати A’, і звідти почати використовувати цю клавішу. Коли його зламано, користувач може транслювати подію, що містить неналаштований ключ A і налаштований ключ B’. Він містив би всі дані, необхідні для того, щоб показати, що B’ використовувався для створення A’, і користувачі могли б негайно припинити стежити за A’ і натомість слідкувати за B’. Вони точно знають, що B’ є наступним ключем цього користувача, і натомість слідують цьому.

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

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

Щоб трохи розповісти про потенційні рішення тут, уявіть замість ланцюжка налаштованих ключів, як він пропонує, що ключ налаштований головним холодним ключем, який також потрібно використовувати для підпису події, що обертається від одного ключа до іншого. У вас є ключ A’, який отримано шляхом додавання A і M (головний ключ), а подія обертання буде A, M і B’ (генерується шляхом додавання B і M) із підписом від M. M може бути пороговий ключ multisig — два з трьох, три з п’яти тощо. Це потенційно може додати надлишковість від втрати, а також забезпечити безпечний механізм для ротації ключів. Це також відкриває двері для використання служб для допомоги у відновленні або розповсюдження деяких із цих ключів серед довірених друзів. Він пропонує таку саму гнучкість, як multisig із самим біткойном.

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

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

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

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

Це гостьовий пост від Shinobi. Висловлені думки повністю належать їм і не обов’язково збігаються з думками BTC Inc або Bitcoin Magazine.

Source link