‫Google משתמשת בטכנולוגיית AI כדי לתרגם תוכן לשפה המועדפת עליך. בתרגומים כאלו עשויות להיות שגיאות.

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

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

גורמים ומודלים של אימות (attestation)

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

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

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

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

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

מודל Passport

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

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

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

מודל אימות הדרכון

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

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

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

מודל בדיקת הרקע של האימות (attestation)

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

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

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

שורשי אמון

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

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

סביבת TEE תומכת בפונקציות של Root of Trust‏ ‏(RoT) למדידה, לאחסון ולדיווח:

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

מונח מפתח: מתקפת שידור חוזר היא מצב שבו גורם זדוני מעתיק הוכחה שמאמתת זהות, ומשתמש בה כדי לקבל גישה לא חוקית למשאבים. אחת הדרכים להתמודד עם מתקפות Replay היא באמצעות מספר חד-פעמי: מספר אקראי חד-פעמי לטווח קצר, שמסופק על ידי אחד מהגורמים שמגנים על המשאבים – במקרה של Confidential Computing, הגורם המאמת. הישות שמוכיחה את הזהות שלה צריכה לשלב את המספר החד-פעמי בהוכחה לפני שהיא שולחת אותה. אם גורם זדוני ינסה להשתמש בהוכחה גנובה כדי לגשת למשאבים, סביר להניח שהוא ייכשל כי כבר נעשה שימוש ב-nonce שכלול בהוכחה או שתוקפו פג.

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

AMD SEV

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

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

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

שורש האמון של SEV

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

AMD SEV-SNP

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

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

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

שורש האמון למדידה: מעבד מאובטח של AMD + קושחה של מכונה וירטואלית
שורש האמון לאחסון: מעבד מאובטח של AMD‏ + vTPM של מכונה וירטואלית מוגנת
שורש האמון לדיווח:
- מדידות ההפעלה הראשונית: מעבד AMD Secure, שמשתמש במפתח Version Chip Endorsement Key‏ (VCEK) שמוטמע בשבב כדי לחתום על דוחות האימות.
- מדידות של תוכנת האתחול, הליבה ומרחב המשתמש: vTPM של מכונה וירטואלית מוגנת

שורש האמון של SNP

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

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

Intel TDX

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

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

שורש האמון למדידה: מודול Intel TDX
Root of Trust לאחסון: מדידה של מתחם האמון (MRTD) ורגיסטרים של מדידה בזמן ריצה (RTMR)
שורש האמון לדיווח: Trust Domain Quoting Enclave‏ (TDQE) בתוך מודול Intel TDX, שיוצר מפתח אימות כדי לחתום על ציטוטי אימות

TDX root of trust

כדי לדעת אילו מדידות מתועדות בכל אחד מרגיסטרי המדידה של TDX, קראו את המאמר רגיסטרי המדידה של Intel TDX.

‫Root of Trust בחומרה ובתוכנה

רמת הבידוד מה-hypervisor המארח תלויה בשאלה אם שרשרת האימות מעוגנת ב-Root of Trust של תוכנה או ב-Root of Trust של חומרה:

‫Root of Trust של תוכנה (תלוי ב-hypervisor): שרשרת האמון מתחילה בתוכנה שמנוהלת על ידי ספק שירותי הענן. הקושחה הווירטואלית של האורח פועלת כשורש האמון למדידה, וה-vTPM של המכונה הווירטואלית המוגנת של ה-hypervisor המארח פועל כשורש האמון לאחסון ולדיווח. ב- Google Cloud, שני הרכיבים נשלטים על ידי Google.
Hardware root of trust (מבודד hypervisor): שרשרת האמון מתחילה בתת-מערכות ייעודיות לאבטחת המעבד (CPU) מחוץ לשליטה של ספק שירותי הענן: מעבד AMD Secure או מודול Intel TDX. החומרה הזו מודדת את המצב הראשוני וחותמת על דוחות אימות או על ציטוטים באמצעות מפתחות שמוזגו במעבד או נגזרו ממנו. במעבד, רכיבי תוכנה עוקבים בשרשרת האתחול (כולל הקושחה הווירטואלית ומנהל האתחול) פועלים בתוך זיכרון שמוגן על ידי הצפנת חומרה ובקרות גישה. כך, ה-hypervisor המארח מוסר משורש האמון: גם אם גורם זדוני יפרוץ ל-hypervisor, הוא לא יוכל לשנות את המדידות שמוגנות על ידי החומרה או לזייף דוח אימות.

