Электронные подписи. Но что мы знаем о мультиподписях?
1. Введение
В этой статье я хотел бы описать библиотеки для мультиподписи и связанные с ними MPC (multi party computation или многосторонние вычисления). Мне сложно претендовать на четкое описание MPC или мультиподписей. Но цель лишь уведомить о наличие всего этого в сети. Так как я не увидел в ru сегменте достаточного кол-ва информации по данной важной теме. Статья будет разделена на 2 части — небольшое описание протоколов и реализации.
Столкнулся с данной темой, когда дорабатывал библиотку для мультиподписей в блокчейнах Bitcoin и Ethereum. При отправке средств в Bitcoin и Ethereum используется электронная подпись под названием ECDSA. Мультиподписи дали возможность совместного управления средствами и диверсификации рисков при хранении приватного ключа (к примеру его можно распределить между несколькими серверами).
2. MPC и пороговые мультиподписи.
MPC (многосторонние вычисления) — возможность произвести совместные вычисления между участниками без раскрытия секретной информации каждого участника. На основе технологий и концепций MPC базируются мультиподписи. Подробная статья о связи MPC и мультиподписей есть у компании FireBlocks (компания предлагает услуги по защите средств в блокчейне на основе мультиподписей и SGX. Была создана в результате атак на криптовалютные биржи и запросом на безопасное хранение средств в блокчейне (история компании).
Самые известные MPC алгоритмы для подписей являются — GG18 и GG20(Gennaro and Goldfeder algorithms). Они используются в большинстве случаев (Binance bnb-chain, ING Bank, BitGo TSS, ZenGo, Safeheron), на медиуме есть пример пороговой ECDSA c Gennaro and Goldfeder 2020. Из популярных выделяют еще — Lindell et al., Doerner et al. У Fireblocks есть сравнения по всем схемам:
сравнение алгоритмов для мультиподписей
Также компания выпустила новый протокол — CMP-MPC на базе GG20 (CMP — первые буквы разработчиков протокола Prof. Ran Canetti of Boston University, Nikolaos Makriyannis, and Udi Peled.). О котором в основном буду рассказывать в реализациях. Но немного теории.
2.1 DKG
Сам протокол и большинство из них можно разбить на составляющие алгоритмы. В данной статье на медиуме подробно они описаны. Кратко распишу мое понимание структуры.
Начиная с самого простого и фундаментального — Схема разделения Шамира. Есть секрет, который участник (далее дилер) разбивает на несколько частей с порогом, распределяя части между другими участниками. Т.е. для восстановления исходного набора байтов нужно собрать пороговое кол-во частей. Например 2 из 3. За эту часть отвечает SSS — Shamir Scheme Sharning. Подробную математику описал в своей статье работу схемы в hashicrop vault (зашифрованное хранилище, где ключ шифрования разбивается на несколько частей).
Далее возникает потребность проверки правильности частей и самого дилера. Эти схемы строятся поверх SSS и называются Verifiable Secret Sharing (VSS). Самая простая реализация это схема Фельдмана, в статье на медиуме она также описана. VSS позволяет каждому участнику проверить части друг друга на принадлежность к секрету, при этом не раскрывая их.
Последний этап — отказ от дилера и формирование общего секрета между участниками. Называется DKG (Distributed Key Generation). Из статьи на медиум — «В протоколе DKG группа из n сторон P₁, …, Pₙ взаимодействует друг с другом через безопасные и аутентифицированные каналы связи для генерации пары ключей (sk, pk) — секретного ключа и открытого ключа соответственно.» В GG протоколах используется Gennaro et al.«s DKG protocol (2006), который в свою очередь использует Pedersen«s VSS.
3. Реализации
В 2020 Fireblocks представила протокол CMP-MPC. А компания TaurusGroup создала open-source реализацию на основе СMP от fireblocks, о чем и говорит у себя в блоге, напоминая о том, что FireBlocks не будет создавать заявку на патент. В разработке multi-party-sign библитеки от taurusgroup участвовал создатель хеш функции BLAKE — Jean-Philippe Aumasson (он же написал отличную книгу по криптографии — О криптографии всерьез). В файле example/example.go можно найти примеры использования библиотеки для формирования «общей» пары ключей между участниками, обновления приватных частей и подписи даты.
В либе, кроме пороговой подписи ECDSA есть и протокол FROST — это про подписи Шнорра, использующиеся в биткоине, были введены в улучшениях, которые называют Taproot. FROST улучшает уже существующую схему мультиподписи Шнорра.
Стандартная подпись ECDSA не проходила в Ethereum по причине некоторых требований блокчена к подписям, но это было исправлено мной. Метод SigEthereum () у сигнатуры возвращает подпись в подходящем для ETH формате.
Также существует поддержка BIP32(иерархическая генерация ключей). Кратко — это возможность генерировать дочерние ключи из имеющихся. Приватная часть каждого участника это стуктура Config, которая содержит всю нужную информацию для подписи и метод DeriveBIP32(i uint32), который и позволяет создать новый конфиг у каждого участника для дочерней «общей пары». В комментарии функции написано — «This function uses unhardened derivation…». Это означает, что 3 лицо имея открытый родительский ключ, может вычислить дочерние адреса и прослеживать связь между ними.
Уверенность в протоколе добавляет то, что именно компания разработчик FireBlocks обнаружила в 2023 году серьезную уязвимость под названием BitForge, затрагивающию GG18, GG20. «Для упомянутых выше Binance, Coinbase и ZenGo уже вышли патчи.» Но новый протокол от Fireblocks не пострадал, пишут на своем сайте.
цитата по поводу cve под название BitForge
Из недоработок софта от taurusgroup можно выделить невозможность сериализовать структуру Config с приватными данными в набор байтов для сохранения после каждого раунда, чтобы при падении участника (ноды) и его последующем восстановлении генерация «общей» пары ключей не прекращалась или подписи (в подписях Шнорра или надстройкой над Шнорром — FROST нужно передать 2 сообщение от учасника другим).
Кроме, подписи ECDSA и Шнорра, существует еще несколко схем. Более новая — EDDSA, которая используется в экосистеме блокчейнов cosmos. В проекте удаленного подписывающего horcrux — это RAFT + Пороговые мультиподписи (либа). Horcrux представляет из себя кластер RAFT с gRPC серверами, который подписывает данные. Т.е. приватный ключ «распределен» по кластеру и в то же время кластер толерантен к определенному кол-ву падений нод. В реализации horcrux есть уже готовые объекты работающие с данной библиотекой, если использование покажется сложным.
4. Вывод
Мультиподписи (и в целом MPC) полезны не только в блокчейне, где есть потребность в диверсификации рисков между клиентом и поставщиком софта (многие криптокошельки внедряют MPC, например Bitget, хотя я не понимаю, почему пользователи должны делить риски по хранению своих средств с кем-то еще) и совместном управлении токенами, но так же и в обычной инфраструктуре, например, кластерная подпись jwt токенов. Совместная подпись данных между разными сервисами, например, подпись токена для доступа к чувствительным данным и т.д
MPC как концепция в дальнейшем может стать основной для общих безопасных вычислений между участниками. Как и формирование согласованной базы данных или реестра между нодами в блокчейне, MPC будут «согласованными вычислениями».
