פיתוח ארנק MPC: ניהול מפתחות מבוזר

אנו מפתחים ארנקים מבוססי חישוב רב-צדדי (MPC) לניהול מפתחות מבוזר ללא נקודת כשל אחת. ארנקי קריפטו מסורתיים מחזיקים מפתח פרטי במקום אחד: מכשיר, HSM או ענן. כל פגיעה משמעותה אובדן כספים. חישוב רב-צדדי פותר זאת מהיסוד: המפתח הפרטי לעולם אינו קיים בשלמותו באף מערכת. במקום זאת, מספר צדדים מחזיקים חלקי מפתח ומחשבים יחד חתימה מבלי לחשוף את חלקיהם זה לזה.

זה לא multisig. ב-multisig, חתימת עסקה דורשת M מתוך N חתימות, כל אחת גלויה על השרשרת. ב-MPC, החתימה הסופית נראית כמו חתימת ECDSA רגילה של מפתח יחיד. ללא תקורה על השרשרת, ללא שינויי פרוטוקול. זה קריטי עבור: עלויות גז נמוכות יותר (30% פחות מ-multisig), פרטיות (מסתיר את סכמת ניהול המפתחות), ותאימות לכל שרשרת או dApp. במשך למעלה מ-5 שנים בפיתוח בלוקצ'יין, סיפקנו 30+ פרויקטים, כולל ארנקי MPC לפרוטוקולי DeFi מובילים.

ארנקי MPC יעילים פי 1.43 בגז מאשר multisig, וחוסכים 300$ לחודש עבור פרוטוקול המעבד 10,000 עסקאות ב-0.10$ כל אחת.

כיצד פועל המתמטיקה של ארנק MPC

חלוקת סוד של שאמיר וסכמות סף

ארנקי MPC מסתמכים על סכמות חתימת סף (TSS). הנפוצות ביותר הן GG18, GG20 (Gennaro-Goldfeder), CGGMP (Canetti-Gennaro-Goldfeder-Makriyannis-Peled), ו-DKLS.

חלוקת סוד של שאמיר היא מושג בסיסי, לא TSS עצמו. ב-SSS, סוד מחולק ל-N חלקים; M מתוך N מספיקים לשחזור. בעיה: שחזור דורש הרכבה של חלקים במקום אחד – נקודת תורפה. TSS מבטל זאת: החתימה מחושבת ללא שחזור המפתח.

ECDSA סף (אנו משתמשים ב-secp256k1 כמו בביטקוין/אתריום):

יהי המפתח הפרטי d = d1 + d2 (mod q) עבור סכמת 2-מתוך-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: חישוב ישיר ידרוש חשיפת 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 подпись או k1. לכן, אנו משתמשים ב-Oblivious Transfer, הצפנת Paillier, או פרוטוקולים מבוססי Curve25519 לחישוב מאובטח.

פרוטוקולים: GG20 לעומת CGGMP

GG20 – זמן רב היה הסטנדרט דה-פקטו. בשימוש ב-Fireblocks, ZenGo, Coinbase Wallet. תומך בסף t-of-n עבור t ו-n שרירותיים. דורש הצפנת Paillier לכפל מאובטח. חסרונות: יישום מורכב, keygen יקר (תקשורת O(n²)), פגיעות להתקפת rogue key הדורשת range proofs שמגדילות את גודל ההודעה. GG20 דורש 15 סבבי תקשורת לחתימה.

CGGMP – המצב-של-האמנות הנוכחי. מתקן את הפגיעויות של GG20, חתימה יעילה יותר (3 סבבים במקום 15). תומך ב-identifiable abort – אם צד מתנהג שלא כראוי, ניתן לזהותו עם הוכחה קריפטוגרפית.

DKLS – חלופה מבוססת Oblivious Transfer. הודעות קומפקטיות יותר, אך פחות יישומי ייצור.

רענון מפתחות

פעולה קריטית: עדכון תקופתי של חלקי מפתח ללא שינוי המפתח הציבורי (ומכאן ללא שינוי כתובת). אם תוקף פוגע בחלק אחד אך לא השיג חתימה סופית לפני הרענון, הפגיעה מנוטרלת.

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

