החתימה בחישוב רב-משתתפים מתבצעת באמצעות שני אלגוריתמים של מפתחות: ECDSA ב-secp256k1 ו-EdDSA ב-Ed25519 (בקרוב). בדף הזה מוסבר על פרוטוקול ECDSA עם סף, DKLS23, ועל השינויים ש-Google ביצעה בו. כאן אפשר למצוא את האלגוריתמים הנתמכים.
Threshold ECDSA ו-DKLS23
בניגוד לסכמות חתימה אחרות, הבעיה של חתימת סף עבור ECDSA הייתה קשה באופן ידוע לשמצה. עד 2017, רוב הפתרונות כללו פשרות משמעותיות.
בשנת 2018, DKLS הציגו את הפתרון הראשון לחתימה של 2 מתוך 2 ל-ECDSA שהסתמך רק על הנחות קריפטוגרפיות שמבוססות על ECDSA (למשל, לא נדרשו Paillier, RSA או משפחה אחרת של הנחות קריפטוגרפיות קשות). הרעיון פורץ הדרך בפרוטוקול הזה היה דרך חדשה לטעון לאבטחה מפני תוכנות זדוניות בגישה שמבוססת על MPC (ניסיונות קודמים ליישם שיטות MPC גנריות לאבטחה מפני תוכנות זדוניות הובילו לפרוטוקולים שנדרשו דקות להפעיל אותם במקום אלפיות השנייה).
שיפורים נוספים של אותם מחברים הובילו לפרוטוקול k-out-of-n, ולבסוף השיפור של DKLS23 הוביל למסגרת גנרית ל-ECDSA עם סף k-out-of-n ב-3 סבבים, שכללה את כל הגישות הקודמות וזיהתה את גישת DKLS כיעילה ביותר לפי מדדי ביצועים בולטים. באופן ספציפי, הגרסה הזו של הפרוטוקול מסתמכת רק על פרימיטיבים של התחייבות אידיאלית וכפל בין שני צדדים. הפרוטוקול שנוצר דורש חישוב של מילישניות בודדות לכל צד (מה שמוביל למהירות גבוהה יותר בסדרי גודל בהשוואה לגישות מתחרות), וחשוב מכך, הוא מסתמך על פרימיטיבים קריפטוגרפיים פשוטים יותר שמשתמשים רק בפעולות של עקומות אליפטיות (בניגוד לפעולות הומומורפיות יקרות של Paillier, והוכחות יקרות של טווח אפס-ידע והוכחות של תקינות של מפתחות קריפטוגרפיים שנדרשות בעבודות אחרות).
הפרוטוקול נבדק באופן פנימי על ידי כמה גורמי ביקורת, כולל מומחים שנשכרו על ידי Coinbase ומומחי קריפטוגרפיה אחרים. דורנר ורוי DR26 זיהו לאחרונה חישוב שגוי בניתוח האבטחה של מכפיל DKLS, שדורש 22 הפעלות נוספות של OT כדי להשיג את 120 הביטים של האבטחה שנטענו. השינוי הזה נכנס לתוקף. באופן דומה, מבקרי מערכות חיצוניים אחרים הצביעו על פרטים חסרים בתיאור הפרוטוקול בנוגע להשלכות של שידור במודל הערוץ חיבור מנקודה לנקודה (במיוחד, חשוב להדהד כמה פרמטרים של הגדרה כדי להשיג ידע משותף).
העבודה שנעשתה לאחר מכן ב-Google על הפרוטוקול הקשיחה באופן משמעותי את ההטמעה, הפחיתה את המשאבים הנדרשים להפעלת הפרוטוקול בקנה מידה נרחב והרחיבה את הפונקציונליות של הסכימה. לדוגמה, בספרות האקדמית לא מפורטים מספיק הבחירה וההטמעה של אורקל אקראי. למרות שמדובר בהפשטה אקדמית שימושית, ההטמעה של Random Oracle היא משימה מורכבת שהובילה לכמה פגמים שתועדו בביקורות אבטחה.
היבט בולט בעבודה שלנו היה לפתח מערכת טיפוסים (שמבוססת על שתי פעולות של spawn ו-fork, וגם שימוש קפדני במערכות טיפוסים כדי למנוע העתקה, העברה וכינוי של מצביעים לאורקלים) כדי להבטיח שכל סשן וסשן משנה משתמשים באורקל אקראי אחר.
שיפור חשוב נוסף קשור לבחירה של מזהי סשנים ומזהי סשני משנה. מודל ה-UC, ולכן כל הפרוטוקולים שהוכחו כמאובטחים במודל הזה, דורשים שהסביבה תספק מזהי סשן חדשים. בפועל, המערכת צריכה לוודא שהיריב לא יכול להפר את ההנחה הזו, ולשם כך בדרך כלל המשתתפים צריכים לשמור על מצב בלתי מוגבל. הוספנו לפרוטוקול DKLS המקורי סבבים נוספים כדי לבחור את המזהה הזה באופן שדורש רק מצב בגודל קבוע.
בסך הכול, הפרוטוקול המעודכן והמוקשח עדיין משלים פעולת חתימה תוך עשרות אלפיות השנייה.
מבחינת הפונקציונליות, המאמר DKLS23 מתייחס רק למבנה הגישה הרגיל של סף k-out-of-n. בפועל, יכול להיות שהלקוחות יצטרכו מבנה גישה שמחקה את הכללים הארגוניים. בספרות הקריפטוגרפית יש הרבה גישות לתכנון מבני גישה לשיתוף סודות. כאן הרחבנו את פרוטוקול DKLS כדי לתמוך במבני גישה כלליים יותר, שאפשר ליצור משערי threshold-k-out-of-n. כך אפשר להגדיר כללי מדיניות כמו "2 מתוך 3 הקבוצות הבאות: (א) הלקוח, (ב) 2 מתוך 10 קציני בקרת הסיכונים, (ג) 2 מתוך 3 ראשי המחלקות של הכספים, המשפטים וראיית החשבון" וכו'.
ב-API בגרסת v1beta, מגדירים את מבנה הגישה הזה בתור מדיניות המפתחות של KeyRing, בשדה keyPolicy. כל מפתח שנוצר ב-KeyRing משתמש בה. במדיניות מפתחות יכולות להיות עד שתי רמות: כלל הסף ברמה הבסיסית (root) וכללי סף ישירות מתחתיו. כלל סף ברמה הבסיסית לא יכול להכיל כלל סף אחר.