סטטוס וניהול תצורה של רשת

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

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

התנהגות מאובטחת של רשת Mesh ב-SDV

רשת Service Discovery יכולה להיות באחד מהמצבים הבאים, בהתאם לערכי האתחול שהיא מקבלת: Normal, ‏ Warning או Fatal.

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

שגיאה מסוג Fatal היא כשל בסיסי, בדומה לכשל באימות החתימה של תמונת system_ext בתוכנת האתחול של Android. אם ה-SDV Mesh עבר מ'רגיל' ל'קריטי' רק בגלל עדכון OTA (Over The Air), העדכון הזה ייחשב כעדכון בעייתי ותחזרו לגרסה המקורית 'רגילה'.

בקטעים הבאים מוסבר על המצבים האלה בפירוט.

check רגיל

• הפעלת המערכת היא SECURE מנקודת המבט של Service Discovery.
• התכונה 'גילוי שירותים' מתחברת רק לעמיתים שלדעתה הפעילו את המחשב בצורה מאובטחת, ולכן היא מאמינה שהרשת המאובטחת של SDV שהיא חלק ממנה מאובטחת.

אזהרה אחת (warning)

• יכול להיות שהפריצה למערכת הצליחה כי חלק מהאימותים מושבתים.
• התכונה Service Discovery מתחברת רק לעמיתים שגם להם יש אותן בדיקות השבתה. לכן היא חלק מרשת SDV מאובטחת עם אותן תכונות אבטחה כמו שלה.
• יכול להיות שהפעלה של מחשב עמית הושלמה בהצלחה או שלא הושלמה בהצלחה – אי אפשר לאמת את זה בגלל כשלים מקומיים או השבתות.
• מחוץ לסביבת פיתוח או למצב פיתוח, יש לכך את ההשלכות הבאות:
  • נתוני המשתמשים לא צריכים להיות זמינים. כלומר, היא לא יכולה להיות מועברת או מושפעת מהתקשורת דרך SDV Secure.
  • רק שירותים שנדרשים לתהליכי הקצאת הרשאות צריכים להיות זמינים כשהרשת נמצאת במצב הזה.

error קריטי

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

מצב הפעלה של SDV

למצב האתחול של SDV יש שני ערכים אפשריים: UNLOCKED ו-LOCKED. בנוגע להקמת רשת Service Discovery, במצב LOCKED שגיאות אימות הן קריטיות, ואילו במצב UNLOCKED הן לא.

חשוב לשים לב שמצב ההפעלה של SDV שונה ממצב המכשיר של Android (שנקרא גם מצב AVB). מצב ההפעלה של SDV קובע את ההתנהגות של SDV Secure Mesh ואם שגיאות בחיבור לרשת הן קריטיות. מצב AVB קובע אם אימותים שמבוצעים על ידי תוכנת האתחול של Android הם קריטיים.

התאמה בין מצב SDV מקומי לבין מצב AVB

בטבלה הבאה אפשר לראות איך מצב AVB ומצב האתחול SDV משפיעים על ההתנהגות של SDV Secure Mesh. הצבעים מוגדרים בקטע שילוב ספציפי ל-Android במסמכי ה-AVB.

הערך של מצב המכשיר

בשרשרת DICE, לכל אישור CDI יש ערך מצב. הוא משמש לתיאור מצב האבטחה של השכבה הזו על סמך קלט ההגדרה שלה. כדי לבטא את עמדת האבטחה של כל התוכנות במכשיר, מוגדר ערך מצב המכשיר, שנגזר מערך המצב של כל שלבי ה-CDI בשרשראות ה-DICE שרלוונטיות למכונת SDV וירטואלית נתונה (כלומר, ‫Android HLOS ו-Secure World) ומוגדר כך:

enum DeviceMode {
  NotConfigured = 0,
  Recovery = 1,
  Debug = 2,
  Normal = 3,
}

אלגוריתם

1. אני רוצה ש-deviceMode יהיה DeviceMode::Normal
2. ‫diceChainList היא רשימת שרשראות ה-DICE שרלוונטיות למכונת VM של SDV
3. לכל diceChain ב-diceChainList:
   1. ‫cdiList היא רשימת אישורי ה-CDI ב-diceChain:
   2. לכל cdiCert ב-cdiList:
      1. ‫cdiDeviceMode הוא DeviceMode שמתאים ל-cdiCert.mode.
      2. מגדירים את deviceMode להיות min(deviceMode, cdiDeviceMode).
4. החזרה deviceMode.

השוואה בין ערכים של מצב מכשיר מרוחק

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

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

תהליך הקצאת הרשאות במפעל

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

התהליך הזה תלוי בערך של 32 בייט שמאוחסן בזיכרון OTP (זיכרון שניתן לתכנות חד-פעמי) שנקרא VVMFactoryTrust. אם הערך הזה מוגדר, הוא מועבר לליבה כפרמטר בשם androidboot.sdv.vvmfactorytrust.

לכל המכונות הווירטואליות ב-ECU צריכים להיות אותם מצב אתחול של SDV ו-VVMFactoryTrust.