תדירות רענון מומלצת: כל 30–90 יום, או בחשד לפגיעה בכל משתתף.

ארכיטקטורת ארנק MPC בייצור

סכמת 2-מתוך-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

משתמש מאבד טלפון → שחזור באמצעות חלקי שרת + גיבוי. שרת נפרץ → אין גישה ללא מכשיר או גיבוי. זה המודל שבו משתמשים ZenGo וארנקי MPC דומים שאינם נאמנים.

רכיבי מערכת

• שירות יצירת מפתחות. מיישם פרוטוקול Distributed Key Generation (DKG) בין משתתפים. תוצאה: כל משתתף מקבל את חלקו (32 בתים), אף אחד לא יודע את המפתח המלא. יישומים: k2 (Binance, Go), 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 (ZenGo, Rust), ┌──────────────────────────────────────────────────────┐ │ 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 (Fireblocks פנימי).

// 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

• שירות חתימה. מתזמן סשני חתימה בין משתתפים. חייב לתמוך ב: סשנים מקבילים (מספר עסקאות במקביל), טיפול ב-timeout (אם משתתף לא מגיב), מזהי סשן לקורלציית הודעות.

• שכבת תקשורת. ערוץ P2P מוצפן בין משתתפים. TLS + הצפנה נוספת מקצה-לקצה של הודעות פרוטוקול. לא ניתן להשתמש בערוצים לא מוצפנים: הודעות ביניים מכילות ערכים חלקיים שעלולים לדלוף חלקים אם יצטברו.

• שילוב HSM/TEE. חלק השרת מאוחסן ב-HSM (AWS CloudHSM, Thales) או TEE (Intel SGX, ARM TrustZone). קריטי: פעולות חלק מבוצעות בתוך הסביבה המאובטחת; החלק לעולם אינו עוזב את הזיכרון הזה. Azure Key Vault Managed HSM ו-AWS CloudHSM תומכים בפעולות מפתח מותאמות אישית דרך ממשק PKCS#11.

פרוטוקול שחזור

היבט UX קריטי: כיצד המשתמש משחזר גישה ללא ביטוי גיבוי.

• שחזור חברתי עם MPC. חלק הגיבוי מוצפן עם מפתחות של שומרים מהימנים. שחזור דורש הסכמה של M מתוך N שומרים. יישום: חלק הגיבוי מוצפן באמצעות הצפנת סף עבור קבוצת השומרים. שומר יכול להיות: מכשיר משתמש אחר, שירות דוא"ל (דרך KMS), חבר מהימן (דרך המפתח הציבורי שלו), או שירות שחזור.

• גיבוי מבוסס KMS. חלק הגיבוי מוצפן עם מפתח KMS של המשתמש. שחזור: עמידה ב-KYC/אימות דרך ספק KMS → פענוח חלק הגיבוי → ביצוע re-sharing עם חלק מכשיר חדש.

תמיכה רב-שרשרתית: MPC רב-עקומתי

בלוקצ'יין שונים משתמשים בעקומות אליפטיות שונות:

TSS עבור ed25519 שונה מ-secp256k1: הוא משתמש בסכמה מבוססת חתימת Schnorr (FROST – Flexible Round-Optimized Schnorr Threshold). FROST פשוט יותר ליישום ויעיל יותר בתקשורת (3 סבבים, כמו CGGMP). עבור ארנק רב-שרשרתי בייצור, יש לתמוך בשניהם.

Hierarchical Deterministic (HD) בהקשר MPC. BIP32 קלאסי לא ניתן ליישום ישיר: אין זרע יחיד. פתרון: threshold BIP32 – כל צד מאחסן את חלקו עבור מפתח האב הפרטי; גזירת מפתחות ילדים מתבצעת דרך פעולות MPC או על ידי אחסון חלקים נפרדים לכל נתיב נגזר (פחות יעיל אך פשוט יותר).

אבטחה והמלצות ביקורת

וקטורי התקפה

