סקירה כללית על אימות מרחוק

אימות (attestation) מרחוק הוא תהליך שבו מוודאים שהזהות של מופע Confidential VM היא לגיטימית, ושהוא פועל במצב הצפוי. אימות יכול לעזור לכם להעריך את מהימנות המערכת לפני שתעניקו לה גישה למשאבים המוגנים שלכם.

צדדים ומודלים של אימות

בדרך כלל יש שלושה גורמים בתהליך האימות:

  • גורם מאשר. ב- Google Cloud, זהו עומס עבודה במכונה וירטואלית חסויה שנדרשת לו גישה למשאבים מוגנים. כדי להגביר את הביטחון בכך שמכונת Confidential VM לא נפרצה ושהיא לא מתחזה למכונה אחרת, המכונה הווירטואלית והמארח שלה מבצעים מדידות של מצב החומרה והתוכנה הווירטואליים של המכונה במהלך תהליך האתחול.

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

    המאמת יכול להיות שירות קיים כמו Google Cloud Attestation או Intel Trust Authority, או משהו שבניתם בעצמכם.

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

    ב- Google Cloud הצד הנסמך הוא לרוב מאגר זהויות של עומסי עבודה, והמאמת מתווסף כספק OpenID Connect‏ (OIDC).

אופן האינטראקציה בין הצדדים תלוי במודל האימות שהארכיטקטורה שלכם פועלת לפיו. במסמך Remote ATtestation procedureS (RATS) Architecture RFC מוגדרים שני מודלים עיקריים לאימות: מודל הדרכון ומודל בדיקת הרקע. ההבדל העיקרי בין שתי השיטות הוא מי מחזיק בזהות המאומתת של המאמת: המאמת או הצד המסתמך.

דגם הדרכון

מודל הדרכון משתמש בתהליך הבא כדי לאשר את הזהות של הגורם המאשר ולהעניק גישה למשאבים המבוקשים:

  1. הגורם המאשר שולח ראיות לזהות שלו לגורם מאמת.

  2. אם הראיות נחשבות מהימנות, המאמת שולח למאומת את תוצאת האימות, שיכולה להיות בצורה של אסימון אימות.

  3. הגורם המאשר שולח את תוצאת האימות לצד שלישי שנסמך על האימות.

  4. הצד המסתמך בודק שתוצאת האימות עומדת בתנאים מסוימים. אם התוצאה תואמת לציפיות, הצד המסתמך מאפשר למאמת גישה למשאבים המבוקשים.

במודל הדרכון, הגורם המאשר והצד המסתמך צריכים להסכים על המראה של תוצאות האישור, כלומר הם צריכים להסכים על מאמת.

מודל של דרכון הצהרה

מודל בדיקת רקע

מודל בדיקת הרקע משתמש בתהליך הבא כדי לאמת את הזהות של מי שמעיד על עצמו ולאשר גישה למשאבים המבוקשים:

  1. המאמת שולח הוכחה לזהות שלו לצד נסמך.

  2. האתר שמוגדר כ-Relying Party מעביר את ההוכחה למאמת.

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

  4. הצד המסתמך בודק שתוצאת האימות עומדת בתנאים מסוימים. אם התוצאה תואמת לציפיות, הצד המסתמך מאפשר למאמת גישה למשאבים המבוקשים.

מודל בדיקת רקע של הצהרה

במודל של בדיקת הרקע, צד מסתמך קובע את הראיות לאימות שהוא צריך ובוחר את המאמת.

ארכיטקטורה וראיות של מאשרים

בקטע הזה מוסבר איך מופקת ממופע של Confidential VM עדות עמידה בפני שינויים לא מורשים, שמאמתת את הזהות שלו.

שורשי אמון

בסביבת מחשוב אמינה (TEE) כמו מופע של Confidential VM, ‏ root of trust הוא רכיב אבטחה בסיסי שממנו נובע אמון אחר. בסיס מהימנות מספק פונקציות קריפטוגרפיות, הוא עמיד בפני שיבוש ולא ניתן לשנות אותו על ידי מערכת הפעלה של מארח.

