FROST

Уявімо об’єднання, заощадженнями якого керують Анна, Ян і Єва. Вони обирають правило 2 із 3: платіж можуть схвалити Анна з Яном, Анна з Євою або Ян з Євою. Кожен зберігає іншу секретну частку — криптографічно створену частину спільного ключового матеріалу. Однієї недостатньо, але це й не три копії того самого пароля. Якщо Єва недоступна, двоє інших можуть співпрацювати. Та сама межа діє для нападника: здобувши достатньо часток, він теж зможе підписати. Отже, розподіл допомагає лише тоді, коли злам одного пристрою чи облікового запису не відкриває доступ до всіх інших. [1] [2]

Анні не варто підтверджувати операцію лише тому, що застосунок повідомив про очікування підпису. Вона має знати одержувача, суму й комісію та перевірити, чи повертається решта об’єднанню. Кожному підписувачу потрібен надійний спосіб перевірити справжню транзакцію. Hash, короткий криптографічний відбиток даних, сам по собі не пояснює людині їхнього змісту. FROST забезпечує співпрацю над однаковим повідомленням; він не визначає, чи справжній рахунок і чи людина зрозуміла, що саме схвалює. Навіть готовий підпис ще не є підтвердженням платежу в блоці. Блок — це група транзакцій, записана до спільної історії мережі Bitcoin. RFC 9591 — інформаційна специфікація протоколу, а не сертифікат безпеки всього застосунку. [1] [2]

Taproot — це оновлення Bitcoin, яке дозволяє витрачати кошти за підписом відповідного ключа або після виконання заздалегідь визначених умов. Правильно сформований пороговий підпис під час витрачання через ключовий шлях Taproot може виглядати як звичайний підпис одним ключем. Із самого підпису не видно внутрішньої кількості часток або порога. Це корисно для приватності й розміру даних підпису, але не робить анонімними всю транзакцію чи спілкування учасників. Bitcoin вимагає точних правил BIP 340; звичайного FROST на кривій secp256k1, математичній основі обчислень із ключами Bitcoin, недостатньо. Тому Zcash Foundation (ZF) пропонує окремо frost-secp256k1-tr для Taproot. Потрібно також правильно застосувати зміни ключа, які використовує Taproot. Однакова назва кривої не доводить сумісності, а наявність бібліотеки не означає підтримки в кожному гаманці. [3] [4]

Перш ніж щось підписувати, об’єднання має безпечно створити частки. Довірений розподілювач може згенерувати повний ключ і розділити його. Але це створює вразливий момент: він знає весь ключ, і збережена копія дозволила б обійти заплановане спільне схвалення. Інший шлях — DKG, розподілена генерація ключа, за якої повний секретний ключ не мусить з’являтися в одного учасника. Вона потребує автентифікованого захищеного зв’язку й правильного виконання протоколу. Просто надіслати кілька файлів електронною поштою недостатньо. RFC 9591 зосереджено на підписанні; він не обіцяє автоматично DKG в кожному продукті. Довготривала частка ключа також відрізняється від частки підпису конкретного платежу. [1] [2]

Саме підписання відбувається у два раунди, без урахування попереднього створення ключа. Спочатку кожен обраний учасник генерує два секретні одноразові значення nonce та передає їхні публічні зобов’язання — значення, що криптографічно прив’язують його до цих nonce. Потім він отримує спільне повідомлення й список зобов’язань, перевіряє дані та обчислює свою частку підпису. Координатор об’єднує частки. Коефіцієнти прив’язки пов’язують обчислення з конкретним повідомленням, відкритим ключем групи та зобов’язаннями. За правила 2 із 3 можна почати сеанс із двома учасниками. Якщо ж для нього обрали всіх трьох, внесок мають надати всі; того, хто замовк, не можна просто виключити. [1] [3]

Nonce тут — секретне значення для однієї спроби підписання, а не багаторазовий пароль. Повторне використання може розкрити секретний ключовий матеріал. Якщо комп’ютер Яна вийде з ладу після надсилання частки підпису, відновлення старого стану не повинне позначити використані nonce як нові. Незавершений платіж теж не дозволяє використовувати їх повторно. Безпечна реалізація потребує якісної випадковості, розділення одночасних спроб і надійного вилучення використаних значень. Тому не варто самостійно складати FROST із випадкових скриптів. Правильна математика не захистить секретні дані, з якими неправильно поводяться. [1]

Координатор організовує повідомлення, але сама ця роль не дозволяє йому підписувати за об’єднання. Потрібні внески обраних власників часток. Утім, він може затримувати повідомлення чи перервати сеанс; його також може зірвати некоректний внесок учасника. Перевірки виявляють неправильну частку підпису, але для встановлення винуватця потрібно достовірно знати походження повідомлень. Виявлення проблеми не гарантує завершення. Нова спроба потребує доступної уповноваженої групи та свіжих nonce. Тож об’єднанню потрібен план на випадок збоїв і незгоди, а не лише число порога на початковому екрані. [1] [2]

Якщо Єва втратить пристрій, напис FROST сам по собі не поверне кошти. Резервна копія має зберігати її частку, ідентифікатор, необхідні дані групи та можливість завантажити їх у сумісну програму. Це не обов’язково звичайна Seed Phrase — словесна резервна копія гаманця. Відновлення частки за допомогою інших та оновлення часток — додаткові процедури, які конкретна система має підтримувати. Копія частки Єви лишається тією самою часткою й не додає незалежного голосу. Оновлення зі збереженням ключа групи також не знешкоджує достатню кількість раніше викрадених часток. Тому перед використанням справжніх заощаджень перевірка має охоплювати відновлення, збої та точну версію програми, а не лише один успішний підпис. [2] [3]