משמורת מוסדית על ביטקוין ב-Google Cloud

כדי להגן על רזרבות הביטקוין של המוסד בלי ליצור נקודת פגיעה אחת, אפשר להפיץ את מפתחות החתימה בין מובלעות מבודדות ברמת החומרה באמצעות Google Cloud חישוב רב-משתתפים. במסמך הזה אנחנו משווים בין Cloud Key Management Service‏ (Cloud KMS) ו-Cloud HSM לבין חישוב רב-משתתפים, בוחנים את שני מודלי האבטחה למשמורת על ביטקוין ומציגים טופולוגיית עזר.

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

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

שירותי Cloud KMS ו-Cloud HSM תומכים בהצפנת מעטפה ארגונית ובתשתית של מפתח ציבורי באינטרנט. עם זאת, הם לא תוכננו לפרימיטיבים של משמורת ביטקוין, כמו גזירת מפתחות דטרמיניסטית היררכית (HD) במסגרת הצעת השיפור של ביטקוין 32 (BIP32), חתימת Schnorr של BIP340 וניהול מפורט של מספר גורמים.

האתגרים העיקריים בשמירה על ביטקוין בענן

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

דרישה מגבלה ב-Cloud KMS וב-Cloud HSM איך חישוב רב-משתתפים עונה על הדרישה הזו
הפקת מפתחות BIP32

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

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

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

בארנקים עם מפתח יחיד, אם גם מפתח ציבורי מורחב של הורה (xpub) וגם מפתח פרטי של צאצא לא מוקשח נחשפים, תוקף יכול לחשב את המפתח הפרטי של ההורה. חישוב רב-משתתפים מסיר את החשיפה הזו כי מפתחות פרטיים צאצאים (kchild) לא מורכבים בטקסט פשוט. הם קיימים רק כחלקים מקומיים מבוזרים וזמניים (s1', s2') בתוך זיכרון TEE שמוצפן בחומרה.
נקודת פריצה אחת

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

המפתח הפרטי המלא לא קיים כטקסט פשוט באף מיקום. החלקים של המפתח מופצים באופן מתמטי בין צומתי מחשוב עצמאיים.
גמישות אלגוריתמית (Schnorr ו-Taproot)

מחזורי החומרה הפיזיים של HSM הם איטיים. כדי להוסיף תמיכה בעקומות אליפטיות או בסכימות חתימה כמו BIP340 Schnorr בעקומה secp256k1, נדרש אישור מחדש של החומרה למשך כמה שנים.

פעולות קריפטוגרפיות פועלות בתוך מובלעות של Confidential VM שמבודדות ברמת החומרה, וכך אפשר להשתמש בחישוב רב-משתתפים כדי לעדכן פרוטוקולים בלי לשנות את הגבול הפיזי של ה-HSM.

השוואה בין Cloud KMS לבין חישוב רב-משתתפים

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

מודל Cloud KMS ו-Cloud HSM עם מפתח יחיד

בפריסה של Cloud KMS, ‏ Cloud HSM יוצר מפתח חתימה אסימטרי שמשתמש באלגוריתם EC_SIGN_SECP256K1_SHA256 ישירות בתוך HSM פיזי עם אישור FIPS 140-2 ברמה 3. באיור הבא אפשר לראות איך שכבת האפליקציה יוצרת אינטראקציה עם Cloud HSM כשמפיקים מפתחות צאצא:

שתי שכבות האפליקציות של VM רגילות שמקיימות אינטראקציה עם גבול Cloud HSM FIPS 140-2 ברמה 3, שבו נגזרת צאצא מוקשחת חושפת את מפתח ההורה בזיכרון המארח.

הארכיטקטורה הזו מספקת אימות מנוהל של FIPS 140-2 ברמה 3, ומפיקה חתימות מנורמלות של secp256k1 אלגוריתם חתימה דיגיטלית של עקום אליפטי (ECDSA)‎ עם S נמוך, שרשת הביטקוין מקבלת. עם זאת, יש שתי מגבלות ארכיטקטוניות למשמורת על ביטקוין:

  • פרגמנטציה של ניהול מפתחות: מכיוון ש-Cloud HSM לא יכול לחשב נתיבי גזירה של BIP32, האפליקציה צריכה לעקוב אחרי מיליוני מזהי משאבים נפרדים של CryptoKey ב-Cloud KMS, ולהסיר תהליכי עבודה של שחזור משורש יחיד.
  • סיכון לחשיפת הזיכרון: כדי לבצע גזירה מוקשחת, האפליקציה צריכה לייצא את ה-seed הבסיסי לזיכרון המארח, מה שפוגע בהיקף האבטחה של החומרה.

מודל סף של חישוב רב-משתתפים מבוזר