בהתאם להגדרות של מכונת Confidential VM, אפשר להשתמש באחד או יותר מהמנגנונים הבאים כדי למדוד ולאמת את מצב ההפעלה שלה:

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

ה-vTPM של המכונה הווירטואלית המוגנת מתעד את המדידות של תוכנת האתחול, הליבה ומרחב המשתמשים ב-PCR. מכיוון שהוא מנוהל על ידי ה-hypervisor המארח, הוא שומר על המצב שלו במהלך הפעלות מחדש, לצורך תכונות כמו נעילת מפתחות.
‫AMD Secure Processor (שורש אמון בחומרה): זמין במכונות וירטואליות של Confidential VM עם AMD SEV-SNP. לפני שהאורח מבצע אתחול, מעבד AMD Secure מודד את מצב ההפעלה הראשוני (כולל הקושחה הווירטואלית) לתוך הרגיסטר MEASUREMENT שלו וחותם על ATTESTATION_REPORT באמצעות ה-VCEK שלו.

אתם יכולים לאמת את דוח האימות של AMD Secure Processor בפני עצמו, או לשלב אותו עם הצעת מחיר של vTPM למכונה וירטואלית מוגנת כדי לאמת את שאר שרשרת האתחול.
רישומי מדידה של Intel TDX (שורש אמון בחומרה): זמינים במכונות וירטואליות חסויות של Intel TDX. מודול Intel TDX מתעד מדידות של קושחה וירטואלית בזמן ה-build ב-Measurement of the Trust Domain ‏(MRTD), ומרחיב את המדידות של טוען האתחול, הליבה ומרחב המשתמשים ל-Run-Time Measurement Registers ‏(RTMR) בתוך מתחם האמון המבודד, בלי צורך ב-vTPM.

אתם יכולים לאמת את הציטוט של מודול Intel TDX בפני עצמו כדי לכסות את כל שרשרת האתחול. במכונות וירטואליות חסויות של Intel TDX יש vTPM של מכונה וירטואלית מוגנת, שמשמש לתכונות של TPM כמו חתימת מפתחות.

רישום מדידות

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

‫AMD SEV: רגיסטרים של הגדרות פלטפורמה (PCR). הם נמצאים בתוך ה-vTPM של המכונה הווירטואלית המוגנת.

ב-vTPM של מכונות וירטואליות מוגנות נעשה שימוש בשלושה בנקים של PCR שמאחסנים את אותן מדידות, אבל הגיבוב שלהם מתבצע באמצעות אלגוריתמים שונים: SHA-1,‏ SHA-256 ו-SHA-384.
‫AMD SEV-SNP: רישום MEASUREMENT של ההפעלה. הוא נמצא בתוך AMD Secure Processor.

ה-PCR ב-vTPM של המכונה הווירטואלית המוגנת משמשים גם לאחסון המדידות של טוען האתחול, הליבה ומרחב המשתמש.
‫Intel TDX: המדידה של מתחם האמון (MRTD) בזמן ה-build ורגיסטרים של מדידה בזמן הריצה (RTMR).

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

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

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

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

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

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

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

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

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

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

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

טכנולוגיית Confidential Computing	בקשות מיזוג לאימות	סוג יומן הביקורת	נתיב במערכת ההפעלה של האורח להפעלה מחדש של יומן האירועים
AMD SEV, ‏ AMD SEV-SNP, ‏ Intel TDX	רישומי תצורה של פלטפורמת vTPM‏ (PCR)	יומן האירועים של 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 ל-vTPM, דוח אימות ל-AMD SEV-SNP והצעת מחיר ל-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 יוצר תקציר SHA-384, על סמך מדידות ההפעלה הראשוניות שלו, שבוצעו לפני שה-UEFI של ה-Confidential VMs פועל.