שורשי האמון שייכים לגבולות האמון בתוך TEE, שנקראים Trusted Computing Base ‏ (TCB). ה-TCB הוא אוסף של חומרה ותוכנה במכונה וירטואלית אורחת ובמארח שלה, שאחראים על משימות כמו בידוד הסביבה (באמצעות מנגנונים כמו הצפנת זיכרון ובידוד היפר-ויזורי) וביצוע מדידות כדי לשמור על שלמות הסביבה.

סביבת TEE תומכת ב-Roots of Trust לפונקציות של מדידה, אחסון ודיווח:

  • ה-root of trust למדידה הוא הקוד שמתחיל את המדידות של תהליך האתחול של TEE.

  • ה-Root of Trust לאחסון מספק זיכרון מוגן למדידות בצורה של רגיסטרים של מדידות.

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

בהמשך מפורטות הגישות השונות לשורשי אמון בטכנולוגיות שונות של Confidential Computing.

AMD SEV

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

השורשים של האמון הם:

  • Root of trust for measurement: קושחה של מכונה וירטואלית

  • Root of trust לאחסון: vTPM של מכונה וירטואלית מוגנת

  • בסיס מהימן לדיווח: vTPM של מכונה וירטואלית מוגנת, שמשתמש במפתח אימות פרטי כדי לחתום על דוחות אימות

SEV root of trust

מידע על המדידות שמתועדות ב-vTPM של מכונה וירטואלית מוגנת זמין במאמר בנושא רישומים של תצורת פלטפורמת vTPM.

AMD SEV-SNP

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

למדידות של טוען האתחול, הליבה וסביבת המשתמש, אפשר להשתמש במדידות מבוססות vTPM של מכונה וירטואלית מוגנת.

השורשים של האמון הם:

  • Root of trust for measurement: AMD Secure Processor + VM instance firmware

  • Root of trust לאחסון: AMD Secure Processor + מכונה וירטואלית מוגנת vTPM

  • Root of trust for reporting:

    • מדידות של ההפעלה הראשונית: המעבד המאובטח של AMD, שמשתמש במפתח אישור השבב (VCEK) שמוטמע בשבב כדי לחתום על דוחות אימות

    • מדידות של תוכנת האתחול, הליבה ומרחב המשתמש: vTPM של מכונה וירטואלית מוגנת

שורש מהימנות של SNP

כדי ללמוד אילו מדידות נרשמות במעבד המאובטח של AMD, אפשר לעיין במאמר בנושא רישום מדידות של AMD SEV-SNP.

מידע על המדידות שמתועדות ב-vTPM של מכונה וירטואלית מוגנת זמין במאמר בנושא רישומים של תצורת פלטפורמת vTPM.

Intel TDX

מכונה וירטואלית מסוג Confidential VM עם Intel TDX מאמתת את הסביבה וההגדרה שלה באמצעות מודול Intel TDX. מודול Intel TDX מודד את הקושחה של מכונת האורח (VM) בתוך דומיין מהימן מבודד, ומאחסן את המדידות האלה ב-Measurement of the Trust Domain (MRTD). מדידות עוקבות בשרשרת האתחול נמדדות ברישומים של מדידת זמן הריצה (RTMR).

השורשים של האמון הם:

  • Root of trust for measurement: Intel TDX module

  • Root of trust for storage: Measurement of the Trust Domain (MRTD) and Run-Time Measurement Registers (RTMR)

  • בסיס מהימן לדיווח: ה-Trust Domain Quoting Enclave‏ (TDQE) בתוך מודול Intel TDX, שיוצר מפתח אישור לחתימה על ציטוטי אישור

TDX root of trust

כדי ללמוד אילו מדידות מתועדות איפה ברישומים של מדידת TDX, אפשר לעיין במאמר רישומים של מדידת Intel TDX.

אימות של תוכנה וחומרה

אפשר לחשוב על טכנולוגיות של Confidential Computing ב- Google Cloud כעל תוכנה או חומרה מאומתות, בהתאם ל-Root of Trust שלהן.

