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 не пострадал, пишут на своем сайте.

Из недоработок софта от taurusgroup можно выделить невозможность сериализовать структуру Config с приватными данными в набор байтов для сохранения после каждого раунда, чтобы при падении участника(ноды) и его последующем восстановлении генерация "общей" пары ключей не прекращалась или подписи(в подписях Шнорра или надстройкой над Шнорром - FROST нужно передать 2 сообщение от учасника другим).

Кроме, подписи ECDSA и Шнорра, существует еще несколко схем. Более новая - EDDSA, которая используется в экосистеме блокчейнов cosmos. В проекте удаленного подписывающего horcrux - это RAFT + Пороговые мультиподписи(либа). Horcrux представляет из себя кластер RAFT с gRPC серверами, который подписывает данные. Т.е. приватный ключ "распределен" по кластеру и в то же время кластер толерантен к определенному кол-ву падений нод. В реализации horcrux есть уже готовые объекты работающие с данной библиотекой, если использование покажется сложным.

4. Вывод

Мультиподписи(и в целом MPC) полезны не только в блокчейне, где есть потребность в диверсификации рисков между клиентом и поставщиком софта(многие криптокошельки внедряют MPC, например Bitget, хотя я не понимаю, почему пользователи должны делить риски по хранению своих средств с кем-то еще) и совместном управлении токенами, но так же и в обычной инфраструктуре, например, кластерная подпись jwt токенов. Совместная подпись данных между разными сервисами, например, подпись токена для доступа к чувствительным данным и т.д

MPC как концепция в дальнейшем может стать основной для общих безопасных вычислений между участниками. Как и формирование согласованной базы данных или реестра между нодами в блокчейне, MPC будут "согласованными вычислениями".