בחישוב רב-משתתפים מוטמעת גרסה מוקשחת של פרוטוקול ECDSA עם סף DKLS23. במקום ליצור מפתח אחד שלם, צמתים עצמאיים שפועלים בתוך Confidential Space במובלעות מוצפנות בחומרה של AMD SEV-SNP יוצרים ומחזיקים נתחי מפתחות מתמטיים. למידע נוסף על הפרוטוקול, ראו רקע קריפטוגרפי של DKLS23.

באיור הבא מוצג איך החתימה מופצת בחישוב רב-משתתפים בין צומתי TEE שמגובים במפתחות הצפנה של מפתחות HSM עצמאיים:

בקשה לעסקת ביטקוין מנותבת לשני צומתי TEE שמריצים את פרוטוקול DKLS23 ופורקים את חלקי המפתח באמצעות Cloud HSM ו-Cloud EKM.

למודל הסף המבוזר הזה יש שלושה יתרונות אבטחה עיקריים:

  • אין מפתח פרטי מלא: אין מכשיר פיזי, מובלעת או מפעיל שמחזיקים במפתח הפרטי המלא.
  • שורש אמון (root of trust) מעוגן בחומרה: חלקי המפתחות מוצפנים במנוחה באמצעות מפתחות להצפנת מפתחות (KEK) שמוגנים על ידי מחיצות Cloud HSM עם אישור FIPS 140-2 ברמה 3, או על ידי מודולי אבטחה לחומרה (HSM) מקומיים חיצוניים שמחוברים באמצעות Cloud External Key Manager.
  • פענוח באמצעות אימות: Cloud KMS פותח את המפתחות ששותפו בזיכרון של המובלעת רק כשציטוט של אימות חומרה מאשר שהצומת מריץ קובצי אימג' מאומתים של קונטיינר Multi-party Compute שלא בוצעו בהם שינויים.

מנגנונים קריפטוגרפיים ל-BIP32 ול-Taproot

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

גזירה אדיטיבית לא מוקשחת של BIP32

ב-BIP32, הנגזרת של מפתח פרטי צאצא לא מוקשח מוגדרת כתוספת סקלרית מודולרית:

\[ k_{\text{child} } = (k_{\text{par} } + \text{parse}_{256}(I_L)) \bmod n \]

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

צומת 1 וצומת 2 מחשבים באופן עצמאי את השינוי הסקלרי של HMAC-SHA512 באופן מקומי, מעדכנים את חלק 1 תוך שמירה על חלק 2 ללא שינוי, ומפעילים סשן חתימה אונליין של DKLS23.

שינוי מפתח Taproot לפי BIP341

המאפיין הליניארי הזה תומך גם בשינוי מפתח Taproot של BIP341 בלי לשנות את ההפצה של שיתוף המפתחות הבסיסי:

\[ Q = P + t \cdot G \quad \text{where} \quad t = H_{\text{TapTweak} }(P \parallel \text{MerkleRoot}) \]

לפני ההשתתפות בטקס החתימה על הסף, צומת משתתף מחיל את השינוי הסקלרי (t) ישירות על שיתוף המפתח המקומי שלו. היכולת הזו מאפשרת לכם לבצע פעולות בעצי סקריפטים של Taproot, ב-Ordinals וב-Discreet Log Contracts בלי ליצור מחדש או לשתף מחדש מפתחות.

השוואה בין ארכיטקטורות

בטבלה הבאה מוצגת השוואה בין Cloud KMS ו-Cloud HSM לבין חישוב רב-משתתפים, לפי מאפייני המשמורת העיקריים.

מאפיין ארכיטקטוני ‫Cloud KMS ו-Cloud HSM חישוב רב-משתתפים
פרימיטיבים קריפטוגרפיים ECDSA עם חתימה אחת בעקומת secp256k1 ‫Threshold ECDSA‏ (DKLS23) ו-Threshold Edwards-curve Digital Signature Algorithm‏ (EdDSA) בעקומת Ed25519, עם אפשרות הרחבה ל-Threshold Schnorr בעקומת secp256k1
גבולות החומרה כרטיס PCIe HSM פיזי מובלעות AMD SEV-SNP Confidential Space שעוגנו ב-Cloud HSM root of trust
תמיכה בארנק BIP32 HD ניהול ידני של מפתחות Cloud KMS נפרדים שינוי מקומי של שיתוף מפתחות אדיטיביים ללא סבבים
הגנה על מפתח פיזי ‫FIPS 140-2 ברמה 3 ‫FIPS 140-2 ברמה 3 למפתחות KEK ששמורים ב-HSM ועוטפים את חלקי המפתחות
זמן אחזור של חתימה (p95) ‫20-50 אלפיות השנייה פחות מ-1,000 אלפיות השנייה (פחות משנייה) באזורים מבוזרים
היקף ההשפעה של פריצה לפרטי כניסה חשיפה מלאה של המפתח אם פרטי הכניסה של מבצע הקריאה או כללי המדיניות של ניהול זהויות והרשאות גישה (IAM) נחשפים אין חתימה לא מורשית, אלא אם תוקף פורץ למספר מסוים של מובלעות ו-KEK בו-זמנית
יכולת ביקורת יומני ביקורת של Cloud יומני ביקורת של Cloud ויומני אימות חומרה של הצדקות גישה למפתחות (KAJ)