תוכנה מאומתת פירושה ששורשי המהימנות מבוססים על תוכנה: הקושחה הווירטואלית היא שורש המהימנות למדידה, וה-vTPM של המכונה הווירטואלית המוגנת הוא שורש המהימנות לאחסון. ה-vTPM מנוהל על ידי hypervisor של המארח, והקושחה מנוהלת על ידי מכונת ה-VM של האורח. ב- Google Cloud, שני הרכיבים האלה נשלטים על ידי Google.

אימות חומרה פירושו שהמדידות מנוהלות ומוגנות על ידי חומרה ייעודית שלא נמצאת בשליטת ספק השירות. ב- Google Cloud, החומרה הזו כוללת את AMD Secure Processor ל-AMD SEV-SNP (למדידות השקה בלבד) ואת Intel TDX Module ל-Intel TDX.

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

טכנולוגיות Confidential Computing ש- Google Cloud מספקת מחולקות לקטגוריות הבאות:

  • ‫AMD SEV: תוכנה מאומתת. הקושחה הווירטואלית מודדת את עצמה, והמדידות נשמרות ב-vTPM של Shielded VM.

  • ‫AMD SEV-SNP: אימות היברידי של חומרה ותוכנה. מדידות של ההפעלה, כולל מדידות של הקושחה הווירטואלית, מתועדות ונשמרות במעבד המאובטח של AMD, ולכן הן מאומתות על ידי החומרה. המדידות של טוען האתחול, הליבה ומרחב המשתמש מאוחסנות ב-vTPM של המכונה הווירטואלית המוגנת, ולכן הן מאומתות על ידי התוכנה. אתם יכולים לבחור להשתמש רק במדידות שמאומתות על ידי החומרה, רק במדידות שמאומתות על ידי התוכנה או בשניהם.

  • ‫Intel TDX: אימות חומרה. מודול TDX מודד את הקושחה הווירטואלית, וכל המדידות מאוחסנות במודול Intel TDX. מודול ה-vTPM של מכונה וירטואלית מוגנת עדיין מהווה חלק מהמערכת, אבל הוא לא חלק מ-TCB אלא אם מריצים תוכנה שזקוקה לממשק TPM.

רישום של מדידות

ה-Roots of Trust של מכונות וירטואליות חסויות מספקות אחסון מוגן ועמיד בפני שינויים של מדידות בצורה של רשומות מדידה (MR). השם של רשומות המדידה האלה משתנה בהתאם לטכנולוגיית Confidential Computing שבשימוש:

  • ‫AMD SEV: Platform configuration registers (PCRs). הם ממוקמים בתוך vTPM של מכונה וירטואלית מוגנת.

    ב-vTPM של מכונה וירטואלית מוגנת נעשה שימוש בשלושה בנקים של PCR שמאחסנים את אותם המדידות, אבל הם מגובבים באמצעות אלגוריתמים שונים: SHA-1,‏ SHA-256 ו-SHA-384.

  • ‫AMD SEV-SNP: ההשקה MEASUREMENT register. הוא ממוקם בתוך המעבד המאובטח של AMD.

    בנוסף, נעשה שימוש ב-PCR בתוך vTPM של מכונה וירטואלית מוגנת כדי לאחסן את המדידות של טוען האתחול, הליבה ומרחב המשתמש.

  • ‫Intel TDX: מדידה בזמן הבנייה של תחום המהימנות (MRTD) ורישום מדידות בזמן הריצה (RTMR).

    המדדים זמינים גם ב-PCR של vTPM במכונות וירטואליות מוגנות עבור תוכנות שמצפות לממשק TPM.

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

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

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

\(MR_{new}=hash(MR_{old}\;∥\;hash(measured\;data))\)

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

יומני אירועים

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

יומני האירועים האלה משמשים למטרות הבאות:

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

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

יומני האירועים מאוחסנים במערכת הקבצים של מערכת ההפעלה של האורח במיקומים הבאים:

