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

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

מצב האתחול של SDV משמש להקצאה או לעדכון של מאגר האמון של המכונה הווירטואלית של הרכב (VVM Trust Store, שנקרא גם vvmtruststore).

התנהגות של SDV Secure Mesh

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

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

Fatal הוא כשל בסיסי, בדומה לכשל באימות החתימה של תמונת system_ext בתוכנת האתחול של Android. אם המעבר של SDV Secure Mesh מ-Normal ל-Fatal מתבצע רק בגלל עדכון OTA, העדכון נחשב לבעייתי והרשת חוזרת לגרסה המקורית Normal.

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

check רגיל

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

אזהרה אחת (warning)

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

error קריטי

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

מצב הפעלה של SDV

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

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

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

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

בשרשרת DICE, לכל אישור CDI יש ערך מצב. הערך הזה מתאר את מצב האבטחה של השכבה על סמך קלט ההגדרה שלה. כדי לבטא את עמדת האבטחה של כל התוכנות במכשיר, במפרט SDV מוגדר ערך של מצב המכשיר. הערך הזה נגזר מערך המצב של כל שלבי ה-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.

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

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

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

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

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

לכל המכונות הווירטואליות ב-ECU צריך להיות אותו מצב אתחול של SDV ואותו אמון במפעל VVM.

מצב התחלתי

כל יחידות ה-ECU הן במצב אתחול SDV במצב UNLOCKED, עם Vehicle VM Trust Store ו-VVM Factory Trust ריקים, למעט uds_certs שקיימים ב-vvmtruststore. איור 1 מציג דוגמה שבה יש שלוש מכונות וירטואליות של SDV‏ (VM-A,‏ VM-B ו-VM-C) שמפוזרות בשני יחידות ECU נפרדות (ECU-0 ו-ECU-1):

איור 1. הקצאת הרשאות במפעל, מצב התחלתי.

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

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

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

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

איור 2. הקצאת הרשאות להגדרות המקוריות, שלב 1.

שלב 2: כתיבת VVM Factory Trust

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

1. כותבים את הגיבוב של /vvmtruststore/uds_pubs שהופק על ידי sdv_provisioning_tool בשלב הקודם אל VVM Factory Trust. אופן הכתיבה הזה הוא ספציפי ליצרן הציוד המקורי או לספק, והוא לא כלול בהיקף המפרט הזה.

איור 3. הקצאת הרשאות להגדרות היצרן, שלב 2.

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

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

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

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

איור 4. הקצאת הרשאות במפעל, שלב 3.

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

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

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

מצב התחלתי

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

באיור 5 מוצגת דוגמה שבה יחידת ECU-0 לא פועלת וצריך להחליף אותה:

איור 5. החלפת חלקים, מצב התחלתי.

שלב 1: התקנת ה-ECU החדש

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

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

איור 6. החלפת חלקים, שלב 1.

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

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

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

איור 7. החלפת חלקים, שלב 2.

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

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

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

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

איור 8. החלפת חלקים, שלב 3.

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

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

איור 9. החלפת חלקים, שלב 4.

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

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

אם רשת ה-SDV Secure Mesh לא הושלמה, חוזרים אל שלב 2.

איור 10. החלפת חלקים, שלב 5.