Розробка MPC-гаманця (Multi-Party Computation)

Розробка MPC-гаманця

Традиційний крипто-гаманець зберігає приватний ключ в одному місці: на пристрої, в HSM, в хмарі. Будь-яка компрометація цього місця = втрата коштів. MPC (Multi-Party Computation) вирішує фундаментальну проблему інакше: приватний ключ ніколи не існує цілісно в жодній точці системи. Замість цього кілька сторін тримають key shares і спільно обчислюють підпис, не розкриваючи один одному свої долі.

Це не мультисиг. У мультисигу підпис транзакції потребує M з N підписів, кожен з яких видно on-chain — мережа знає, що використовується мультисиг. В MPC фінальний підпис виглядає як звичайний ECDSA підпис одного ключа. Жодних on-chain витрат, жодних змін в протоколі. Це критично для: зменшення газової вартості, приватності (приховує схему управління ключами), сумісності з будь-якими ланцюгами та dApp.

Математична основа

Shamir's Secret Sharing та threshold schemes

Основа MPC-гаманців — threshold signature schemes (TSS). Найчастіше використовувані: GG18, GG20 (Gennaro-Goldfeder), CGGMP21 та DKLS19.

Shamir's Secret Sharing — базова концепція, але не сама TSS. В SSS секрет ділиться на N шардів, M з N достатньо для відновлення. Проблема: відновлення потребує зібрати шарди в одному місці — уразливість. TSS усуває це: підпис обчислюється без збору ключа.

Threshold ECDSA (використовуємо secp256k1 як у Bitcoin/Ethereum):

Нехай приватний ключ d = d1 + d2 (mod q) для 2-of-2 схеми. Кожна сторона тримає d1 та d2. При підписанні:

1. Кожна сторона генерує свій nonce: k1, k2
2. Спільно обчислюють R = (k1 + k2)^(-1) * G (commitment protocol)
3. Кожна сторона обчислює свою частину s: s1, s2
4. Фінальний підпис: s = s1 + s2 (mod q)
5. Підпис (r, s) — звичайний ECDSA підпис

Складність на кроці 2: пряме обчислення потребуватиме розкриття k1 або k2. Тому використовуються Oblivious Transfer, Paillier encryption або Curve25519-based протоколи для безпечного обчислення.

Протоколи: GG20 vs CGGMP21

GG20 (Gennaro-Goldfeder 2020) — довгий час був стандартом де-факто. Використовується у Fireblocks, ZenGo, Coinbase Wallet. Підтримує threshold t-of-n для довільних t та n. Потребує Paillier encryption для безпечного множення.

Недоліки GG20: складність реалізації, дорога keygen (O(n²) комунікацій), уразливість до «rouge key attack» потребує range proofs що збільшує розмір повідомлень.

CGGMP21 (Canetti-Gennaro-Goldfeder-Makriyannis-Peled 2021) — сучасний state-of-the-art. Виправляє уразливості GG20, більш ефективне підписання (менше раундів комунікації). Підтримує identifiable abort — якщо одна сторона ведеться дурницькі, можна ідентифікувати її через криптографічний доказ.

DKLS19 — альтернатива на основі Oblivious Transfer. Компактніші повідомлення, але менше реалізацій в production.

Key Refresh

Критично важлива операція: періодичне оновлення key shares без змін публічного ключа (а значить, без зміни адреси). Якщо атакуючий компрометив один шард, але не встиг отримати фінальний підпис до refresh — компрометація нейтралізована.

Refresh protocol (спрощено):
1. Кожна сторона генерує нові random shares: r1, r2, ...rn
2. Підсумовують: Σri = 0 (нульова сумарна зміна)
3. Кожна сторона додає своє ri до поточного di
4. Публічний ключ d*G не змінюється: Σ(di + ri)*G = d*G + Σri*G = d*G

Рекомендована частота refresh: кожні 30-90 днів, або при підозрі на компрометацію будь-якого учасника.

Архітектура production MPC-гаманця

Типова 2-of-3 схема для мобільного гаманця

┌──────────────────────────────────────────────────────┐
│  User Device (Mobile)   │  Company Server  │  Backup  │
│  Share 1 (локально,     │  Share 2         │  Share 3 │
│  зашифрован біометрією) │  (HSM/TEE)       │  (MPC    │
│                         │                  │  backup) │
└──────────────────────────────────────────────────────┘

Signing: Device + Server (2-of-3)
Recovery: Device + Backup або Server + Backup

Користувач втратив телефон → відновлення через Server + Backup шарди. Сервер взломаний → немає шансу без Device або Backup. Це модель ZenGo та аналогічних non-custodial MPC гаманців.

Компоненти системи

Key generation service. Реалізує DKG (Distributed Key Generation) протокол між учасниками. Результат: кожен учасник отримує свій share, ніхто не знає повного ключа. Реалізації: tss-lib (Binance, Go), multi-party-ecdsa (ZenGo, Rust), threshold-sig-lib (Fireblocks internal).