טכנולוגיית Confidential Computing בקשות למיזוג שצריך לאמת סוג יומן הביקורת נתיב מערכת ההפעלה של האורח להפעלה מחדש של יומן האירועים
‫AMD SEV, ‏ AMD SEV-SNP, ‏ Intel TDX רשומות תצורת פלטפורמה (PCR) של vTPM יומן אירועים של Trusted Computing Group (TCG) /sys/kernel/security/tpm0/binary_bios_measurements
Intel TDX RTMR[0], RTMR[1], RTMR[2] יומן אירועים של Confidential Computing‏ (CCEL) /sys/firmware/acpi/tables/data/CCEL

מידע נוסף על הפעלה חוזרת וניתוח של יומני אירועים

הצעות מחיר ודוחות אימות

בסיס האמון לדיווח מספק הגנה על השלמות והאותנטיות של התקצירים שמאוחסנים במרשם המדידות, על ידי חתימה על המדידות שלהם באמצעות מפתח אישור. ה-blob הבינארי שמתקבל נקרא PCR quote ב-vTPM,‏ attestation report ב-AMD SEV-SNP ו-quote ב-Intel TDX.

התוכן של ה-blob הבינארי שונה בטכנולוגיות השונות של Confidential Computing:

  • ‫AMD SEV: ה-vTPM של מכונה וירטואלית מוגנת קורא את הערכים מאחד ממאגרי ה-PCR שלה (SHA-1,‏ SHA-256 או SHA-384), משרשר את הערכים האלה בסדר מספרי ואז מגבב את התוצאה באמצעות אותו אלגוריתם גיבוב שבו נעשה שימוש במאגר ה-PCR כדי ליצור תקציר גיבוב. תקציר הסיכום הזה, יחד עם צופן חד-פעמי אופציונלי שסופק על ידי מאמת, מוצב במבנה TPMS_ATTEST ונחתם על ידי מפתח האימות הפרטי של ה-vTPM כדי ליצור קידוד PCR.

    פרטים נוספים על המבנה של TPMS_ATTEST זמינים במאמר Trusted Platform Module Library, Part 2: Structures (PDF).

  • ‫AMD SEV-SNP: מעבד ה-AMD Secure יוצר תקציר SHA-384, על סמך מדידות ההפעלה הראשוניות שלו, שמתבצעות לפני ש-UEFI של מכונה וירטואלית חסויה מופעל.

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

    פרטים על המבנה של ATTESTATION_REPORT זמינים במאמר SEV Secure Nested Paging Firmware ABI Specification (PDF).

  • ‫Intel TDX: מודול ה-TDX ממקם את הערכים של MRTD ו-RTMR, נתונים אחרים של מכונה וירטואלית (VM) וערך אקראי אופציונלי שסופק על ידי מאמת במבנה TDREPORT_STRUCT.

    יצירת הצעת מחיר היא תהליך רב-שלבי. קודם כול, ה-Provisioning Certification Enclave (מובלעת אימות ההקצאה) בתוך המעבד (CPU) גוזר מפתחות אימות הקצאה (PCK) מסודות קריפטוגרפיים שמוטמעים במעבד. לאחר מכן, ה-Quoting Enclave בתוך ה-CPU יוצר מפתח פרטי לאימות, שנחתם באמצעות מפתח האישור להקצאת הרשאות. לאחר מכן, המערכת חותמת על TDREPORT_STRUCT באמצעות מפתח האימות הפרטי כדי ליצור הצעת מחיר.

    פרטים על המבנה של TDREPORT_STRUCT זמינים במאמר Intel Trust Domain Extensions (Intel TDX) Module Base Architecture Specification (PDF).

המלצות

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

אישורים

אישורי X.509 v3 משמשים כהוכחה לשימוש בחומרה מקורית של AMD או Intel במארח, או לכך שמופע Confidential VM משתמש ב-vTPM של מכונה וירטואלית מוגנת.

