איך Google אוכפת את תקינות האתחול במכונות ייצור

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

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

מבוא

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

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

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

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

רקע

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

פרטי הכניסה של המכונה

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

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

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

Roots of Trust בחומרה ואיטום קריפטוגרפי

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

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

איטום קריפטוגרפי הוא שירות שמציע Titan, שמשמש להגנה על סודות. יכולות האיטום של Titan דומות לאלה שמופיעות במפרט של Trusted Platform Module‏ (TPM), שפורסם על ידי Trusted Computing Group. להצפנה של Titan יש יתרון נוסף: היא מאפשרת למדוד את הקושחה ברמה נמוכה ולתת לה אישור.

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

• הצפנה של מידע אישי רגיש
• מדיניות שצריך לעמוד בה לפני שאפשר לפענח את הנתונים

פרטי כניסה מוצפנים

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

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

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

תהליך חתימת פרטי הכניסה

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

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

1. תשתית האוטומציה של המכונות של Google מתחילה עדכון תוכנה במכונה. הוא מעביר את גרסאות התוכנה הרצויות לתשתית של האישורים.
2. תשתית האישורים של Google מבקשת מפתח איטום מ-Titan, שמוגבל למדיניות כך ש-Titan משתמש בו רק אם המכונה מפעילה את התוכנה המיועדת שלה.
3. תשתית האישורים משווה את המדיניות של המפתח שהוחזר לבין הכוונה שהועברה אליה על ידי תשתית האוטומציה של המכונה. אם תשתית פרטי הכניסה קובעת שהמדיניות תואמת לכוונת המשתמש, היא מנפיקה למכונה פרטי כניסה מאומתים.
4. תשתית פרטי הכניסה מצפינה את פרטי הכניסה האלה באמצעות מפתח החתימה שמתקבל בשלב 2.
5. פרטי הכניסה המוצפנים מאוחסנים בדיסק לצורך פענוח על ידי Titan באתחולים הבאים.

תהליך האתחול המדוד

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

השכבות הן:

• מרחב משתמש: אפליקציות כמו תהליכי רקע או עומסי עבודה.
• תוכנת מערכת: היפרויזור או ליבה. הרמה הנמוכה ביותר של תוכנה שמספקת הפשטה של תכונות חומרה כמו רשת, מערכת קבצים או זיכרון וירטואלי למרחב המשתמש.
• קושחת אתחול: הקושחה שמאחלת את הליבה, כמו BIOS ותוכנת אתחול.
• Hardware root of trust: במכונות של Google, צ'יפ Titan שמבצע מדידה קריפטוגרפית של הקושחה ושירותים אחרים של מעבד ברמה נמוכה.

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

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

שחזור מפגיעויות בליבת המערכת

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

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

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

שחזור מפגיעויות בקושחה של האתחול

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

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

התאוששות מפגיעויות בקושחה של Root of Trust

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

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

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

מפתחות האימות והאיטום הם ייחודיים לכל שבב Titan. מפתחות ייחודיים מאפשרים ל-Google לבטוח רק בשבבי Titan שאמורים לפעול במרכז נתונים של Google.

הדיאגרמה הבאה מציגה את Titan עם מפתחות גרסה. קושחה בגרסה X לא יכולה לגשת למפתח בגרסה X+1, אבל היא יכולה לגשת לכל המפתחות בגרסאות ישנות יותר.

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

הבטחת האותנטיות של root of trust

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

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

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

התרשים הבא מדגים את תהליך האישור הזה.

בסביבת ייצור, מפתח Titan משתמש במפתח הייחודי למכשיר כדי לאשר כל חתימה שהוא יוצר. צ'יפים מסוג Titan משתמשים בתהליך שדומה ל-Device Identifier Composition Engine‏ (DICE). האישור כולל את פרטי הגרסה של הקושחה של Titan. האימות הזה עוזר למנוע מתוקף להתחזות לחתימה שמופקת על ידי שבב Titan, ולחזור לקושחה ישנה יותר של Titan ולהתחזות לקושחה חדשה יותר של Titan. אמצעי הבקרה האלה עוזרים ל-Google לוודא שהחתימות שהתקבלו מ-Titan נוצרו על ידי חומרה מקורית של Titan שמופעלת על ידי קושחה מקורית של Titan.

המשך פיתוח של תקינות אתחול

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

מודל האיומים של Google כולל תוקפים שעשויים להתערב פיזית באפיק בין ה-CPU לבין RoT, במטרה להשיג שלא כדין את פרטי הכניסה המפוענחים של המכונה. כדי לצמצם את הסיכון הזה, Google מפתחת גישה מבוססת-תקנים לנטרול של מכשירי ביניים פעילים, שמשלבת את ממשקי ה-API של TPM ושל DPE מ-Trusted Computing Group ואת שורש האמון המשולב של Caliptra.

המאמרים הבאים

• במאמר אימות (attestation) מרחוק של מכונות מפוצלות מוסבר איך Google עוזרת לוודא את תקינות מחסניות האתחול של מכונות מפוצלות מורכבות.
• בסקירה הכללית על תכנון האבטחה בתשתית של Google תוכלו לקרוא על האבטחה ב-Google.
• מידע נוסף על התרומה של Google לפתרונות האבטחה של Titan לתקנים בתעשייה זמין בהרצאה TPM Attested Boot in Big, Distributed Environments בערוץ YouTube של Trusted Computing Group.