‫AAOS SDV – מאובטח משלב התכנון (secure-by-design)

אנחנו ב-Google מאמינים שהמוצרים שלנו צריכים להיות מאובטחים כבר בשלב התכנון. לכן בנינו את מערכת ההפעלה Android Automotive למכוניות מוגדרות תוכנה (AAOS SDV) על בסיס פלטפורמות קיימות שאומתו בשוק, תוך שימוש בטכנולוגיות וירטואליזציה כמו Cuttlefish. בהודעות על גרסאות חדשות התמקדנו בתכונות, אבל בפוסט הזה בבלוג נסביר על כמה מהמושגים שקשורים לאבטחה.

‫Foundation: בידוד דומיין

וירטואליזציה לבידוד מקרים של אירוח משותף

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

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

אבטחה שעוברת בירושה ב-Android

‫AAOS SDV התפתח מ-Microdroid, גרסת Android מינימליסטית שעברה אופטימיזציה למכונות וירטואליות לשמירה על פרטיות (pVM). השילוב הזה מספק למהנדסי פלטפורמת Android תכונות אבטחה מוכרות שהם כבר מכירים.

טכנולוגיות לבידוד תהליכים והגדרה של 'דחייה כברירת מחדל'

ב-AAOS SDV, מוגדרת ארגז חול לכל אפליקציה לפי מודל הבידוד שמבוסס על מזהה משתמש (UID) של Android. כל שירות פועל בתהליך ייעודי עם UID ייחודי לניהול הרשאות גישה, ספריות נתונים והגבלות אחרות. אנחנו משתמשים ביכולות של Portable Operating System Interface‏ (POSIX) כדי להגביל באופן מחמיר את הפעולות, ומשלבים את זה עם Security-Enhanced Linux‏ (SELinux) כדי לאכוף גישה מסוג 'דחייה כברירת מחדל'. בגישה הזו, כל שירות מוגבל למינימום המוחלט הנדרש, כלומר חוסר בהגדרות חוסם את הגישה במקום ליצור מערכת עם הרשאות יתר. אנחנו מיישמים את אותה אסטרטגיה במערכת הרשאות הגישה שלנו, כפי שמוסבר בהמשך המאמר הזה.

Proven Vulnerability Management

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

יושרה: Secure Software Delivery

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

אימות של הכנת תוכנה להפצה

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

שנית, אנחנו משתמשים בחבילות Android Pony EXpress‏ (APEX) לשירותים. כל APEX מכיל תוכנה ואת יחסי התלות שלה, והחבילה נחשבת למחיצה עם אימות חתימה חובה. ב-AAOS SDV,‏ APEX מתייחסת לחתימת קוד כאל חוזה מתמשך שנאכף על ידי חומרה. ‫APEX מבטיח צמצום של הרצת קוד זדוני באמצעות ארבעה עקרונות מרכזיים: 

1. אחסון בלתי ניתן לשינוי

• המנגנון: ליבת Android מבצעת לולאה בקובץ apex_payload.img ישירות כהתקן אחסון גולמי באמצעות read-only loopback, ומטמיעה אותו באמצעות הדגל המחמיר MS_RDONLY.
• למה זה מאובטח יותר: אין חשיפה של נתיב כתיבה למערכת ההפעלה כי הקבצים לא נפרקים באחסון של הרכב. גם אם תוקף יקבל הרשאות root, הוא לא יוכל לשנות את קוד ה-APEX הפעיל כי שכבת מערכת הקבצים דוחה את כל פקודות הכתיבה.

2. תקינות קריפטוגרפית

• המנגנון: החתימה הקריפטוגרפית מאמתת עץ מרקל של כל תמונת מערכת הקבצים.
• למה זה יותר מאובטח: ליבת המערכת משתמשת ב-dm-verity לכל בלוק כדי לאמת את החתימה של כל בלוק נתונים בגודל 4KB תוך כדי תנועה. אם תוקף ישנה בלוק גולמי בזיכרון הפלאש, הליבה תזהה את אי ההתאמה של הגיבוב ותעצור את הביצוע באופן מיידי.

3. בידוד מחמיר

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

4. שחזור אטומי

• המנגנון: APEX משתמשת בעיצוב 'פעיל/גיבוי' כדי לאפשר החזרות כפולות למאגר. קובץ ה-APEX שמוטמע במפעל נשאר במחיצת המערכת הבלתי ניתנת לשינוי (/system), ואילו העדכונים נמצאים במחיצת הנתונים הניתנת לשינוי (/data).
• למה זה יותר מאובטח: אם עדכון נכשל או נראה זדוני, דמון apexd מסמן אותו כ'נכשל' במהלך האתחול המוקדם. המערכת מחליפה באופן מיידי את הקישורים הסמליים בחזרה למחיצת ‎ /system. השחזור האטומרי עוזר לוודא שהמערכת לא תישאר במצב פגום.

עמידות: פיתוח בטוח בזיכרון

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

‫Rust כשפה העיקרית

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

מהימנות מבוזרת: בקרה על הרשת והגישה

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

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

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

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

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

‫TLS מבוסס-DICE לאבטחת התקשורת בין מכונות וירטואליות

הצגת הזהות של המארח באופן מציאותי

כלל הזהב של DICE (Device Identifier Composition Engine): אם משתנה שורה אחת של קוד בקושחה (גם עדכון קל או ניצול לרעה זדוני), מזהה המכשיר המורכב (CDI) שנגזר משתנה לחלוטין, ונוצר מפתח כינוי שונה לגמרי.

‫DICE ו-TLS (Transport Layer Security) משולבים כדי לפתור את האתגר הבסיסי של ארכיטקטורת אפס אמון: אימות של מכונה תוך אימות של תקינות התוכנה שלה.

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

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

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

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

בקרת גישה בשכבות

ב-AAOS SDV נעשה שימוש באסטרטגיית הגנה מקיפה כדי לאפשר עדכונים דינמיים של כלי רכב בלי לפגוע במנגנוני הגישה. המודל הזה מסתמך על שתי שכבות אמון עיקריות:

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

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

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

סיכום

‫AAOS SDV מרחיב את ארכיטקטורת האבטחה של Android כדי לתת מענה לדרישות ספציפיות של כלי רכב באמצעות גישה של אבטחה משלב התכנון (secure-by-design). באמצעות מינוף של וירטואליזציה לבידוד דומיין ואכיפה של מדיניות גישה מסוג 'דחייה כברירת מחדל', הפלטפורמה יוצרת סביבה עמידה לרכבים מוגדרים בתוכנה. התקינות הקריפטוגרפית נשמרת באמצעות אימות של קוד שמופעל, בזמן אמת, על ידי חומרה.

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