השם של האישור שונה בכל אחת מהטכנולוגיות של Confidential Computing:

  • ‫AMD SEV: אישור מפתח אימות (AK)

  • ‫AMD SEV-SNP: אישור מפתח אישור שבב (VCEK)

  • ‫Intel TDX: אישור מפתח הקצאת הרשאות (PCK)

ב-AMD SEV, האישור מאמת את ה-vTPM של מכונה וירטואלית מוגנת. המארח שולח בקשה לשרת רשות האישורים של Google, ומקצה באופן אוטומטי את האישור ישירות לאחסון הלא-נדיף של vTPM במופע של Confidential VM. אורח יכול לאחזר את האישור הזה בנפרד על ידי שליחת בקשה ל-vTPM באמצעות תוכנה כמו go-tpm-tools.

ב-AMD SEV-SNP וב-Intel TDX, המארח מחלץ הוכחות חומרה מה-CPU ומציג אותן במטמון שמנוהל על ידי Google. במטמון הזה מאוחסנים אישורים שנמשכו בעבר משירות הפצת המפתחות של AMD ומשירות הקצאת האישורים של Intel. אחרי הצגת הראיות לגבי הציוד, האישורים נשמרים במטמון בדיסק של המארח ומשותפים עם האורח. אורח יכול לאחזר את האישורים האלה בנפרד כדי לאמת חומרה באמצעות תוכנה כמו go-sev-guest ו-go-tdx-guest.

האישורים מכילים את הפרטים הבאים:

  • הזהות של מנפיק האישור, AMD,‏ Google או Intel.

  • מפתח האימות הציבורי, שמאמת את החתימה בקידודים של PCR‏ (vTPM), בדוחות אימות (SEV-SNP) ובקידודים של אימות (Intel TDX).

  • אימות חומרה בלבד: גרסאות ה-TCB של המיקרוקוד והקושחה של החומרה שבה פועלת הקושחה של המארח.

  • אימות חומרה בלבד: ראיות שמקשרות את האישור למעבד פיזי ספציפי, שנחתם באמצעות מפתח פרטי במעבד ולא ניתן לייצא אותו. ב-AMD SEV-SNP, הראיה הזו היא מזהה הפלטפורמה. ב-Intel TDX, ההוכחה היא מניפסט הפלטפורמה.

קושחה

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

כשמכונה וירטואלית מופעלת, מודול AMD Secure Processor או Intel TDX מבצע גיבוב של קובץ הבינארי של הקושחה לפני שהוא מופעל. תקציר ה-SHA-384 הזה מאוחסן בשדה MEASUREMENT עבור AMD SEV-SNP, וב-MRTD עבור Intel TDX.

אפשר להשתמש בערך הגיבוב הזה כדי להוריד אישור הפעלה מ-Google, לאמת שהחתימה מושרשת ב-Google באמצעות כלי כמו gcetcbendorsement, ואז לוודא שערכי הגיבוב של SHA-384 זהים בין המדידה של הקושחה לבין מה שמתועד באישור.

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

מידע נוסף זמין במאמר בנושא אימות הקושחה של מופע Confidential VM.

הפעלה חוזרת וניתוח של יומן האירועים של כלי האימות

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

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

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

יצירת כלים משלכם להפעלה חוזרת ולניתוח של יומן אירועים

אפשר ליצור תוכנה משלכם כדי להפעיל מחדש ולנתח יומני אירועים, אבל אנחנו ממליצים להשתמש בתוכנה מוכרת כמו go-eventlog כדי להימנע מטעויות נפוצות כמו נקודת חולשה EventType בפורמטים של יומני אירועים של Trusted Computing Group ו-Confidential Computing.

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

בדוגמה הבאה יש אירועים נבחרים מיומן האירועים של vTPM ב-Ubuntu 24.04, שנמדדים ב-PCR 0. יומן האירועים הומר מקובץ בינארי ל-ASCII באמצעות tpm2_eventlog באמצעות הפקודה הבאה:

sudo tpm2_eventlog /sys/kernel/security/tpm0/binary_bios_measurements

האירועים של PCR 0 מהיומן הם:

