Що потрібно знати: |
- Miniscript дає змогу створювати програмні гаманці Bitcoin, які унеможливлюють використання бекдорів. Ми раді повідомити, що Ledger є першим виробником комерційного апаратного гаманця, який підтримує мініскрипт.
- Додаткові функції можна реалізувати без шкоди для взаємодії з користувачем. |
Апаратні пристрої для підпису розроблено для захисту користувача від різних поширених векторів атак, як-от:
- Несанкціонований доступ і вилучення насіння
- Зловмисне програмне забезпечення, що заражає пов’язаний гаманець програмного забезпечення
- Уразливості програмного забезпечення на самому пристрої
Як і в будь-якому іншому бізнесі, в інтересах виробника створювати пристрої як непорушний як можуть. Успіх у цій місії має першочергове значення, і охоронні компанії, такі як Ledger, покладаються на репутацію, сформовану завдяки їх досвіду.
Однак у деяких користувачів все ще можуть виникнути занепокоєння. Що заважає самій компанії приховати a закулісний в пристроях?
У самоохороні ми не довіряй, ми перевіряємо.
Але може користувач насправді перевірити, чи пристрій не має бекдору?
Це ключове питання, яке розглядає ця стаття. Точніше, ця стаття стосується наступних тем:
- що таке бекдор, і чому важко, якщо не неможливо, довести, що його немає;
- чому тільки користувачі можуть захистити себе від цього ризику;
- як miniscript дозволяє практичні рішення цієї проблеми для біткойн-гаманців.
Будучи першим апаратним гаманцем з підтримкою мініскрипт, ми сподіваємось надихнути розробників створювати безпечні рішення та оновлювати всю нашу галузь, а також усунути ймовірність того, що такий системний ризик коли-небудь з’явиться.
Як побудувати unbackdoorable підписуючий пристрій
Скажемо чітко: не можна.
Щоб захиститися від потенційного бекдору, вам потрібна модель атаки, відмінна від тієї, яку ми окреслили вище: у цьому сценарії супротивником може бути сам постачальник або пошкоджений інсайдер.
Часто рекламоване рішення цієї проблеми — це відкрите кодове джерело: зрештою, якщо ви можете перевірити код, що може піти не так?
Однак правда складніша. Оскільки постачальник збирає обладнання, бекдор може повністю міститися в ньому. Апаратне забезпечення може бути розроблено таким чином, щоб у певних моментах ігнорувати програмне забезпечення та замість цього виконувати шкідливий код.
На відміну від програмного забезпечення, яке працює на обчислювальних пристроях загального призначення (наприклад, на вашому ноутбуці чи телефоні), у сучасних технологіях практично неможливо перевірити апаратне забезпечення. Навіть якби специфікації апаратного забезпечення були повністю відкритими, разом із деталями кожного окремого вентиля в схемі, вам все одно знадобилося б дороге обладнання, щоб перевірити, чи конкретна мікросхема побудована відповідно до них.
Як зробити бекдор апаратного гаманця
Ось кілька найпростіших методів, які постачальник зловмисного обладнання може використовувати для впровадження бекдору, а також деякі способи, якими досвідчені користувачі можуть захистити себе сьогодні.
Генерація насіння
Багато пристроїв пропонують вам можливість генерувати насіння (також називається Секретна фраза відновлення) безпосередньо на пристрої за допомогою a Справжній генератор випадкових чисел.
😈 Злий пристрій може генерувати насіння, які здаються випадковими, але насправді передбачуваними для зловмисника.
🛡️ Досвідчені користувачі можуть обійти цю проблему, згенерувавши мнемоніку офлайн. Крім того, включає міцний парольна фраза також може генерувати повністю незалежне початкове число, яке постачальник обладнання не може передбачити. Компроміс полягає в тому, що користувачі повинні забезпечити належне резервне копіювання парольної фрази на додаток до мнемонічних слів.
Виведення відкритого ключа
Апаратні гаманці отримують і експортують відкриті ключі (також називається xpubs, скорочено розширений відкритий ключ як визначено в БІП-32, xpubs використовуються для створення можливих адрес для отримання монет.
😈 Злий пристрій може повернути відкритий ключ, яким керує зловмисник, замість правильних, отриманих із насіння.
🛡️ Користувачі можуть перевірити отримане xpub на іншому автономному пристрої. Однак введення початкового коду на інших пристроях пов’язане з власними ризиками. Користувачі, які обізнані з безпекою, можуть вважати будь-який пристрій, який отримав доступ до насіннєвого коду, небезпечним, аж до його знищення. Типовому користувачеві може бути важко правильно виконати цю процедуру, керуючи додатковими ризиками.
Витік інформації
An повітряний проміжок часто пропонується як рішення для запобігання викраданню приватних ключів зловмисним або скомпрометованим пристроєм. Зрештою, якщо пристрій не може спілкуватися із зовнішнім світом, він не може зробити нічого шкідливого, чи не так?
Не зовсім!
Пристрій може завжди спілкуватися, коли він використовується: він створює підписи. Ці підписи потрапляють у транзакції, які транслюються та назавжди зберігаються в блокчейні.
Підпис — це довільний рядок байтів довжиною щонайменше 64 байти. Однак, оскільки одному повідомленню може відповідати більше ніж один дійсний підпис, шкідливий пристрій може передавати кілька бітів інформації щоразу, коли створюється підпис, створюючи кілька підписів і вибірково вибираючи, які публікувати.
😈 Підроблений пристрій може створювати невипадкові підписи, які під час багатьох транзакцій розкривають зловмиснику зерно!
Зловмиснику, який успішно встановив такий бекдор, доведеться просто чекати, поки зловмисні сигнатури з’являться в блокчейні, поки вони не отримають достатньо інформації для реконструкції всього початкового коду.
🛡️ Для підписів ECDSA, використовуючи стандартизований метод детермінованого виведення nonce (наприклад, RFC6979) запобігає цій атаці, за умови перевірки того, що отриманий підпис відповідає очікуваному. Однак, щоб переконатися, що це так, потрібно завантажити другий пристрій тим самим насінням, що призводить до тих самих практичних проблем, згаданих у попередньому розділі.
🛡️ Цікавим підходом є використання розумного способу змусити пристрій фактично вибирає випадковий одноразовий номер. Протокол для цієї мети, відомий як антиексфіл or антиклепто, зараз реалізовано в апаратних гаманцях Blockstream Jade і ShiftCrypto BitBox02. Докладніше на Блог ShiftCrypto, який також містить технічний опис того, як може бути виконана така атака.
Добре, тоді немає надії?
Більшість засобів захисту🛡️, перелічених вище, здебільшого вимагають від користувача виконання явних, нав’язливих дій, щоб захистити себе: або самостійно генеруючи початковий код (по суті, використовуючи свій мозок, щоб замінити функціональні можливості апаратного гаманця), або використовуючи додатковий пристрій для перевірки правильності виконання обчислень.
Однак протокол anti-exfil виділяється: враховуючи, що завжди є машина, яка є посередником між апаратним забезпеченням, що підписує, та зовнішнім світом, ця машина може допомогти. Завдяки інтерактивному протоколу з апаратним підписувачем він може примусове виконання використання справді випадкового nonce, тим самим зменшуючи або усуваючи ймовірність значного маніпулювання остаточним підписом.
У цьому дописі в блозі ми насамперед зацікавлені в цих типах заходів: хоча стратегії, які значно погіршують UX, можуть бути привабливими для досвідчених користувачів, вони, ймовірно, зроблять щось гірше на практиці для менш технічно досвідчених користувачів − яких є переважна більшість.
Модель безпеки
Стандартна модель для апаратних підписувачів
Виробники апаратного підпису прагнуть захистити користувачів від різноманітних потенційних загроз (докладніше див Модель загрози). У цій статті ми зосередимося на одній дуже важливій властивості, яку можна підсумувати таким чином:
Користувачі не можуть бути введені в оману для дії, яка призведе до втрати коштів, якщо вони розуміють і перевіряють інформацію на екрані до схвалення.
Схвалення потрібне для будь-якої конфіденційної дії, зокрема для підписів. Захист початкового коду був би марним, якщо б зловмисне програмне забезпечення могло виробляти підписи для довільних повідомлень, таких як транзакція, що виснажує всі кошти!
Важливо підкреслити, що наведена вище властивість має бути істинною, навіть якщо програмний гаманець повністю скомпрометовано. Те, що відображається на екрані вашого ноутбука/телефону, не можна довіряти: зловмисне програмне забезпечення може замінити адреси, ввести вас в оману щодо ваших адрес, представити транзакцію, але потім переслати іншу на пристрій для підписання тощо.
Таким чином, вбудоване програмне забезпечення та програми, що працюють на апаратному пристрої підпису, за своєю суттю враховують програмний гаманець ненадійний і не заслуговує довіри.
Модель захисту від бекдорів для програмних гаманців
У цьому розділі ми повністю міняємо ролі. Тепер ми хочемо спроектувати a програмний гаманець що перешкоджає виробнику обладнання від крадіжки або спричинення втрати коштів, навіть якщо пристрій повністю шкідливий.
Отже, це не може бути властивістю пристрій: скоріше, це властивість програмний гаманець налаштування. Ми могли б узагальнити це так:
За умови, що програмний гаманець не скомпрометовано, виробник апаратного забезпечення не може спричинити втрату коштів користувачем.
Це може здатися нелогічним, оскільки прямо суперечить стандартній моделі безпеки, описаній вище. Однак «не мати бекдору» означає «робити саме те, що вони повинні робити». Оскільки програмний гаманець є єдиний інтерфейс між пристроєм підпису та зовнішнім світом, це єдине місце, де можна застосувати захист від неналежної поведінки – чи то через помилку, чи через явну компрометацію пристрою.
Зауважте, що ця модель значно розширюється за межі збою пристрою, наприклад помилки, які можна використовувати. У цьому випадку ми працюємо за сценарієм, коли пристрій активно намагається спричинити втрату коштів.
Звичайно, неможливо захистити, якщо виробник успішно зламав обидва пристрій, а також вашу машину, на якій працює програмний гаманець. Тому надзвичайно важливо переконатися, що ваш програмний гаманець має відкритий вихідний код і підлягає перевірці, особливо якщо він створений тим же постачальником, що виробляє апаратне забезпечення.
Роль мініскрипту
Miniscript надає розробникам гаманців можливість повною мірою використовувати розширені функції Bitcoin Script. Щоб отримати огляд неймовірних можливостей розблокування мініскрипту, зверніться до наш попередній допис у блозі. Ви також можете послухати Епізод 452 подкасту Стефана Лівери для обговорення того, що мініскрипт привносить у ландшафт біткойнів.
Додаток Ledger Bitcoin підтримує мініскрипт з моменту випуску 2.1.0, який було розгорнуто в лютому 2023 року. На конференції Bitcoin 2023 у Маямі Wizardsardine оголосив про випуск 1.0 свого Гаманець Ліана, перший розгорнутий гаманець на основі мініскрипту.
Основна ідея цієї публікації полягає в тому, що обліковий запис біткойн-гаманця можна захистити не лише за допомогою одного, а за допомогою множинний ключі. Це дозволяє створювати гнучкі системи безпеки, де навіть повний збій або компрометація ключа не є катастрофічними.
Мультисиг роздуми
Multisig — це значне вдосконалення рішення для самоохорони. Використовуючи можливості програмування Bitcoin Script, він дає змогу створювати гаманці, які вимагають кількох ключів замість одного. А k-з-n multisig гаманець вимагає комбінації k дійсних підписів із загальної кількості n можливі.
Однак multisig також накладає на користувача навантаження на UX і відкриває нові можливості для помилок. Налаштування 3 з 3 мультипідписів, що включає три різні ключі, надійно збережені в окремих місцях, забезпечує надійний захист… але це також означає, що якщо навіть один ключ втрачено, монети стають недоступними!
Тому налаштування, які пропонують більшу надлишковість (наприклад, 2-з-3 або 3-з-5), як правило, більш популярні: якщо один ключ буде втрачено, інші ключі все одно можуть полегшити відновлення. Але це вводить компроміс: якщо один ключ скомпрометовано без вашого відома, загальна безпека значно знижується!
Компанії люблять будинок та Неспрямований капітал спеціалізуються на рішеннях із самоохороною, де вони тримають меншість ключів для своїх клієнтів. Вони також допомагають своїм користувачам, проводячи їх через процес адаптації та спрощуючи використання систем зберігання, яке в іншому випадку може бути складним для більшості нетехнічних користувачів.
Мініскрипт та шляхи відновлення із заблокованим часом
Ліана використовує мініскрипт для створення гаманців, які мають кілька способів витрачання:
- умова первинних витрат, яка є негайною;
- одна або кілька додаткових умов витрат, які стають доступними через певний період (так звані timelock).
Це дає багато цікавих випадків використання:
- відновлення: стандартний гаманець з єдиним підписом або мультипідписом як основний шлях витрат; але окремий механізм відновлення (ключ з іншим початковим кодом, мультисиг, технічно підкований друг, зберігач) стає доступним через 6 місяців.
- Управління: компанія з двома директорами може створити 2 з 2 для казначейства компанії; у разі незгоди довірений юрист міг отримати доступ до коштів через 6 місяців.
- Затухаючий мультисиг: Гаманець починається як 3-з-3, переходить на 2-з-3 через 6 місяців і стає 1-з-3 через 9 місяців.
- Автоматичне успадкування: шлях відновлення після 6 місяців включає 2 із 3 із ваших трьох дітей; можливо, другий шлях стягнення через 1 рік включає нотаріуса, якщо спадкоємці не можуть дійти згоди.
Зауваження: усі наведені вище приклади використовують a відносне блокування часу, що вказує на вік монет (тобто: час останнього переміщення коштів). Компроміс полягає в тому, що користувач повинен пам’ятати витратити монети (надіславши їх собі), якщо час блокування наближається до закінчення.
Це лише кілька прикладів, але їх має бути достатньо, щоб переконати читача в тому, що мініскрипт є значним кроком уперед до реалізації потенціалу біткойна як програмовані гроші.
Реєстрація політики Wallet
Для облікових записів біткойн-гаманців, які використовують кілька ключів (чи то multisig, чи більш складні рішення на основі мініскриптів), дуже важливо навчити пристрій ідентифікувати адреси, які належать до цього облікового запису. Це єдиний спосіб, за допомогою якого пристрій може допомогти користувачеві переконатися, що він отримує або витрачає з правильних адрес…
Перевірка політики та xpubs копідписанта проти довіреної резервної копії є важливою, але відносно довгою.
Хороша новина полягає в тому, що це потрібно зробити лише один раз:
Коли політику буде зареєстровано з назвою (у прикладі «Decaying 3of3»), ваш пристрій зможе розпізнавати її щоразу, коли така політика використовується.
Ті, хто цікавиться технічними подробицями, можуть знайти більше інформації в Пропозиція BIP.
Резервне копіювання політики
Одним із важливих аспектів, на який слід звернути увагу, є те, що хоча багатоключові політики дозволяють підмножину приватні ключі дозволяти операції, знання про всі відкритих ключів (і точний політики) є обов’язковими.
Однак, на відміну від початкового коду, резервне копіювання політики та відкритих ключів є набагато менш ризикованим: якщо хтось це виявить, він зможе відстежити всі транзакції, пов’язані з цією політикою. Хоча це не ідеально – конфіденційність має значення! − це не так катастрофічно, як втрата ваших монет, і менш привабливо для потенційних зловмисників. Отже, зберігання кількох копій політики в гарячих гаманцях, друк і зберігання в різних місцях, шифрування та зберігання в хмарному сховищі тощо є життєздатними стратегіями.
Гаманець із єдиним підписом, який не підтримує бекдор
Зробимо крок назад. Ми обговорювали гаманці з кількома підписами, але тепер повернемося до основ, щоб створити гаманець з одним підписом. Точніше, ми хочемо такий гаманець почуває та виглядає як гаманець з одним підписом, після початкової фази налаштування. Проте ми прагнемо створити гаманець, з якого виробник не зможе вкрасти ваші кошти, навіть якщо вони є зловмисними 😈, а апаратний пристрій для підпису поводиться непередбачувано.
Цей підхід можна легко узагальнити для гаманців із кількома підписами.
Наведені нижче приклади будуть написані мовою під назвою політика, а не мініскрипт. Людям легше читати та думати про політику, її можна скомпілювати в мініскрипт за допомогою автоматизованих інструментів. Докладніше про мініскрипт і політику.
Апаратний гаманець може захистити вас у стандартній моделі безпеки. Miniscript може захистити вас за допомогою моделі захисту від бекдорів (і багато іншого!).
Нульовий крок: статус-кво
Це політика, якою сьогодні користується більшість користувачів: єдиний ключ, отриманий із вихідного коду, створеного в апаратному гаманці.
pk(key_ledger)
Звісно, неможливо довести відсутність бекдору.
Крок перший: подвоїти ці ключі
Перший крок простий:
and(pk(key_ledger), pk(key_client))
Тут, key_client
генерується на машині користувача, отже a гаряча клавіша. По суті, це налаштування мультипідпису 2 з 2. Ключовим аспектом є те, що користувач мало взаємодіє з key_client
: програмний гаманець генерує цей ключ, включає його в резервну копію гаманця та підписує, коли це необхідно (наприклад, коли користувач зайнятий підписом за допомогою апаратного підписувача).
Це вже виглядає досить цікаво: кошти не можуть бути використані без key_client
, який недоступний для виробника обладнання; навіть якби зловмисний постачальник мав повне знання про ключ у пристрої, він все одно не міг би перемістити кошти без явного націлювання на користувача, наприклад, скомпрометувавши машину, на якій працює їхній гаманець програмного забезпечення.
Однак є проблема: під час реєстрації гаманця апаратний підписувач є єдиною сутністю, здатною згенерувати відкритий ключ (xpub) key_ledger
використовується в гаманці. Отже, пристрій може навмисно генерувати a неправильно xpub, контрольований зловмисником, а пізніше відмовився (або не міг) підписати. Можливо, це досить екстремальний сценарій атаки: творець бекдору не може вкрасти кошти, і найбільше, що вони можуть зробити, це індивідуально націлитися на користувача та вимагати викуп («Я можу допомогти вам повернути ваші гроші, якщо ви заплатите мені половину ”).
Більш реалістично, це збільшує ймовірність помилок помилок: тепер у вас є два насіннєві/приватні ключі, і вам потрібно обидва щоб мати можливість витратити. Програйте будь-яке, і монети будуть заблоковані назавжди.
Крок другий: тимчасове відновлення
Ми представляємо окремий ключ відновлення, доступний лише після певного блокування часу: and(older(25920)
, pk(key_recovery))
, де 25920 – приблизна кількість блоків за 6 місяців. Повна політика стає:
or(
and(pk(key_ledger), pk(key_client)), and(after(25920), pk(key_recovery))
)
Це схоже на попередній сценарій, але з родзинкою: якщо key_ledger
or key_client
стає недоступним з будь-якої причини (найчастіше через втрату резервної копії вихідного коду!), a шлях відновлення стає доступним через 6 місяців.
Є кілька варіантів для key_recovery
, кожен зі своїми компромісами:
a. Використовуйте інший гаряча клавіша. Це практичне рішення, якщо користувач пам’ятає про скидання блокування часу. Однак, якщо гарячі клавіші зламано (сценарій, який загалом слід вважати досить вірогідним!), зловмисник може спробувати отримати доступ до коштів, щойно закінчиться час блокування, розпочавши змагання із законним власником.
b. Використовуйте окремий апаратний пристрій підпису. Це надійне рішення, яке за бажанням можна використовувати в поєднанні з іншим постачальником; однак це збільшує складність налаштування та вартість для користувача з точки зору взаємодії з користувачем.
c. Використовуйте перевірену зовнішню службу. Програмний гаманець може імпортувати xpub із зовнішньої служби, використовуючи його як key_recovery
. Цій третій стороні можна довіряти, лише якщо час блокування закінчується, що може бути привабливим компромісом для деяких користувачів.
Як згадувалося, як і для будь-якої політики з блокуванням часу, важливо, щоб користувач не забув оновити монети до закінчення терміну блокування часу.
Крок третій: ненадійна третя сторона
Давайте поєднаємо обидві ідеї (a) і (c): для шляху відновлення нам потрібна локальна гаряча клавіша key_recovery_local
, А в key_recovery_remote
який розміщено в напівдовіреній службі; ми також зберігаємо блокування часу.
or(
and(pk(key_ledger), pk(key_client)),
and(older(25920),
and(pk(key_recovery_local), pk(key_recovery_remote))
)
)
Це знижує рівень довіри, необхідний від служби відновлення. Однак ми повинні бути обережними: сама служба може стежити за блокчейном і виявляти наші UTXO – зрештою, вони надали нам key_recovery_remote
xpub, щоб вони могли сканувати UTXO, що містять pubkey, отримані з key_recovery_remote
. Вони зможуть дізнатися про нашу фінансову історію навіть до закінчення терміну блокування, навіть якщо ми ніколи не користувалися їхніми послугами.
Зауваження: Основні кореневі дерева можуть усунути цю проблему конфіденційності для певних політик, але це не завжди так і вимагає ретельної оцінки на основі конкретної політики.
Крок четвертий: закрийте третю сторону 🙈
Щоб служба відновлення не дізналася про нашу фінансову історію, замість використання pubkey, який вони нам повідомляють, ми можемо використовувати сліпий xpub техніка докладно пояснено mflaxman тут. Одним словом, замість використання key_recovery_remote
у нашій політиці ми вибираємо чотири 31-розрядні випадкові числа a
, b
, c
, d
( фактори засліплення), і ми використовуємо наступне БІП-32 похідний pubkey:
key_recovery_remote_blind = key_recovery_remote_blind/a/b/c/d
Дуже важливо, щоб ми також додавали key_recovery_remote
і фактори засліплення a
, b
, c
та d
до нашої резервної копії для подальшого використання.
Якщо нам колись знадобиться скористатися послугою відновлення, ми розкриємо a
, b
, c
, d
їм. До того часу вони не можуть виявити, що ключі отримані від них key_recovery_remote
публікуються в блокчейні: кількість можливих комбінацій для 4 факторів засліплення становить 2^(31*4) = 2^124
, що унеможливлює брутфорс їх усіх.
Крок п'ятий: занадто багато гарячих клавіш можуть спалити вас 🔥
Нам вдалося зробити наш програмний гаманець беззахисним. Однак ми представили іншу проблему: обидві умови витрат використовують локально створений, гарячий ключ, який не перевірено апаратним гаманцем. Таким чином, якщо хост-машину зламано, це може змусити вас зареєструвати політику за допомогою pubkeys key_client
та key_recovery_local
, але помістіть випадкові, непов’язані закриті ключі в нашу резервну копію (пам’ятайте, що гарячий ключі є частиною нашої резервної копії!).
Це фактично призведе до того, що будь-які кошти будуть надіслані на гаманець невитрачений, оскільки ніхто не контролює закриті ключі, необхідні для підпису.
Є кілька рішень для вирішення цієї проблеми:
- Під час адаптації, після друку нашої резервної копії на папері, ми можемо використовувати окремий пристрій, щоб перевірити, чи приватні та публічні гарячі клавіші в резервній копії дійсно збігаються. Такий підхід усунув би проблему, оскільки ми були б впевнені, що маємо всі необхідні ключі, необхідні для реконструкції та підписання.
- Ми можемо додати іншу умову витрат із ще довшим часовим блокуванням (9 місяців, 38880 блоків), яка вимагає лише
key_ledger_failsafe
з апаратного пристрою. Таким чином, у найгіршому сценарії, коли все інше не вдається, ми повертаємося до безпеки єдиного пристрою підпису. У звичайних умовах ми б ніколи не дозволили закінчити перше блокування часу, отже, друге блокування часу також не закінчиться!
За другого підходу остаточна політика виглядатиме так
or(
and(pk(key_ledger), pk(key_client)),
or(
and(older(25920),
and(pk(key_recovery_local), pk(key_recovery_remote_blind))
),
and(older(38880), pk(key_ledger_failsafe))
),
)
Ця конфігурація програмного гаманця задовольняє всі параметри безпеки, про які ми заявили на початку. Крім того, він пропонує шлях відновлення у випадку основних витратних ключів key_ledger
втрачені. Гарна функція!
Підключення до гаманця з програмним забезпеченням без бекдорів
Як би виглядала взаємодія з користувачем гаманця, що використовує таку складну політику? Ось короткий огляд:
- Користувач відкриває програмний гаманець і починає створювати новий обліковий запис.
- Програмний гаманець пропонує користувачеві підключити свій пристрій підпису та отримує xpubs для
key_ledger
таkey_ledger_failsafe
. - Програмний гаманець автономно генерує гарячу клавішу key_client.
- Програмний гаманець отримує
key_recovery_remote
із служби спільного підписання або дозволяє користувачеві вказати ключ іншим способом. За бажанням він обчислюєkey_recovery_remote_blind
використовуючи техніку засліплення, згадану раніше. - Програмний гаманець створює резервну копію політики, яка містить точну політику мініскрипту, усі xpub і розширений закритий ключ для
key_client
гаряча клавіша. Ця резервна копія надійно зберігається (наприклад, роздруковується на папері або зберігається на окремому пристрої). - Нарешті, програмний гаманець дає вказівку користувачеві зареєструвати політику на пристрої. Користувач перехресно перевіряє резервну копію (на папері чи будь-якому носії, крім екрана, який контролюється програмним гаманцем).
Програмний гаманець керує більшістю вищезазначених кроків, роблячи участь користувача не більш обтяжливою, ніж очікувані зусилля, необхідні сьогодні для налаштування гаманця з кількома підписами.
Для адаптації знадобиться лише кілька хвилин після створення хорошого UX. Після завершення програмний гаманець може забезпечувати роботу користувача, дуже подібну до типового гаманця з одним підписом. Ось як miniscript все змінить: зникнувши з поля зору користувача!
Поліпшення стрижневих коренів
Ledger підтримує мініскрипт починаючи з версії 2.1.0 програми Bitcoin, випущеної в березні. У той час як підтримка отримання та витрачання з адрес основного кореня була ввімкнена з стрижневий софтфорк у листопаді 2021 року ми наносимо останні штрихи на наступний крок дорожньої карти: підтримку мініскриптів для Taproot.
Taproot матиме величезний вплив на зручність використання підходів, представлених у цій статті. Якщо основний шлях витрачання є умовою витрачання з одним ключем, існування шляхів відновлення витрат буде неможливо виявити в блокчейні, якщо вони не будуть використані. Це значно покращить конфіденційність, повністю виключивши будь-які відбитки пальців для стандартного шляху витрат. Крім того, це покращує масштабованість, оскільки стандартний шлях витрат стає максимально рентабельним. Це означає, що через наявність шляхів відновлення не буде стягуватися додаткових витрат, якщо вони не використовуються. Це значне оновлення транзакцій SegWit, які вимагають публікації всього сценарію, включаючи всі умови витрат, під час будь-яких витрат.
Нарешті, більш просунуті протоколи, такі як MuSig2 (нещодавно стандартизований) і FROST буде перезаряджати основний кореневий шлях ключа. Побудовані на основі підписів Шнорра, ці протоколи дозволяють створювати один сукупний pubkey який можна використовувати для представлення n-з-n мультипідпис або a k-з-n порогова схема. Це дозволило б використовувати шлях ключа Taroot навіть у випадках, які сьогодні частіше представлені спеціальними сценаріями multisig.
Висновки
Ця стаття досліджує невелику (але важливу) нішу великого дизайнерського простору, який мініскрипт відкриває для програмних гаманців.
Ми показали, як мініскрипт можна використати для створення гаманця програмного забезпечення, що не підтримує бекдор, а також додали додатковий шлях відновлення, який дозволяє запобігти катастрофічній втраті ключів. Незважаючи на те, що апаратні пристрої для підпису не можуть застосувати модель захисту від бекдорів, підтримуючи мініскрипт, вони дозволяють програмним гаманцям, які роблять саме це!
Розумно використовуючи комбінацію схем мультипідпису, блокування часу, сліпих xpubs і гарячих клавіш, ми продемонстрували безпечну конфігурацію гаманця, яка балансує між безпекою, конфіденційністю та надійністю.
Крім того, ми стверджували, що це можливо без негативного впливу на досвід користувача, оскільки складність налаштування не означає великого додаткового навантаження на UX.
Ми в захваті від можливостей, які відкриє miniscript для наступного покоління самостійного зберігання біткойнів.
- Розповсюдження контенту та PR на основі SEO. Отримайте посилення сьогодні.
- PlatoData.Network Vertical Generative Ai. Додайте собі сили. Доступ тут.
- PlatoAiStream. Web3 Intelligence. Розширення знань. Доступ тут.
- ПлатонЕСГ. Автомобільні / електромобілі, вуглець, CleanTech, Енергія, Навколишнє середовище, Сонячна, Поводження з відходами. Доступ тут.
- BlockOffsets. Модернізація екологічної компенсаційної власності. Доступ тут.
- джерело: https://www.ledger.com/blog/towards-a-trustless-bitcoin-wallet-with-miniscript
- : має
- :є
- : ні
- :де
- $UP
- 1
- 2021
- 2023
- 30
- 7
- 9
- a
- здатність
- Здатний
- МЕНЮ
- вище
- абсолют
- абсолютно
- доступ
- доступний
- доступною
- відповідно
- рахунки
- Рахунки
- дію
- дії
- активно
- насправді
- додавати
- додати
- доповнення
- Додатковий
- Додатково
- адреси
- просунутий
- після
- проти
- вік
- Aid
- мета
- ВСІ
- дозволяти
- дозволяє
- по
- вже
- Також
- хоча
- завжди
- an
- та
- оголошений
- Інший
- будь-який
- все
- додаток
- привабливий
- з'являтися
- застосування
- підхід
- підходи
- твердження
- приблизний
- ЕСТЬ
- суперечливо
- сперечався
- стаття
- AS
- зовнішній вигляд
- допомогу
- асоційований
- At
- атака
- підлягає аудиту
- авторизувати
- Автоматизований
- автономно
- доступний
- назад
- закулісний
- підтриманий
- підтримка
- резервна копія
- баланси
- заснований
- основний
- В основному
- Основи
- BE
- оскільки
- ставати
- стає
- перед тим
- початок
- буття
- нижче
- КРАЩЕ
- між
- За
- Біткойн
- Bitcoin Гаманець
- біткойн-гаманці
- Blend
- blockchain
- блоки
- Blockstream
- Блог
- обидва
- Brain
- Приносить
- віщати
- Помилка
- будувати
- побудований
- тягар
- горіти
- бізнес
- зайнятий
- але
- by
- званий
- CAN
- не може
- здатний
- обережний
- випадок
- випадків
- катастрофічний
- Викликати
- викликаючи
- обережність
- певний
- виклик
- шанс
- зміна
- діти
- чіп
- Вибирати
- Вибираючи
- стверджував,
- очевидно
- хмара
- Cloud Storage
- код
- Монети
- поєднання
- комбінації
- комерційний
- загальний
- зазвичай
- спілкуватися
- Компанії
- компанія
- Компанії
- повний
- повністю
- комплекс
- складність
- Компрометація
- компрометуючі
- обчислення
- обчислення
- Турбота
- стан
- Умови
- конференція
- конфігурація
- З'єднуватися
- Консенсус
- Отже
- Вважати
- вважається
- містяться
- контроль
- управління
- переконати
- виправити
- пошкоджені
- Коштувати
- може
- Курс
- створювати
- створення
- створення
- творець
- критичний
- критичний аспект
- вирішальне значення
- В даний час
- зберігач
- Зберігання
- Клієнти
- Небезпечний
- Відмова прийняти
- зменшується
- вважати
- певний
- Попит
- продемонстрований
- розгорнути
- Отриманий
- description
- дизайн
- призначений
- бажаний
- деталь
- докладно
- деталі
- виявляти
- розробників
- пристрій
- прилади
- різний
- важкий
- зменшується
- безпосередньо
- Директори
- зникають
- катастрофічний
- відкрити
- відкриття
- обговорювалися
- обговорення
- displayed
- do
- робить
- Ні
- зроблений
- подвійний
- два
- під час
- кожен
- легше
- легко
- зусилля
- або
- усунутий
- усуваючи
- ще
- підкреслити
- працевлаштований
- включіть
- включений
- дозволяє
- кінець
- примусове виконання
- досить
- забезпечувати
- забезпечення
- вхід
- заманливо
- Весь
- повністю
- суб'єкта
- обладнання
- помилки
- особливо
- істотний
- по суті
- встановити
- і т.д.
- оцінка
- Навіть
- НІКОЛИ
- Кожен
- все
- точно
- приклад
- Приклади
- збуджений
- виконувати
- виконано
- Здійснювати
- існування
- очікуваний
- досвід
- витікання
- Експлуатувати
- досліджує
- експорт
- продовжується
- зовнішній
- екстремальний
- фасилітувати
- фактори
- зазнає невдачі
- Провал
- достатньо
- Падати
- далеко
- особливість
- риси
- лютого
- кілька
- остаточний
- фінансовий
- фінансова історія
- знайти
- Перший
- гнучкий
- Flip
- Сфокусувати
- після
- слідує
- для
- назавжди
- Вперед
- чотири
- каркаси
- часто
- друг
- від
- Повний
- повністю
- функціональність
- фонд
- засоби
- Крім того
- марний
- майбутнє
- Головна мета
- в цілому
- породжувати
- генерується
- генерує
- породжує
- покоління
- даний
- Go
- буде
- добре
- великий
- значно
- було
- Половина
- апаратні засоби
- апаратний пристрій
- Апаратний гаманець
- Виробник апаратного гаманця
- Ключниці для обладнання
- шкідливий
- Мати
- має
- допомога
- отже
- історія
- тримати
- надія
- господар
- відбувся
- ГАРЯЧА
- Як
- Однак
- HTTP
- HTTPS
- величезний
- Людей
- ідея
- ідеальний
- ідеї
- ідентифікувати
- if
- негайно
- Impact
- впливає
- реалізовані
- імпорт
- важливо
- неможливе
- удосконалювати
- in
- includes
- У тому числі
- включення
- Збільшує
- неймовірний
- дійсно
- незалежний
- Індивідуально
- промисловість
- інформація
- за своєю суттю
- початковий
- всередині
- Інсайдер
- вселяти
- установка
- екземпляр
- замість
- навмисно
- взаємодіяти
- інтерактивний
- інтерес
- зацікавлений
- цікавий
- інтерфейс
- в
- вводити
- введені
- Вводить
- настирливий
- участь
- за участю
- питання
- IT
- ЙОГО
- сам
- просто
- тільки один
- ключ
- ключі
- Знати
- знання
- відомий
- ландшафт
- мова
- портативний комп'ютер
- останній
- пізніше
- юрист
- Веде за собою
- УЧИТЬСЯ
- вивчення
- найменш
- Гросбух
- залишити
- законний
- менше
- дозволяти
- рівень
- використання
- як
- Ймовірно
- пов'язаний
- Перераховані
- погрузка
- місцевий
- місць
- замкнений
- Довго
- довше
- подивитися
- виглядає як
- втрачати
- програш
- від
- втрати
- втрачений
- машина
- головний
- Більшість
- зробити
- РОБОТИ
- Робить
- шкідливих програм
- управляє
- управління
- маніпулювання
- манера
- виробник
- Виробники
- багато
- березня
- матч
- Може..
- засоби
- заходи
- механізм
- середа
- згаданий
- просто
- повідомлення
- повідомлення
- метод
- методика
- Майамі
- може бути
- мініскрипт
- меншість
- хвилин
- Місія
- помилки
- модель
- гроші
- моніторинг
- місяців
- більше
- Більше того
- найбільш
- в основному
- рухатися
- переїхав
- багато
- множинний
- Мультисиг
- повинен
- ім'я
- наближається
- необхідно
- Необхідність
- необхідний
- потреби
- негативно
- мережа
- ніколи
- Нові
- новини
- наступний
- приємно
- немає
- нетехнічні
- нормальний
- Листопад
- листопад 2021
- зараз
- номер
- номера
- отримує
- of
- пропонувати
- пропонує
- Пропозиції
- offline
- on
- На борту
- один раз
- ONE
- ті,
- тільки
- відкрити
- з відкритим вихідним кодом
- Відкриється
- операційний
- операції
- Можливості
- Опції
- or
- порядок
- Інше
- інакше
- наші
- з
- викладені
- поза
- над
- загальний
- огляд
- власний
- власник
- Папір
- Першорядний
- частина
- особливо
- партія
- шлях
- Платити
- Виконувати
- може бути
- period
- постійно
- фаза
- телефон
- місце
- місця
- plato
- Інформація про дані Платона
- PlatoData
- точка
- точок
- Політика
- політика
- популярний
- можливостей
- це можливо
- можливо
- пошта
- потенціал
- потенційно
- влада
- Практичний
- практично
- практика
- необхідність
- точно
- передбачати
- Передбачуваний
- наявність
- представити
- представлений
- запобігати
- запобігає
- попередній
- раніше
- в першу чергу
- первинний
- друк
- попередній
- недоторканність приватного життя
- приватний
- Private Key
- Приватні ключі
- Проблема
- проблеми
- процедура
- процес
- виробляти
- Вироблений
- випускає
- правильно
- властивості
- власність
- запропонований
- захист
- захищений
- захищає
- захист
- протокол
- протоколи
- Доведіть
- забезпечувати
- за умови
- громадськість
- публічний ключ
- відкриті ключі
- публікувати
- опублікований
- Видавничий
- мета
- put
- Поклавши
- питання
- Гонки
- випадковий
- Викуп
- швидше
- досягати
- Читати
- читач
- розуміючи,
- причина
- отримання
- нещодавно
- визнавати
- запис
- відновлення
- відноситься
- реєструвати
- зареєстрований
- реєструючий
- щодо
- звільнити
- випущений
- покладатися
- запам'ятати
- замінювати
- представляти
- представлений
- репутація
- вимагати
- вимагається
- Вимагається
- в результаті
- зберігати
- повертати
- показувати
- право
- Risk
- ризики
- Ризикований
- Дорожня карта
- міцний
- стійкість
- Роль
- ролі
- біг
- пробіжки
- то ж
- say
- масштабованість
- сканування
- сценарій
- схема
- схеми
- Шнорр
- Екран
- scripts
- другий
- розділ
- безпечний
- безпечно
- безпеку
- побачити
- насіння
- Насіння
- пошук
- здається
- Здається,
- SegWit
- Самоохорона
- відправка
- чутливий
- посланий
- окремий
- обслуговування
- комплект
- установка
- кілька
- Короткий
- Повинен
- показав
- підпис
- Signatures
- значний
- істотно
- підписання
- Ознаки
- аналогічний
- простий
- спрощення
- з
- один
- невеликий
- розумний
- So
- Софтвер
- рішення
- Рішення
- ВИРІШИТИ
- деякі
- Хтось
- скоро
- складний
- Source
- Простір
- спеціалізуватися
- конкретний
- специфікації
- витрачати
- Витрати
- standard
- стенди
- починається
- Статус
- Крок
- заходи
- Як і раніше
- зберігання
- зберігати
- зберігання
- стратегії
- сила
- рядок
- сильний
- боротьба
- успішний
- Успішно
- такі
- підсумовувати
- Надзарядка
- підтримка
- Підтримуючий
- Опори
- передбачуваний
- системний
- системний ризик
- Systems
- снасті
- Приймати
- корінь
- Мета
- націлювання
- технічний
- технічно
- Технологія
- terms
- ніж
- Що
- Команда
- Монети
- їх
- Їх
- самі
- потім
- Там.
- тим самим
- отже
- Ці
- вони
- речі
- думати
- третій
- це
- ті
- загрози
- три
- поріг
- через
- Таким чином
- час
- трудомісткий
- до
- сьогодні
- сьогоднішній
- занадто
- інструменти
- теми
- Усього:
- до
- Трасування
- трек
- послужний список
- поїзд
- угода
- Transactions
- переходи
- переводити
- скарбниця
- Дерева
- правда
- Довіряйте
- Довірений
- недовірливий
- Правда
- поворот
- два
- Типи
- типовий
- не в змозі
- розуміти
- розв’язує
- на відміну від
- відімкнути
- розблокує
- непередбачуваний
- до
- модернізація
- us
- юзабіліті
- використання
- використовуваний
- користувач
- User Experience
- користувачі
- використовує
- використання
- використовувати
- використовувати
- використовує
- ux
- ПЕРЕВІР
- різноманітність
- різний
- величезний
- продавець
- перевірено
- перевірити
- версія
- дуже
- viable
- життєво важливий
- Уразливості
- чекати
- Wallet
- Гаманці
- хотіти
- було
- шлях..
- способи
- we
- були
- Що
- коли
- коли б ні
- Чи
- який
- в той час як
- всі
- чому
- Вікіпедія
- волі
- з
- в
- без
- слова
- світ
- б
- письмовий
- Неправильно
- рік
- ще
- Ти
- вашу
- себе
- зефірнет
- нуль