בידוד של מערכת הרכב

כדי להבטיח את תקינות המערכת ברכב, מערכת Android Automotive מגינה על הנתונים הנכנסים ברמות הבאות:

רכיבי מערכת EVS

איור 1. ארכיטקטורת שירותי המערכת

  • אפליקציות המערכת מוודאת שלאפליקציה יש הרשאה לתקשר עם רכיבי המשנה של הרכב.
  • ממשקי API מוגדרים היטב. ממשקי API כלליים לא מקבלים blobs שרירותיים של נתונים (ממשקי API חייבים להיות מוגדרים היטב).
  • שירותי רכב עדכונים מותרים רק דרך OTA (או USB), עם הצפנה מלאה של הדיסק ואתחול מאומת. לא ניתן להעביר אותן להתקנה ידנית.
  • Vehicle HAL מוודא שהודעות ספציפיות מותרות.

אפליקציות וממשקי API

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

הודעות Vehicle HAL מסוננות בשתי רמות:

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

שכבת הפשטת חומרה לרכב

Vehicle HAL היא שכבה נמוכה יותר שמקיימת אינטראקציה עם הרכב, ומנהלת תקשורת עם רשתות ברכב וחומרה אחרת ברכב באמצעות קריאות ל-ioctl (בקרת קלט/פלט של מנהל התקן).

HAL הרכב הוא הרכיב היחיד ב-Android Automotive שמחובר למערכת ה-IVI, בין שבאמצעות חיבור ישיר של מעבד אפליקציות/מיקרו-בקר ובין שבאמצעות שער דרך VMCU. הגישה ל-HAL של הרכב צריכה להיות מוגבלת לאפליקציות מערכת באמצעות כללי SELinux והרשאות מתאימות בממשקי הליבה.

מדיניות SELinux

Android Automotive מרחיב את SELinux כדי לסנן את הגישה של הנהג, כולל קריאות ל-open, ‏ close, ‏ read,‏ write ו-ioctl. שימוש בסינון ioctl (יחד עם פונקציונליות אחרת של SELinux) מגביל את סוג הודעות ה-CAN שמותר ל-HAL של הרכב לקבל, וכך מקטין באופן משמעותי את שטח ההתקפה. למידע נוסף על SELinux, ראו Security-Enhanced Linux ב-Android.

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

<permission-group
 android:name=”android.support.car.permission.CAR_MONITORING />

<permission
 android:name=”android.support.car.permission.CAR_MILEAGE”
 android:protectionLevel=”signature|privileged” />
<permission
 android:name=”android.support.car.permission.CAR_SPEED”
 android:permissionGroup=”android.permission-group.LOCATION”
 android:protectionLevel=”dangerous” />
<permission
 android:name=”android.support.car.permission.CAR_VENDOR_EXTENSION”
 android:permissionGroup=”android.support.car.permission.CAR_INFORMATION”
 android:protectionLevel=”signature|privileged” />

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

חסימת אפליקציות ופעילויות

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

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