Google Cloud חישוב רב-משתתפים מספק תשתית קריפטוגרפית מהימנה לפעולות בנכסים דיגיטליים של מוסדות. הוא משתמש בארכיטקטורה של ריבוי דיירים יחידים: כל מכונה שאתם יוצרים היא סביבה ייעודית ומבודדת עם תעבורת נתונים נכנסת (ingress) משלה ברשת, אחסון משלה וחישוב מבודד חומרה משלה לפעולות קריפטוגרפיות.
רכיבי ליבה
לכל מכונה של חישוב רב-משתתפים יש שלושה רכיבים עיקריים. לוגיקת הפיקוח, ניתוב הבקשות והחישובים הקריפטוגרפיים פועלים ברכיבים נפרדים.
MPC API
ה-Multi-party Compute API מנהל את המשאבים הבאים:
- משתמשים וצוותים: הזהויות שמחזיקות בתפקידים במכונה, וקבוצות החותמים שאליהן מתייחסות כללי המדיניות של המפתחות.
- אוספי מפתחות ומדיניות מפתחות: אוספי המפתחות שמקבצים מפתחות, כל אחד עם מדיניות המפתחות שקובעת אילו צוותים ומשתמשים מחזיקים במניות מפתח וכמה מהם חייבים לאשר חתימה.
- TransactionPolicies: כללי Cedar שמאפשרים או אוסרים על עסקאות, והאישורים של מחבר המדיניות שמפעילים או משביתים אותם.
- KeyLists: רשימות של כתובות עם שמות, שכללי המדיניות של העסקאות יכולים להתייחס אליהן.
ה-Multi-party Compute API עוקב אחרי המצב של כל עסקה והאישורים שמתועדים בה, ומבקש מהרכז לתזמר את יצירת המפתחות והחתימה. Spanner מאחסן את הבקשות ואת האישורים החתומים. סביבות TEE של עובדים מאמתות בעצמן את חתימות האישור לפני שהן פועלות לפיהן.
רכז
Multi-party Compute API מחבר את הבקר ל-TEE של המשתתפים:
- זיהוי שיתופים של מפתחות וניתוב בקשות: הוא מקצה סביבות TEE תקינות לשמירת שיתופים חדשים של מפתחות במהלך יצירת המפתחות, ולאחר מכן מנתב את הבקשה לסביבות ה-TEE המתאימות.
- תקינות: מעקב אחרי התקינות של סביבות ה-TEE של המשתתפים ואיזון עומסים של הבקשות לחתימה.
- עמידות: ניהול השיתוף מחדש כשצריך להחליף חלק מהמפתח.
ה-Coordinator לא משפיע על אבטחת הפרוטוקול. הוא לא מחזיק בחלקים של מפתחות, והוא לא מאמת אישורים או תוצאות של מדיניות. האימות הזה מתבצע בתוך סביבות ה-TEE של המשתתפים.
סביבות TEE של עובדים
כל Worker הוא TEE שפועל ב-Confidential Space. ב-Worker TEE פועלים שני חלקים:
- מנוע קריפטוגרפי: מכיל את חלקי המפתח ומריץ את הפרוטוקולים המאובטחים של יצירת מפתחות סף וחתימה עם סביבות ה-TEE האחרות של ה-Worker.
- מעריך המדיניות: מעריך את העסקאות בהתאם לקבוצת כללי המדיניות הפעילים בנושא עסקאות.
תהליך החתימה על העסקה
בחישוב רב-משתתפים, חותמים על מטען ייעודי (payload) באמצעות קריאה אחת ל-API, CreateTransaction. הערכת מדיניות העסקאות, אישורי החותמים וחתימת הסף מתחילים בקריאה הזו. זה התהליך בסדר קבוע:
- בקשה. החתימה שולחת קריאה ל-
CreateTransactionבמפתח. הבקשה כוללת את האישור של החותם, שחתום באמצעות מפתח ההרשאה שלו. מערכת IAM בודקת אם המתקשר יכול להפעיל את ה-method, והבקשה מתועדת ביומני הביקורת של Cloud. - הערכת מדיניות. העסקה נבדקת בהתאם לקבוצה הפעילה של כללי המדיניות בנושא עסקאות. בדיקת המדיניות יוצרת יומן ביקורת עמיד לכל החלטה,
APPROVEDאוREJECTED. - אישור של יוזם השיחה. אם האישור של היוזם לבדו עומד בדרישות הסף של מדיניות המפתחות,
CreateTransactionעובר מיד לשלב 5. - אישורים של החותמים. אם האישור של היוזם לבדו לא עומד בדרישות הסף של מדיניות המפתחות, העסקה עוברת למצב
PENDING_AUTHORIZATION. חותמים אחרים שמחזיקים בחלקים מהמפתח מאשרים או דוחים את העסקה באמצעות קריאה ל-RecordSignerDecision, וכל אחד מהם חותם באמצעות מפתח ההרשאה שלו. העסקה ממתינה במצבPENDING_AUTHORIZATIONעד שמספיק חותמים מאשרים אותה כדי לעמוד בדרישות הסף של מדיניות המפתחות. אם מספיק בעלי חתימה דוחים את העסקה כך שלא ניתן יותר לעמוד בסף, העסקה עוברת למצבREJECTED. אם הוא לא יקבל מספיק אישורים לפני שתוקף ההצעה יפוג, הואEXPIRED. חתימה עם סף. כשהתנאים מתקיימים, סביבות המחשוב האמינות (TEE) שמכילות את החלקים של המפתח מריצות את פרוטוקול החתימה ומפיקות את החתימה על העסקה.
לפני שסביבת TEE משתתפת משתמשת בחלק שלה במפתח, היא בודקת שהמטען הייעודי המדויק שהיא מתבקשת לחתום עליו נבדק מול מדיניות העסקאות שלכם. אף לקוח, מפעיל או רכיב שירות אחר לא יכול לגרום למשתתף לחתום על מטען ייעודי (payload) שלא נבדק.
למידע על המשאבים שמעורבים, כמו משתמשים, צוותים, אוספי מפתחות ומדיניות טרנזקציות, קראו את הסקירה הכללית על חישוב רב-משתתפים.
מודל אבטחה
- חלקים של המפתח מוצמדים ל-TEE שלהם. כל חלק של מפתח יכול להיקרא רק על ידי ה-TEE שיצר אותו. חלקי המפתחות אף פעם לא יוצאים מסביבת ה-TEE הזו בפורמט שרכיב אחר יכול לקרוא, כולל הרכז, הבקר או מפעיל של Google.
- שמירת מפתחות של לקוחות. הלקוח שומר על בעלות מלאה על מפתחות ההצפנה שלו בכל שלב, באמצעות Cloud Key Management Service בארגון של הלקוח ב- Google Cloud .
- בידוד חומרה. סביבות ה-TEE של המשתתפים פועלות ב-Confidential Space, שמשתמש בהצפנת זיכרון בחומרה כדי להגן על הנתונים שבשימוש מפני המארח ומפני התשתית של Google. האימות מקשר כל TEE לקובץ אימג' מאומת של קונטיינר.
- הצפנה מקצה לקצה. סביבות ה-TEE של ה-Worker מתקשרות ישירות באמצעות gRPC שמוצפן מקצה לקצה.
- אישורים חתומים. חותמים, כותבי מדיניות ואדמינים חותמים על האישורים שלהם באמצעות מפתח הרשאה שהחלק הפרטי שלו אף פעם לא עוזב אותם. סביבות ה-TEE של המשתתפים מאמתות את החתימות האלה לפני שהן חותמות על עסקה, מאשרות מדיניות של עסקאות או מאשרות שינוי בתפקיד של אדמין או של מחבר מדיניות. כך העסקאות חסינות לחבלות ונוצר יומן ביקורת עמיד.
- קוורום של כותבי מדיניות. מדיניות עסקאות חדשה, או בקשה להשבית מדיניות קיימת, נכנסת לתוקף רק אחרי שמספר כותבי המדיניות הנדרש מאשר אותה.
- קוורום של אדמינים. הענקה או הסרה של התפקיד "אדמין" או "יוצר מדיניות" נכנסת לתוקף רק אחרי שמספר האדמינים הנדרש מאשר אותה. מידע נוסף זמין במאמר אישור אדמין לשינויים בתפקידים.
מפת דרכים
היכולות הבאות מתוכננות לגרסאות עתידיות:
- סביבות TEE חיצוניות: חלקי מפתחות ששמורים בסביבות TEE שהלקוחות מפעילים מחוץ ל- Google Cloud, כמו AWS Nitro Enclaves.
- חלקים של מפתחות בנייד: חלקים של מפתחות ששמורים במכשירים הניידים של המשתמשים.
- שיתוף מחדש: שינוי הבעלים של החלקים של מפתח קיים, או החלפת חלק שאבד, בלי לשנות את המפתח.
מאפייני מערכת
תשתית האמון של חישוב רב-משתתפים שומרת על מאפייני המערכת הבאים.
בטיחות (תקינות בהקשר קריפטוגרפי)
בכל מקרה, המערכת לא יכולה להתנהג באופן אסור. לדוגמה, קבוצה של פחות מ-k משתתפים לא יכולה לזייף חתימות, בזכות פרוטוקול DKLS23. הגדרות האבטחה המדויקות מנוסחות במסגרת Universal Composable בספרות.
כשמערכת קריפטוגרפית מגולמת בהטמעה מעשית, צריך להיזהר לא להסתמך על הנחות שפוגעות במאפייני האבטחה. לדוגמה, כל צד בפרוטוקול חייב להיות עצמאי: הפגיעות שלו לפריצה צריכה להיות עצמאית.
כדי להבטיח את המאפיין הזה, חישוב רב-משתתפים מריץ כל משתתף בסביבת TEE מאומתת, וכל שיתוף מפתחות מוצמד לסביבת ה-TEE שיצרה אותו. אם אחד מהמשתתפים בפרוטוקול נפגע, זה לא משפיע על המשתתפים האחרים.
הספרות האקדמית בנושא חישוב רב-משתתפים מתמקדת כמעט אך ורק בתקינות, ומניחה עולם פשטני שבו קבוצת המשתתפים לא ניתנת לשינוי, כל המשתתפים זמינים תמיד, והמשתתפים מתקשרים באמצעות ערוצים אידיאליים ומאומתים של חיבור מנקודה לנקודה שתמיד זמינים. במוצר בעולם האמיתי, צריך להתייחס לכמה שיקולים נוספים.
זיהוי פנים פעיל
בסופו של דבר המערכת מתקדמת. המאפיין הכי בנאלי של חיוּת הוא היעדר מבוי סתום, שמתקיים בפרוטוקול DKLS23. אפשר להשתמש במפתח סף לחתימה כל עוד יש מספיק סביבות TEE שמכילות את החלקים שלו כדי לעמוד בדרישות הסף של מדיניות המפתח. לדוגמה, במפתח של 2 מתוך 3, כל 2 מתוך 3 החלקים יכולים להשלים חתימה.
עמידות
צריך להחליף את הגורמים שנכשלו באופן סופי, אחרת המערכת תאבד בסופו של דבר את הסוד המשותף באופן סופי. לדוגמה, אם החומרה נכשלת, המצב של המשתתף שפועל בחומרה הזו אובד. מכיוון שחלקים של מפתחות מוצמדים לסביבות ה-TEE שלהם, שירות התיאום עוקב אחרי סביבות ה-TEE שמכילות את החלקים של כל מפתח. בגרסה v1beta, אפשר להשתמש במפתח כל עוד נשאר מספר מספיק של שיתופים כדי לעמוד בדרישות הסף של מדיניות המפתח. כדי להחליף שיתוף שאבד, צריך לשתף מחדש. אנחנו מתכננים להוסיף את האפשרות הזו בגרסה עתידית.
שינויים בהגדרות
גם תקלות בחומרה (אובדן נתונים ב-TEE) וגם שינויים ארגוניים (עובד חדש מצטרף לפרוטוקול עם חלק מהמפתח הסודי) מחייבים שינוי של הגורמים שמחזיקים בחלקים של המפתח. בחישוב רב-משתתפים, התמיכה בכך תתבצע באמצעות פרוטוקול שיתוף מחדש מאובטח ששומר על מאפייני התקינות של DKLS23: גורם זדוני חדש שמשתתף בשיתוף מחדש מדליף לכל היותר חלק אחד של הסוד, כמו כל גורם זדוני אחר.