// ZenGo's curv + tss-lib приклад (Rust)
use curv::elliptic::curves::{Secp256k1, Point, Scalar};
use multi_party_ecdsa::protocols::multi_party_ecdsa::gg_2020::party_i::*;

// Phase 1: кожна сторона генерує commitment
let party1_keys = Keys::create(1);
let (commit1, decom1) = party1_keys.phase1_broadcast_phase3_proof_of_correct_key();

// Phase 2: обмін commitments, обчислення vss
// Phase 3-5: verification та фіналізація shares
// Результат: party1_keys.u_i — приватний share сторони 1

Signing service. Оркеструє signing sessions між учасниками. Повинен підтримувати: concurrent sessions (кілька транзакцій паралельно), timeout handling (якщо учасник не відповідає), session ID для кореляції повідомлень.

Communication layer. Зашифрований P2P канал між учасниками. TLS + додаткове end-to-end шифрування повідомлень протоколу. Неможливо використовувати незашифрований канал: проміжні повідомлення містять часткові значення, які при накопленні можуть витекти share.

HSM/TEE integration. Серверний share зберігається в HSM (AWS CloudHSM, Thales) або TEE (Intel SGX, ARM TrustZone). Критично: операції з share виконуються всередині захищеного середовища, share ніколи не виходить у відкриту пам'ять. Azure Key Vault Managed HSM та AWS CloudHSM підтримують користувацькі операції з ключами через PKCS#11 interface.

Протокол відновлення

Важливий аспект UX: як користувач відновлює доступ без seed phrase.

Social recovery MPC. Backup share зашифрований ключами довірених осіб (guardians). Для відновлення потрібна згода M з N guardians. Реалізація: backup share шифрується через threshold encryption для guardian set. Guardian може бути: інший пристрій користувача, email сервіс (через KMS), довіреної друг (через його публічний ключ), recovery service.

KMS-based backup. Backup share зашифрований через користувацький KMS ключ. Для відновлення: пройти KYC/authentication через KMS provider → розшифрувати backup share → виконати re-sharing з новим device share.

Підтримка ланцюгів: multi-curve MPC

Різні блокчейни використовують різні еліптичні криві:

TSS для ed25519 відрізняється від secp256k1: використовує схему на основі Schnorr підписів (FROST protocol — Flexible Round-Optimized Schnorr Threshold). FROST простіший у реалізації, більш ефективний в комунікації. Для production multi-chain гаманця потрібно підтримувати обидва.

Hierarchical Deterministic (HD) у MPC контексті. Класичний BIP32 неможливо застосувати напрямку: немає єдиного seed. Рішення: threshold BIP32 — кожна сторона зберігає свій share для master private key, child key derivation виконується через MPC операції або через зберігання окремих shares для кожного derived path (менш ефективно, але простіше).

Безпека та аудит

Attack Vectors

Malicious party in signing protocol. Учасник може намагатися отримати інформацію про чужі shares через аномальні повідомлення. Захист: range proofs, zero-knowledge докази коректності кожного проміжного значення. CGGMP21 спеціально розроблений з identifiable abort: протокол може довести яка сторона ведеться дурницькі.

Replay attack на signing sessions. Перехоплені повідомлення однієї signing session не повинні використовуватися в іншій. Захист: session ID включається в кожне повідомлення, сесії одноразові.

Side-channel через timing. Реалізації на Java/Python уразливі до timing attacks при операціях з великими числами. Production реалізації повинні використовувати constant-time arithmetic (бібліотека ct-codecs, Rust subtle crate).

Compromised communication channel. TLS з certificate pinning + додаткове authenticated encryption на рівні протоколу (кожне MPC повідомлення підписується довгостроковим ключем відправника).

Рекомендації аудиту

MPC протокол — криптографічно складний компонент. Аудит повинен включати:

• Перевірку коректності реалізації конкретного протоколу (GG20/CGGMP21) відносно паперу
• Аналіз side-channel стійкості
• Fuzz testing signing sessions з аномальними повідомленнями
• Verifiable key generation (публічний ключ збігається з очікуваним)

Провайдери для MPC аудиту: NCC Group, Kudelski Security, спеціалізуються на криптографічних реалізаціях.

Ready-Made Libraries vs Custom Implementation

Рекомендація: для більшості проектів — інтеграція з Web3Auth MPC Core Kit або Fireblocks MPC SDK замість написання з нуля. Кастомна реалізація MPC протоколу потребує глибокої експертизи в прикладній криптографії і займає 6–12 місяців. Помилка в MPC реалізації = потенційна утечка приватних ключів користувачів.

Етапи розробки

Мінімальний production-ready MPC гаманець (2-of-2, один ланцюг, базовий recovery) — 4–5 місяців. Повнофункціональний multi-chain з social recovery та HSM — 8–12 місяців.