סקירה כללית על חישוב רב-משתתפים

חישוב רב-משתתפים הוא פלטפורמת Google Cloud משמורת למפתחות חתימה של נכסים דיגיטליים. הוא משלב חתימה על סף, אכיפת מדיניות עסקאות ואמצעי בקרה על ממשל ארגוני.

למה כדאי להשתמש בחתימה מבוססת-סף

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

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

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

חישוב רב-משתתפים פותר את הבעיה הזו באמצעות סכמות של חתימות סף, כולל תוסף מוקשח של פרוטוקול DKLS23. גורמים עצמאיים שמגובים בחומרה יוצרים ומחזיקים כל אחד חלק מבודד של מפתח. במהלך החתימה, הגורמים האלה מריצים פרוטוקול מרובה גורמים כדי ליצור חתימה חוקית בלי להרכיב את המפתח הפרטי המלא במיקום אחד. תוקף שפורץ לפחות גורמים מסף החתימה לא יכול לזייף חתימה או לשחזר את המפתח. במקביל, פעולות החתימה נמשכות גם אם גורמים מסוימים לא זמינים או נכשלים באופן סופי, כל עוד נותרו מספיק גורמים כדי לעמוד בסף. למידע נוסף על הפרוטוקול, ראו רקע קריפטוגרפי של DKLS23.

רשתות בלוקצ'יין נתמכות

בחישוב רב-משתתפים אפשר להשתמש באלגוריתמים הבאים של מפתחות:

אלגוריתם עקומה רשתות אופייניות
ECDSA (EC_SIGN_SECP256K1) secp256k1 רשתות שתואמות לביטקוין, ל-Ethereum ול-EVM
EdDSA (EC_SIGN_ED25519) Ed25519 ‫Solana (בקרוב)

אחרי שנוצר מפתח מבוזר, Multi-party Compute מחזיר את המפתח הציבורי שלו ואת כתובות הבלוקצ'יין שנגזרות ממנו.

אמצעי בקרה לארגונים

מודלים של חישוב רב-משתתפים בארגון שלכם במכונה ייעודית ומבודדת משלכם. הוא קובע מי מחזיק בחלקים של המפתח, כמה מהם צריכים לאשר חתימה, ואילו כללים חלים על כל עסקה לפני החתימה.

משתמשים ותפקידים

משתמש הוא זהות שאתם מוסיפים למכונה. כל משתמש מקושר לחשבון ראשי אחד, או לחשבון Google או לחשבון ראשי של איחוד שירותי אימות הזהות של כוח עבודה. לכל משתמש יש תפקיד אחד או יותר:

  • אדמין: מנהל משתמשים, צוותים ומשאבים אחרים של המכונה.
  • מחבר המדיניות: מחבר ומאשר את כללי המדיניות בנושא עסקאות.
  • חותם: מחזיק בחלקים של המפתח ומאשר עסקאות.

חותמים, מחברי מדיניות ואדמינים חותמים על האישורים שלהם באמצעות מפתח הרשאה, שהחלק הפרטי שלו אף פעם לא יוצא מהחזקה של הלקוח.

ברמת ה-API, התפקידים של חישוב רב-משתתפים פועלים יחד עם תפקידי IAM. ב-IAM אפשר לקבוע לאילו שיטות API חשבון המשתמש יכול לקרוא. התפקידים של המשתמש קובעים מה הוא יכול לעשות בתוך המכונה. במאמר אבטחה והרשאה מוסבר איך תפקידי IAM ותפקידי משתמשים פועלים יחד.

צוותים

צוות הוא קבוצה של חותמים, כמו מחלקה או קבוצה של בעלי תפקידים. כל חותם שייך לצוות אחד בדיוק. צוותים מאפשרים ל-KeyPolicy להפנות לקבוצות של חותמים, למשל "ליצור מניות מפתח ל-3 חברים בצוות האוצר, ולדרוש שכל 2 מהם יחתמו" במקום לציין את השם של כל אדם.

המדיניות בנושא MPC

אוספי מפתחות ומדיניות מפתחות

KeyRing מקבץ מפתחות. כשיוצרים KeyRing, מגדירים את ה-KeyPolicy שלו, שקובע לכל מפתח שנוצר ב-KeyRing:

  • אילו צוותים ומשתמשים מחזיקים במניות מפתח,
  • כמה מהם צריכים לחתום (הסף), וגם
  • איפה כל חלק של המפתח מאוחסן (Google Cloud, אתר הלקוח או המכשירים הניידים של המשתמשים).

אי אפשר להעביר מפתחות בין אוספי מפתחות או למחוק אותם. אפשר רק להשבית מפתח, וכך למנוע חתימה נוספת.

KeyLists

KeyList היא רשימה עם שם של כתובות בלוקצ'יין שמדיניות העסקאות יכולה להתייחס אליהן, כמו יעדים מהימנים. רשומה היא מפתח קיים, אוסף מפתחות (כולל מפתחות שנוספו אליו מאוחר יותר) או כתובת שמזינים באופן ידני.

כללי המדיניות בנושא עסקאות

מדיניות טרנזקציות היא כלל של Cedar שמתיר או אוסר טרנזקציות בחישוב רב-משתתפים, למשל תקרת הוצאות או רשימת היתרים של יעדים. כל כללי המדיניות הפעילים ביחד יוצרים פסיקה, אישור או דחייה, לכל עסקה. ההחלטה משמשת כהנחיה לחותמים, אבל לא אוכפת את ההחלטה הסופית: עדיין אפשר לבצע עסקה שנדחתה על ידי כללי המדיניות האוטומטיים לעסקאות, אם מספיק חותמים מאשרים אותה.

כדי ללמוד איך לכתוב ולשלב כללים, קראו את המאמרים כתיבת כללים של מדיניות עסקאות והערכת מדיניות עסקאות.