---
version: 1
events:
- EventNum: 0
  PCRIndex: 0
  EventType: EV_NO_ACTION
  Digest: "0000000000000000000000000000000000000000"
  EventSize: 41
  SpecID:
  - Signature: Spec ID Event03
    platformClass: 0
    specVersionMinor: 0
    specVersionMajor: 2
    specErrata: 0
    uintnSize: 2
    numberOfAlgorithms: 3
    Algorithms:
    - Algorithm[0]:
      algorithmId: sha1
      digestSize: 20
    - Algorithm[1]:
      algorithmId: sha256
      digestSize: 32
    - Algorithm[2]:
      algorithmId: sha384
      digestSize: 48
    vendorInfoSize: 0
- EventNum: 1
  PCRIndex: 0
  EventType: EV_NO_ACTION
  DigestCount: 3
  Digests:
  - AlgorithmId: sha1
    Digest: "0000000000000000000000000000000000000000"
  - AlgorithmId: sha256
    Digest: "0000000000000000000000000000000000000000000000000000000000000000"
  - AlgorithmId: sha384
    Digest: "000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000"
  EventSize: 160
  Event: "53503830302d313535204576656e7433792b000056aca511a145224ba54128607dac543b0d476f6f676c652c20496e632e0016476f6f676c6520436f6d7075746520456e67696e650001000d476f6f676c652c20496e632e00792b000004322e37000300000028000000468e85a27fa36a458c790c1fe48b65ff4600690072006d007700610072006500520049004d0000000000000000000000000000000000"
- EventNum: 2
  PCRIndex: 0
  EventType: EV_NO_ACTION
  DigestCount: 3
  Digests:
  - AlgorithmId: sha1
    Digest: "0000000000000000000000000000000000000000"
  - AlgorithmId: sha256
    Digest: "0000000000000000000000000000000000000000000000000000000000000000"
  - AlgorithmId: sha384
    Digest: "000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000"
  EventSize: 288
  Event: "53503830302d313535204576656e7433792b000056aca511a145224ba54128607dac543b0d476f6f676c652c20496e632e0016476f6f676c6520436f6d7075746520456e67696e650001000d476f6f676c652c20496e632e00792b000004322e370001000000a800000068747470733a2f2f73746f726167652e676f6f676c65617069732e636f6d2f6763655f7463625f696e746567726974792f6f766d665f7836345f63736d2f3834383939616564336339653837363735666638303966356665613365366638383733353533643166303130306464623961653333323639323832356163636537333866343562646563323738613430393864316332376534393533373134332e66642e7369676e65640000000000000000000000000000"
- EventNum: 3
  PCRIndex: 0
  EventType: EV_S_CRTM_VERSION
  DigestCount: 3
  Digests:
  - AlgorithmId: sha1
    Digest: "4031fe1129fb826f12dcad169992cca9f4f56aa3"
  - AlgorithmId: sha256
    Digest: "fa129a8f82b65bcbce8f9e8e5f6de509beff9b1df33714116bf918c5a3bba45d"
  - AlgorithmId: sha384
    Digest: "21d340a4a30bb8865486d150cd9ceb46100662b92f336d38b87d70b373ca15c4c60878336924baa818dc2aceaeb40ea6"
  EventSize: 48
  Event: "47004300450020005600690072007400750061006c0020004600690072006d0077006100720065002000760032000000"
- EventNum: 4
  PCRIndex: 0
  EventType: EV_NONHOST_INFO
  DigestCount: 3
  Digests:
  - AlgorithmId: sha1
    Digest: "2b106cedd1631981619790bbc1afaa80cc6ecd3e"
  - AlgorithmId: sha256
    Digest: "6ac9241348a80c5755a63bcd1865b9f6d5720f6e925dc869bb4694281c1510c5"
  - AlgorithmId: sha384
    Digest: "1167e32c3814259ea4809234cccfbd2785c32bde882833bb199d6df6bd989a49f45663e63ce11699fcd01250050f042c"
  EventSize: 32
  Event: "474345204e6f6e486f7374496e666f0001000000000000000000000000000000"