התקציר הזה, נתונים אחרים של המכונה הווירטואלית ומספר חד-פעמי אופציונלי שסופק על ידי גורם מאמת, ממוקמים במבנה ATTESTATION_REPORT שנחתם על ידי Version Chip Endorsement Key‏ (VCEK) של AMD Secure Processor כדי ליצור דוח אימות.

לפרטים על המבנה של ATTESTATION_REPORT, קראו את מפרט ה-ABI של קושחת SEV Secure Nested Paging (קובץ PDF).
‫Intel TDX: מודול ה-TDX ממקם את ערכי ה-MRTD וה-RTMR, נתוני VM אחרים ו-nonce אופציונלי שסופק על ידי גורם מאמת במבנה TDREPORT_STRUCT.

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

לפרטים על המבנה של TDREPORT_STRUCT, קראו את מפרט הארכיטקטורה הבסיסית של מודול Intel Trust Domain Extensions (Intel TDX) (קובץ PDF).

המלצות

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

אישורים

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

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

‫AMD SEV: אישור מפתח אימות (AK)
‫AMD SEV-SNP: אישור Version Chip Endorsement Key ‏(VCEK)
‫Intel TDX: אישור Provisioning Certification Key ‏(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, ההוכחה היא מניפסט הפלטפורמה.

קושחה

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

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

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

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

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

ניתוח והפעלה מחדש של יומן האירועים של הגורם המאמת

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

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

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

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

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

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

בדוגמה הבאה מוצגים אירועים נבחרים מיומן אירועים של Ubuntu 24.04 vTPM, שנמדדים ב-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"

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

הערך של הרגיסטר משורשר עם תקציר SHA-256 של האירוע הבא שהוקצה ל-PCR 0, ‏EV_S_CRTM_VERSION. התוצאה המשורשרת עוברת שוב גיבוב SHA-256, ואז מאוחסנת ברגיסטר. ה-hexdigest של SHA-256 ב-PCR 0 הוא עכשיו 0c3684a7571193d76a68e489ded7bf186fc2fb1efe0c6dd9ce147960bbc57365.
אותו תהליך משמש לאירוע EV_NONHOST_INFO. ה-hexdigest של SHA-256 ב-PCR 0 הוא עכשיו 509f590b71fb22c9a6eef647e3c23611d13e599a6e15fdbb4db56ea4c2cb878d.
תהליך דומה משמש לאירוע EV_SEPARATOR, שמציין שהמדידה של תוספי המדידה ברגיסטר ספציפי הושלמה. הערך של EV_SEPARATOR הוא ערך אפס של 32 ביט (\x00*4). לכן, ה-hexdigest הסופי של SHA-256 של PCR 0 הוא a0b5ff3383a1116bd7dc6df177c0c2d433b9ee1813ea958fa5d166a202cb2a85.

קוד ה-Python הבא מדגים את התהליך הקודם על ידי יצירת סימולציה של Compute Engine PCR 0. הקוד הוא לא הפעלה מחדש של יומן אירועים, כי הוא שואב את תמציות האירועים שלו מערכים ידועים. כשיוצרים הפעלה מחדש תקינה של יומן אירועים, צריך לקרוא את התקצירים מיומן האירועים של מכונת ה-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 הוא להשתמש באיחוד שירותי אימות הזהות של עומסי העבודה, ולהתייחס לגורם המאמת כזהות מאוחדת:

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

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

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

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

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

גורמים ומודלים של אימות (attestation)

מודל Passport

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

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

שורשי אמון

AMD SEV

AMD SEV-SNP

Intel TDX

‫Root of Trust בחומרה ובתוכנה

רישום מדידות

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

דוחות של הצעות מחיר ואישורים

המלצות

אישורים

קושחה

ניתוח והפעלה מחדש של יומן האירועים של הגורם המאמת

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

הגדרת הצד המסתמך

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