מצב התחלתי

כל יחידות ה-ECU נעולות בהתחלה במצב אתחול SDV, עם VVMFactoryTrust ו-VVMTrustStore ריקים, מלבד uds_certs שאולי קיימים ב-VVMTrustStore.

איור 1 מציג דוגמה שבה יש שלוש מכונות וירטואליות של SDV‏ (VM-A, ‏ VM-B ו-VM-C) שמפוזרות בשני יחידות ECU נפרדות (ECU-0 ו-ECU-1).

שלב 1: מריצים את הכלי sdv_provisioning_tool

מפעילים את כל המכונות הווירטואליות מכל יחידות ה-ECU.

בכל מכונה וירטואלית:

• הפעלה של sdv_provisioning_tool

  • הכלי מתקשר עם סוכן גילוי השירות המקומי וממתין לאות ממנו שהרשת המאובטחת של SDV הושלמה, ושהסוכן כתב את רשימת המפתחות הציבוריים של UDS אל /vvmtruststore/uds_pubs.
  • במקרה כזה, הכלי מקבל את הגיבוב של /vvmtruststore/uds_pubs שזה עתה נכתב ומציג אותו.

שלב 2: כותבים VVMFactoryTrust

במכונה וירטואלית אחת של כל ECU:

• כותבים את הגיבוב של /vvmtruststore/uds_pubs שהופק על ידי sdv_provisioning_tool בשלב הקודם אל VVMFactoryTrust. אופן הכתיבה תלוי ב-OEM או בספק, ולכן הוא לא נכלל בהגדרות האלה.

שלב 3: הפעלה מחדש במצב אתחול SDV נעול

מפעילים מחדש את כל המכונות הווירטואליות בכל יחידות ה-ECU במצב SDV Boot Mode Locked (מצב אתחול SDV נעול).

הסוכן Service Discovery נותן אמון במכונות וירטואליות ב-ECU עם המפתחות הציבוריים של UDS שמפורטים ב-uds_pubs, כי הגיבוב של הקובץ הזה תואם ל-VVMFactoryTrust.

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

תהליך החלפת חלקים

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

התהליך הזה תלוי באישור UDS שהונפק ישירות על ידי רשות הבסיס שצוינה ב-vvmconfig או בעקיפין, דרך שרשרת של רשויות ביניים.

מצב התחלתי

כל המכונות הווירטואליות כבר הוקצו כברירת מחדל ופועלות במצב אתחול SDV נעול.

באיור 5 מוצגת דוגמה שבה יחידת הבקרה האלקטרונית ECU-0 לא תקינה ולכן צריך
להחליף אותה.

שלב 1: התקנת יחידת הבקרה האלקטרונית (ECU) החדשה

מתקינים את ה-ECU החדש, שיהיה במצב ריק ולא מוקצה.

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

שלב 2: הפעלה מחדש במצב אתחול SDV לא נעול

אתחול מחדש של כל מכונות ה-VM של כל יחידות ה-ECU במצב אתחול SDV לא נעול.

באיור 7, מכונות ה-VM‏ VM-B ו-VM-C מצטרפות לרשת המאובטחת SDV Secure Mesh, שהיא עכשיו מלאה.

שלב 3: מריצים את הכלי sdv_provisioning_tool

בכל מכונה וירטואלית, מריצים את sdv_provisioning_tool.

הכלי מתקשר עם סוכן גילוי השירות המקומי וממתין לאות ממנו שהרשת המאובטחת של SDV הושלמה, ושהסוכן כתב את רשימת המפתחות הציבוריים של UDS אל /vvmtruststore/uds_pubs.

במקרה כזה, הכלי מקבל את הגיבוב של /vvmtruststore/uds_pubs שזה עתה נכתב ומציג אותו, אבל הגיבוב הזה לא נמצא בשימוש בתהליך הזה.

שלב 4: התקנת אישורי UDS

• תמצית /vvmtruststore/uds_pubs ממכונה וירטואלית שרירותית של SDV. לא משנה באיזו מהן תבחרו, כי היא תהיה זהה לכל המכונות הווירטואליות באותו SDV Secure Mesh.
• שליפה של אישורי הקצאת הרשאות לכל המפתחות הציבוריים של UDS שמופיעים ב-/vvmtruststore/uds_pubs.
  • בדרך כלל, המשמעות היא שליחת הנתונים לשרת מרוחק שבו האישורים כבר מאוחסנים, או שהשרת ייצור אותם על ידי בדיקת המפתחות הציבוריים שהתקבלו מול מסד נתונים של מפתחות ציבוריים ידועים של UDS. מסד הנתונים הזה היה אמור להיבנות ממפתחות ציבוריים של UDS שחולצו במהלך ייצור ה-ECU.
• כותבים את /vvmtruststore/uds_certs של כל מכונת SDV וירטואלית.

שלב 5: הפעלה מחדש במצב הפעלה של SDV נעול

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

אם מסיבה כלשהי רשת ה-SDV המאובטחת לא הושלמה, צריך לחזור אל שלב 2.