- EventNum: 19
  PCRIndex: 0
  EventType: EV_SEPARATOR
  DigestCount: 3
  Digests:
  - AlgorithmId: sha1
    Digest: "9069ca78e7450a285173431b3e52c5c25299e473"
  - AlgorithmId: sha256
    Digest: "df3f619804a92fdb4057192dc43dd748ea778adc52bc498ce80524c014b81119"
  - AlgorithmId: sha384
    Digest: "394341b7182cd227c5c6b07ef8000cdfd86136c4292b8e576573ad7ed9ae41019f5818b4b971c9effc60e1ad9f1289f0"
  EventSize: 4
  Event: "00000000"

כשמאפסים את מכונת ה-VM הסודית, ערכי ה-PCR שלה מאותחלים לאפס. כשהאירועים מתרחשים, הערך בבנק SHA-256 של PCR 0 ‏ (PCRIndex: 0) משתנה באופן הבא (אירועי EV_NO_ACTION לא מרחיבים את הרישום):

  1. הערך של הרגיסטר משורשר לסיכום הגיבוב (digest) מסוג SHA-256 של האירוע הבא שמוקצה ל-PCR 0, ‏ EV_S_CRTM_VERSION. התוצאה המשורשרת מגובבת שוב באמצעות SHA-256, ואז מאוחסנת במרשם. הגיבוב ההקסדצימלי של PCR 0 לפי SHA-256 הוא עכשיו 0c3684a7571193d76a68e489ded7bf186fc2fb1efe0c6dd9ce147960bbc57365.

  2. אותו תהליך משמש לאירוע EV_NONHOST_INFO. הגיבוב ההקסדצימלי של PCR 0 לפי SHA-256 הוא עכשיו 509f590b71fb22c9a6eef647e3c23611d13e599a6e15fdbb4db56ea4c2cb878d.

  3. אותו תהליך משמש גם לאירוע EV_SEPARATOR, שמציין שההרשמה הספציפית הושלמה. הערך של EV_SEPARATOR הוא אפס (\x00*4) ב-32 ביט. לכן, הגיבוב הסופי של SHA-256 בפורמט הקסדצימלי של PCR 0 הוא a0b5ff3383a1116bd7dc6df177c0c2d433b9ee1813ea958fa5d166a202cb2a85.

קוד ה-Python הבא מדגים את התהליך הקודם על ידי יצירת PCR 0 מדומה של Compute Engine. הקוד לא משחזר יומן אירועים, כי הוא גוזר את תקצירי האירועים שלו מערכים ידועים. כשיוצרים הפעלה חוזרת של יומן אירועים, צריך לקרוא את התקצירים מיומן האירועים של מכונת ה-VM.

import hashlib

