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

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

יסודות: בידוד דומיינים

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

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

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

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

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

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

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

ניהול מוכח של נקודות חולשה

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

תקינות: הכנת תוכנה מאובטחת להפצה

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

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

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

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

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

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

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

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

3. בידוד קפדני

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

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

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

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

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

‫Rust כשפה הראשית

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

אמון מבוזר: בקרת גישה ורשת

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

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

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

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

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

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

התאמת הזהות של המארח למציאות

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

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

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

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

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

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

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

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

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

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

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

סיכום

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

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