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

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

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

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

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

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

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

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

check רגילה

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

אזהרה אחת (warning)

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

error קריטי

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

מצב הפעלה של SDV

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

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

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

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

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

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

אלגוריתם

האלגוריתם לחישוב הערך של מצב המכשיר הוא כדלקמן:

1. מציינים את deviceMode בתור DeviceMode::Normal.
2. מציינים את diceChainList כרשימת שרשראות DICE שרלוונטיות למכונת SDV VM.
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 (זיכרון שניתן לתכנות חד-פעמי) שנקרא VVMFactoryTrust. אם הערך הזה מוגדר, הוא מועבר לליבה כפרמטר בשם androidboot.sdv.vvmfactorytrust.

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

מצב התחלתי

כל יחידות ה-ECU הן במצב אתחול SDV במצב UNLOCKED, עם VVMFactoryTrust ריק ומאגר מהימנות של מכונה וירטואלית לרכב, מלבד 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: כותבים VVMFactoryTrust

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

1. כותבים את הגיבוב (hash) של /vvmtruststore/uds_pubs שהוצג כפלט על ידי sdv_provisioning_tool בשלב הקודם ב-VVMFactoryTrust. אופן הכתיבה הזה הוא ספציפי ל-OEM או לספק, והוא לא כלול במפרט הזה.

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

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

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

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

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

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

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

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

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

מצב התחלתי

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

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

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

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

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

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

איור 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.

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

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

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

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

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

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

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

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

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

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