def CalculatePCR0(version_num: int, mem_encrypt_enum: int):
  """Calculates the expected SHA-256 PCR 0 value given the
  Compute Engine firmware version and Confidential Computing technology
  that's in use.

  This code uses derived values for events instead of reading digests from an
  event log. It's intended to demonstrate how to simulate the extend function
  used in measurement registers.

  While the code should provide correct values for PCR 0 in
  Compute Engine VM instances, for other PCRs and true event log replay
  you should read in digests from an event log instead of using derived values.

  PCR 0 measurements include:
    * EV_S_CRTM_VERSION: The firmware version string, in UTF-16 little-endian
      form. This value remains stable as long as the firmware version stays the
      same.
    * EV_NONHOST_INFO: This value changes based on the Confidential Computing
      technology that's in use.
    * EV_SEPARATOR: A 32-bit zero value to split UEFI and bootloader
      measurements.

  Args:
    version_num (int): The Compute Engine firmware version number. The
      value is 2.

    mem_encrypt_enum (int): The type of Confidential Computing technology used
      on the VM:

      0: None
      1: AMD SEV
      2: AMD SEV-ES
      3: Intel TDX
      4: AMD SEV-SNP

  Returns:
    A hexstring representing the expected PCR 0 digest.
  """
  # Create a hash object to act as PCR 0, and initialize it with zeroes.
  h = hashlib.sha256()
  h.update(b'\x00' * h.digest_size)

  # Update the hash object with the EV_S_CRTM_VERSION event, with a hard-coded
  # firmware version `version_num`.
  #
  # This code uses derived values for events. To use the digest supplied in an
  # event log for event log replay, you need to read in the event digest, and
  # then convert it to bytes before updating the hash object, similar to the
  # following:
  #
  # h.update(bytes.fromhex('fa129a8f82b65bcbce8f9e8e5f6de509beff9b1df33714116bf918c5a3bba45d'))
  #
  h.update(
          hashlib.sha256(
              # The firmware uses UCS-2 encoding, so we match it by encoding to
              # the equivalent UTF-16 little-endian. An extra null byte is
              # needed to match the required byte length.
              f'GCE Virtual Firmware v{version_num}\x00'.encode('utf-16-le')).digest()
          )

  # Create a new hash object to act as PCR 0 and update it with the previous
  # hash object's digest. This simulates the first part of the register EXTEND
  # function.
  h2 = hashlib.sha256()

  h2.update(h.digest())

  # Update the hash object with the EV_NONHOST_INFO event, which includes
  # `mem_encrypt_enum`, the Confidential Computing technology in use. Performing
  # this update completes the simulated EXTEND function.

  h2.update(
          hashlib.sha256(
              b'GCE NonHostInfo\x00'
              + (mem_encrypt_enum).to_bytes(1, byteorder='little')
              + (b'\x00' * 15)
              ).digest()
          )

  # Create a new hash object to act as PCR 0 and update it with the previous
  # hash object's digest. This simulates the first part of the register EXTEND
  # function.
  h3 = hashlib.sha256()
  h3.update(h2.digest())

  # Update the hash object with the EV_SEPARATOR event. Performing this update
  # completes the simulated EXTEND function.
  h3.update(hashlib.sha256(b'\x00' * 4).digest())

  # There are more PCR 0 events, but they're all `EV_NO_ACTION` and don't
  # affect the register value. Return the final simulated register value.
  digest = h3.hexdigest()
  return digest

print('\nPCR 0 simulation')
print('\nConfidential Computing type\tDigest')
# Compute Engine firmware version 2, no Confidential Computing
# Expected hexdigest: d0c70a9310cd0b55767084333022ce53f42befbb69c059ee6c0a32766f160783
print(f'None\t\t\t\t{CalculatePCR0(2, 0)}')

# Compute Engine firmware version 2, AMD SEV
# Expected hexdigest: a0b5ff3383a1116bd7dc6df177c0c2d433b9ee1813ea958fa5d166a202cb2a85
print(f'AMD SEV\t\t\t\t{CalculatePCR0(2, 1)}')

# Compute Engine firmware version 2, AMD SEV-SNP
# Expected hexdigest: 50597a27846e91d025eef597abbc89f72bff9af849094db97b0684d8bc4c515e
print(f'AMD SEV-SNP\t\t\t{CalculatePCR0(2, 4)}')

# Compute Engine firmware version 2, Intel TDX
# Expected hexdigest: 0cca9ec161b09288802e5a112255d21340ed5b797f5fe29cecccfd8f67b9f802
print(f'Intel TDX\t\t\t{CalculatePCR0(2, 3)}')

print()

הגדרות של צד נסמך

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

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

תבנית נפוצה להגדרת צד נסמך ב- Google Cloud היא שימוש באיחוד שירותי אימות הזהות של עומסי עבודה, והתייחסות למאמת כזהות מאוחדת:

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

  2. מגדירים את הערכים שצריכים להיות זהים בטענות האימות של המאמת כדי שהמאשר יקבל גישה למשאבים.

    ב- Google Cloud, התהליך הזה כולל מיפוי של הצהרות אימות למאפיינים, כדי שמערכת ניהול הזהויות והרשאות הגישה (IAM) תוכל לעבד אותן כתנאים שזהות מאוחדת צריכה לעמוד בהם כדי לעבור אימות כחשבון משתמש.

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

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