• צד זדוני בפרוטוקול החתימה. משתתף עלול לנסות ללמוד על חלקיהם של אחרים דרך הודעות חריגות. הגנה: range proofs, הוכחות אפס-ידע לנכונות כל ערך ביניים. CGGMP תוכנן במיוחד עם identifiable abort: הפרוטוקול יכול להוכיח איזה צד התנהג שלא כראוי.

• התקפת replay על סשני חתימה. הודעות שיורטו מסשן חתימה אחד אסור שיהיו שמישות באחר. הגנה: מזהה סשן כלול בכל הודעה; סשנים הם חד-פעמיים.

• ערוץ צדדי דרך תזמון. יישומים ב-Java/Python פגיעים להתקפות תזמון על פעולות מספרים גדולים. יישומי ייצור חייבים להשתמש בחשבון בזמן קבוע (ספריית tss-lib, crate multi-party-ecdsa ב-Rust).

• ערוץ תקשורת שנפגם. TLS עם הצמדת אישורים בתוספת הצפנה מאומתת נוספת ברמת הפרוטוקול (כל הודעת MPC חתומה עם המפתח ארוך-הטווח של השולח).

המלצות ביקורת

פרוטוקול MPC מורכב קריפטוגרפית. הביקורת חייבת לכלול:

• אימות נכונות היישום הספציפי (GG20/CGGMP) מול המאמר
• ניתוח עמידות לערוצים צדדיים
• בדיקות fuzz של סשני חתימה עם הודעות חריגות
• יצירת מפתחות ניתנת לאימות (המפתח הציבורי תואם למצופה)

ספקי ביקורת ל-MPC: NCC Group, Kudelski Security, המתמחים ביישומים קריפטוגרפיים.

Gennaro & Goldfeder מראים ש-ECDSA סף אפשרי ללא שחזור המפתח המלא, וזה הבסיס לארנקי MPC בייצור.

בהשוואה ל-multisig, ארנקי MPC מפחיתים עלויות גז ב-30% ומפחיתים את מורכבות האינטראקציה על השרשרת. החתימה הסופית אינה ניתנת להבחנה מחתימת ECDSA רגילה, מה שהופך את MPC לאידיאלי לפתרונות DeFi פרטיים.

ספריות מוכנות לעומת יישום מותאם אישית

ההמלצה שלנו: עבור רוב הפרויקטים, השתלבו עם Web3Auth MPC Core Kit או Fireblocks MPC SDK במקום לכתוב מאפס. יישום פרוטוקול MPC מותאם אישית דורש מומחיות עמוקה בקריפטוגרפיה יישומית ואורך 6–12 חודשים. שגיאה ביישום MPC = דליפה פוטנציאלית של מפתחות פרטיים של משתמשים.

מה כלול בעבודה שלנו

• תיעוד ארכיטקטורה עם בחירת פרוטוקול, סכמת אחסון חלקים ומודל שחזור.
• יישום MPC ליבה: keygen, חתימה, רענון מפתחות מבוסס ספרייה מוכחת.
• שילוב HSM/TEE עבור חלק המפתח של השרת.
• תמיכה רב-שרשרתית: ECDSA, EdDSA, גזירת HD.
• יישום זרימת שחזור: שחזור חברתי או גיבוי מבוסס KMS.
• ביקורת קריפטוגרפית על ידי שותפים (NCC Group, Kudelski Security).
• SDK ליישומים ניידים ואינטרנט.
• תמיכה וניטור לאחר השחרור.

אנו גם מספקים הכשרה לצוות הלקוח על שימוש מאובטח בארנק MPC.

שלבי פיתוח

ארנק MPC מינימלי מוכן לייצור (2-מתוך-2, שרשרת אחת, שחזור בסיסי) אורך 4–5 חודשים. ארנק רב-שרשרתי מלא עם שחזור חברתי ו-HSM אורך 8–12 חודשים. עלות פרויקט אופיינית נעה בין 150,000$ ל-400,000$ בהתאם למורכבות.

צרו קשר כדי לדון בפרויקט שלכם. קבלו ייעוץ על פתרון MPC עבור פרוטוקול ה-DeFi או יישום הקריפטו שלכם.