182 / 736FROST

FROST

Одна подпись, решение о которой принимают несколько человек

Анна, Ян и Ева хотят распоряжаться общими средствами так, чтобы никто не мог отправить их в одиночку. FROST позволяет задать необходимое сотрудничество и объединить частичные вычисления в одну подпись. Во время подписания полный секретный ключ не нужно собирать на одном устройстве.

FROST — протокол пороговых подписей Шнорра, то есть цифровых подписей, создаваемых совместно. Порог определяет, сколько владельцев разных долей общего секретного ключа должны как минимум участвовать в подписании. Секретный ключ — это число, необходимое для создания подписи; здесь при подписании вместо полного ключа участники используют свои доли. Результат проверяют одним открытым ключом группы: его можно передавать другим, и сам по себе он не позволяет подписывать. Название расшифровывается как Flexible Round-Optimized Schnorr Threshold; это не кошелёк и не новый вид биткоина.

Представим объединение, сбережениями которого распоряжаются Анна, Ян и Ева. Они выбирают правило 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]

Для полной картины прочитайте эту статью вместе с Schnorr Signature, MuSig2, Multisig, Taproot, Shamir Secret Sharing, Bitcoin.

DOC · 001RFC 9591 — FROSTСпецификация DOC · 002ZF FROST Book — key generation and recoveryПервичный источник DOC · 003ZF frost-secp256k1-tr — Taproot implementationПервичный источник DOC · 004BIP 340 — Schnorr Signatures for secp256k1Спецификация
Обновлено: Сначала источники · Не является инвестиционной рекомендацией