אנחנו ב-Google מאמינים שהמוצרים שלנו צריכים להיות מאובטחים כבר משלב התכנון. לכן פיתחנו את מערכת ההפעלה Android Automotive לרכב מוגדר תוכנה (AAOS SDV) על בסיס פלטפורמות קיימות שהוכיחו את עצמן בשוק, תוך שימוש בטכנולוגיות וירטואליזציה כמו Cuttlefish. ההודעות על הגרסאות החדשות התמקדו בתכונות, אבל בפוסט הזה בבלוג נתאר כמה מהמושגים שקשורים לאבטחה.
בסיס: בידוד דומיינים
וירטואליזציה לבידוד של מופעים שמתארחים יחד
המגמה הנוכחית של איחוד יחידות בקרה אלקטרוניות (ECU) לשבב אחד מפחיתה את הבידוד על ידי הפעלת כמה דומיינים זה לצד זה.
למרות שמופעי SDV של AAOS מספקים מנגנוני בידוד פנימיים, בדרך כלל עדיף להריץ דומיינים לוגיים באופן עצמאי. לדוגמה, ללוח המחוונים ולמערכת המולטימדיה יש דרישות שונות. אנחנו משתמשים במכונות וירטואליות כדי להריץ כמה מכונות במקביל, וכך לוודא שהשיתוף נשאר מפורש והבידוד הוא פעולת ברירת המחדל.
אבטחה שעוברת בירושה ב-Android
AAOS SDV התפתח מ-Microdroid, גרסת Android מינימליסטית שמותאמת למכונות וירטואליות פרטיות (pVM). שושלת זו מספקת למהנדסי פלטפורמת Android אמצעי אבטחה מבוססים שהם כבר מכירים.
טכנולוגיות לבידוד תהליכים ודחייה כברירת מחדל
ב-AAOS SDV, כל אפליקציה מבודדת בארגז חול (sandbox) על סמך מזהה המשתמש (UID) ב-Android. כל שירות פועל בתהליך ייעודי עם מזהה ייחודי (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 ישירות כהתקן אחסון גולמי באמצעות לולאה חוזרת לקריאה בלבד, ומחברת אותו עם הדגל המחמיר MS_RDONLY.
- למה השיטה הזו מאובטחת יותר: השיטה הזו לא חושפת נתיב כתיבה למערכת ההפעלה כי הקבצים לא נפרקים באחסון של הרכב. גם אם תוקף מקבל הרשאות ברמת הבסיס, הוא לא יכול לשנות את קוד ה-APEX שפועל כי שכבת מערכת הקבצים דוחה את כל פקודות הכתיבה.
2. תקינות קריפטוגרפית
- המנגנון: החתימה הקריפטוגרפית מאמתת עץ מרקל של כל קובץ האימג' של מערכת הקבצים.
- למה זה מאובטח יותר: הליבה משתמשת ב-dm-verity לכל בלוק כדי לאמת את החתימה של כל בלוק נתונים בגודל 4KB תוך כדי תנועה. אם תוקף משנה בלוק גולמי בזיכרון ה-flash, הליבה מזהה את חוסר ההתאמה של הגיבוב ומפסיקה את הביצוע באופן מיידי.
3. בידוד קפדני
- המנגנון: המנגנון הזה מחיל את הכללים לטכנולוגיות לבידוד תהליכים, כמו שמתואר בקטע "טכנולוגיות לבידוד תהליכים", כדי ליצור ארגז חול (sandbox), שבו ה-APEX מותקן כמחיצה ייעודית ב-/apex.
- למה זה מאובטח יותר: כל שירות מקבל ספריית משתמשים ונתונים משלו, מה שמגביל את הגישה אלא אם השיתוף מוגדר באופן מפורש. כשיוצרים מחיצה ייעודית, מערכת Android יוצרת מרחב שמות ייעודי למקשר, וכך מבטיחה שרק ספריות שנחשפו באופן מפורש יהיו נגישות מתהליכי רקע של המערכת ללא הרשאות, וכך מצמצמת את שטח המתקפה.
4. שחזור אטומי
- המנגנון: APEX משתמש בעיצוב "פעיל/גיבוי" כדי לאפשר חזרה למצב קודם עם מאגר נתונים זמני כפול. קובץ ה-APEX שנצרב במפעל נשאר במחיצת המערכת /system שלא ניתנת לשינוי, והעדכונים נמצאים במחיצת הנתונים /data שניתנת לשינוי.
- למה זה מאובטח יותר: אם עדכון נכשל או נראה זדוני, ה-daemon של apexd מסמן אותו כ"נכשל" במהלך האתחול המוקדם. המערכת מחליפה באופן מיידי את הקישורים הסמליים בחזרה למחיצה /system. השחזור האטומי הזה עוזר לוודא שהמערכת לא תישאר במצב פגום.
עמידות: פיתוח עם ניהול זיכרון בטוח
טעינה מאומתת מגינה על המערכת מפני שינויים חיצוניים, אבל החוסן של הפלטפורמה תלוי גם באופן שבו הקוד הבסיסי בנוי. ברכיבים חדשים שפותחו ל-AAOS SDV, נתנו עדיפות לבטיחות הזיכרון.
Rust כשפה הראשית
AAOS SDV מיועד למערכות קטנות עם דרישות זמינות מהירות. זה מונע פיתוח על סטאק Android המלא, ולכן הגבלנו את ההיקף שלנו למסגרת המקורית. כדי ליצור את התשתית הנדרשת למערכת מבוזרת, פיתחנו כמה רכיבים בנוסף לתשתית הקיימת, ואימצנו את 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 נעשה שימוש באסטרטגיית הגנה לעומק כדי לאפשר עדכונים דינמיים של הרכב בלי לפגוע במנגנוני הגישה. המודל הזה מסתמך על שתי שכבות אמון עיקריות:
- הרשאות ברמת השירות: מגדירות את המשאבים הספציפיים ששירות במכונה וירטואלית מסוימת יכול לגשת אליהם או לחשוף אותם ברשת ה-mesh.
- הרשאות ברמת המכונה הווירטואלית: הגדרת גבולות התקשורת בין מכונות וירטואליות לכל השירותים שמתארחים במכונה וירטואלית ספציפית.
המודל הזה מאפשר ליצרני ציוד מקורי (OEM) לאזן בין אבטחה לבין אפשרות לקבל עדכונים. בשירותים שלא רגישים מבחינת אבטחה, מדיניות מתירנית ברמת המכונה הווירטואלית מאפשרת התקנה באמצעות עדכוני APEX קלים, במקום פריסה מחדש של המכונה הווירטואלית.
לעומת זאת, הרשאות לאותות שרגישים מבחינת אבטחה חייבות להיות מקודדות באופן קשיח בכל מכונה וירטואלית. החיסרון הוא שאם מוסיפים שירות רגיש מבחינת אבטחה למכונה וירטואלית חדשה, צריך לעדכן את ההרשאות ברמת המכונה הווירטואלית בכל המערכת. לכן צריך לעדכן את כל המכונות הווירטואליות ברשת.
סיכום
AAOS SDV מרחיב את ארכיטקטורת האבטחה של Android כדי לתת מענה לדרישות ספציפיות של כלי רכב, באמצעות גישה של אבטחה משלב התכנון (secure-by-design). הפלטפורמה משתמשת בווירטואליזציה לבידוד דומיינים ואוכפת מדיניות גישה של "דחייה כברירת מחדל", וכך יוצרת סביבה עמידה לרכבים מוגדרי תוכנה. התקינות הקריפטוגרפית נשמרת באמצעות אימות בזמן אמת של הקוד שמופעל, שנאכף על ידי החומרה.
הפלטפורמה משלבת מחזורי חיים של אבטחה רציפה, החל מניהול נקודות חולשה יזום ועד לאימות זהות שמבוסס על חומרה באמצעות DICE. ההגנות האלה, שמורכבות מכמה שכבות, מאפשרות ליצרני הציוד המקורי (OEM) לאזן בין האפשרות לעדכן תכונות מתקדמות לבין האבטחה החזקה שנדרשת בסביבות הרכב המודרניות. מפרטים טכניים ופרטי הטמעה זמינים בדף הסקירה הכללית של AAOS SDV.
-
חדשות על המוצרהיום, קטגוריית המשחקים ל-Android Auto ולמכוניות עם Android Automotive OS ושירותי Google מובנים עוברת באופן רשמי מגרסת בטא לזמינות לכלל המשתמשים (GA).
Jan Kleinert • משך הקריאה: 3 דקות -
חדשות על המוצריותר מחצי מהמשחקים לנייד בעולם מבוססים על Unity, ולכן הרושם הראשוני חשוב. למפתחי משחקים, חוויית הצטרפות חלקה ואמינה לשחקנים היא חיונית כדי להגביר את שימור המשתמשים ביום הראשון ואת המעורבות לטווח הארוך.
Michelle Martin • משך הקריאה: דקה אחת -
חדשות על המוצרמחוויות סוחפות בבית ועד לחוויות שניתן לראות במבט חטוף תוך כדי תנועה, פיתוח ב-Android XR מאפשר לכם להגיע למשתמשים בכל רגע, בכל מגוון האפליקציות המרחביות. במפגש של מפתחי Android, ציינו אבן דרך מרגשת עם ההשקה של XREAL AURA.
Amy Zeppenfeld, Vinny DaSilva • משך הקריאה: 3 דקות
רוצים לקבל טיפים עדכניים לפיתוח Android ישירות לאימייל כל שבוע?