ההתפתחות מ-BIP32 לניהול מפתחות סף

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

ההקשר ההיסטורי של ארנקי BIP32 עם גרעין יחיד

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

  • תלות ב-Root seed: בתחילת הדרך, משמורת על ביטקוין התבססה על אבטחה פיזית של ביטוי תזכורת יחיד שקריא לאנשים, באורך של 12 או 24 מילים.
  • שחזור מגיבוי יחיד: ארנקי BIP32 HD מאפשרים לאדם פרטי לגבות ביטוי סיד אחד ולהפיק כתובות באופן דטרמיניסטי בכמה חשבונות.
  • נקודת כשל בודדת: ביטוי ה-seed המנמוני הבסיסי מייצג נקודת כשל בודדת. אם תוקף מצליח לפרוץ לביטוי או לגיבוי הפיזי, כל המפתחות הפרטיים המשניים שנגזרו ממנו בכל החשבונות נחשפים.

האיור הבא ממחיש איך פריצה ל-seed בודד של שורש חושפת כל חשבון צאצא שנגזר ממנו:

ביטוי סיד בסיסי של 12 או 24 מילים שמתפצל למפתח צאצא 1, מפתח צאצא 2 ומפתח צאצא N, כך שחשיפת הסיד חושפת את כל המפתחות הפרטיים של הצאצאים שנגזרו ממנו.

הסרת ה-root seed באמצעות חתימה עם סף

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

השוואה בין נתיבי גזירה של BIP32 בחישוב רב-משתתפים

אם השילוב שלכם דורש תאימות ל-BIP32 בשביל מעקבי כתובות חיצוניים או תהליכי עבודה של הנהלת חשבונות, השוו בין שני נתיבי ההטמעה הטכניים בטבלה הבאה.

שיטת הטמעה מנגנון קריפטוגרפי פרופיל אבטחה וחשיפה זמן אחזור וביצועי חתימה
‫BIP32 לא מוקשח עם חישוב רב-משתתפים

כוונון מקומי של תוספים: s1' = (s1 + IL) mod n.

כל צומת מחשב את היסט הסקלר הציבורי (IL) באופן עצמאי ומחיל את ההיסט הזה על שיתוף המפתח המקומי שלו.
  • סיכון של מפתח יחיד: בארנקים שאינם MPC, פריצה למפתח ציבורי ראשי (xpub) ולמפתח פרטי משני מאפשרת לתוקף לחשב לאחור את המפתח הפרטי הראשי.
  • הפחתת סיכונים באמצעות MPC: המפתחות הפרטיים הצאצאים (kchild) לא מורכבים בטקסט פשוט, והם קיימים רק כחלקים זמניים ומבוזרים של מפתחות (s1',‏ s2') בתוך זיכרון TEE שמוצפן בחומרה. כך נמנע שחזור של מפתחות צאצאים למפתחות הורים.
  • לא נדרשים סבבי תקשורת ברשת בין צומתי MPC כדי להפיק מפתחות צאצא.
  • הוא פועל במהירות המעבד המקומי לפני החתימה.
  • תמיכה בזמן אחזור של פחות משנייה לחתימה (p95 פחות משנייה אחת) בערוצי gRPC מוצפנים.
‫BIP32 מוקשח עם חישוב רב-משתתפים

גיבוב (hash) אינטראקטיבי של HMAC-SHA512 עם מספר משתתפים, שמחושב על חומר מפתח הורה שמשותף באופן סודי.
  • הגנה מפני הסלמת מפתחות מצאצא להורה באמצעות גיבוב (hashing) של המפתח הפרטי של ההורה, מה שמוסיף מורכבות משמעותית לפרוטוקול.
  • לא מספקת יתרון אבטחה נוסף בסביבת מובלעת מרובת-משתתפים שבה מפתח ההורה כבר משותף באופן סודי ומוגן מפני זליגת מידע.
  • נדרשים כמה סבבים של רשת אינטראקטיבית בין צומתי MPC כדי להעריך מעגל HMAC-SHA512 של סף על קלט של סודות משותפים.
  • מאריך את זמן האחזור של החתימה ויוצר צווארי בקבוק בעיבוד העסקאות.

המלצות למשמורת מוסדית

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

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