מדריך יצרן לאבטחת אנדרואיד לטווח ארוך

מדריך זה מתאר את השיטות המומלצות המומלצות של Google להחלת תיקוני אבטחה המוערכים על ידי חבילת בדיקת התאימות של Android (CTS). זה מיועד ליצרנים של ציוד OEM תואם אנדרואיד (יצרנים) שייתמכו יותר משלוש שנים כמו רכבים, טלוויזיות, ממירים ומכשירי חשמל ביתיים. מדריך זה אינו מיועד למשתמשי קצה (לדוגמה, בעלי רכב).

תודות והסתייגות

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

מָשׁוֹב

מדריך זה לא נועד להיות מקיף; מתוכננים תיקונים נוספים. שלח משוב אל [e-mail].

מילון מונחים

טווח	הַגדָרָה
ACC	התחייבות לתאימות אנדרואיד. ידוע בעבר כ-Android Anti-Fragmentation Agreement (AFA).
AOSP	פרויקט קוד פתוח של אנדרואיד
ASB	עלון אבטחה של אנדרואיד
BSP	חבילת תמיכה בלוח
CDD	מסמך הגדרת תאימות
CTS	חבילת בדיקת תאימות
FOTA	קושחה דרך האוויר
ג'י.פי. אס	מערכת מיקום גלובלית
MISRA	איגוד אמינות התוכנה של תעשיית הרכב
לא	המכון הלאומי לתקנים וטכנולוגיה
OBD	אבחון מובנה ( OBD-II הוא שיפור לעומת OBD-I הן ביכולת והן בסטנדרטיזציה )
OEM	יצרן ציוד מקורי
מערכת הפעלה	מערכת הפעלה
SEI	המכון להנדסת תוכנה
SoC	מערכת על שבב
לְהַספִּיג	תחילת הייצור
SPL	רמת תיקון אבטחה
TPMS	מערכת בקרת לחץ אויר בצמיגים

לגבי מערכת ההפעלה אנדרואיד

אנדרואיד היא ערימת תוכנה מלאה מבוססת לינוקס בקוד פתוח, המיועדת למגוון מכשירים וגורמי צורה. מאז השחרור הראשון שלה ב-2008, אנדרואיד הפכה למערכת ההפעלה הפופולרית ביותר (OS), המניעה יותר מ-1.4 מיליארד מכשירים ברחבי העולם (2016). כ-67% מהמכשירים האלה משתמשים ב-Android 5.0 (Lollipop) או חדש יותר נכון למרץ 2017 (נתונים עדכניים יותר זמינים ב- Android Dashboard ). בעוד שהרוב המכריע של המכשירים הם טלפונים ניידים וטאבלטים, אנדרואיד צומחת בשעונים חכמים, טלוויזיות ומכשירי מידע בידור לרכב (IVI).

מספר אפליקציות האנדרואיד הזמינות בחנות Google Play הגיע ל -2.2+ מיליון (2016). פיתוח אפליקציית אנדרואיד מגובה על ידי תוכנית התאימות ל-Android, המגדירה מערכת של דרישות באמצעות מסמך הגדרת תאימות (CDD) ומספקת כלי בדיקה באמצעות חבילת בדיקת התאימות (CTS) . תוכניות התאימות לאנדרואיד מבטיחות שכל אפליקציית אנדרואיד יכולה לפעול בכל מכשיר תואם אנדרואיד התומך בתכונות הנדרשות לאפליקציה.

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

• אבטח מכשיר אנדרואיד
• עדכוני אבטחה ומשאבים
• חבילת בדיקת תאימות
• שמות קוד, תגים ומספרי Build

על כלי רכב מחוברים (מוצרים קנוניים עם חיים ארוכים)

כלי רכב החלו להיות מחוברים עם הצגת רדיו AM בשנות ה-20. משם, מספר החיבורים הפיזיים והאלחוטיים החיצוניים החל לגדול כאשר הרגולטורים ויצרני הרכב פנו לאלקטרוניקה כדי להקל על האבחון והשירות (לדוגמה, יציאת OBD-II), לשפר את הבטיחות (לדוגמה, TPMS) ולעמוד ביעדי חיסכון בדלק. . גל הקישוריות הבא הציג תכונות נוחות לנהג כגון כניסה מרחוק ללא מפתח, מערכות טלמטיקה ותכונות מידע מתקדמות כגון Bluetooth, Wi-Fi והקרנת סמארטפון. כיום, חיישנים משולבים וקישוריות (לדוגמה, GPS) תומכים במערכות בטיחות ובמערכות נהיגה חצי אוטונומיות.

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

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

להבטיח אבטחה לטווח ארוך

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

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

דוגמה לעדכוני מערכת הפעלה ותיקוני אבטחה (IVI פועל עם אנדרואיד):

איור 1. דגימת מערכת הפעלה עיקרית ועדכוני אבטחה במהלך חיי הרכב.

#	שלב	פעילויות
①	סניף פיתוח	היצרן בוחר בגרסה של אנדרואיד (אנדרואיד X). בדוגמה זו, "אנדרואיד X" הופך לבסיס של מה שיישלח ברכב שנתיים לפני התחלת הייצור הראשונית (SOP).
②	השקה ראשונית	כמה חודשים לפני ש-Android X הופכת לגרסת מערכת ההפעלה הראשונה שנשלחה במוצר, עדכוני אבטחה נלקחים מ-Android Security Bulletins (ASBs) וממקורות אחרים שעלולים להיחשב יקרים על ידי היצרן. y2 = עלון האבטחה השני עבור גרסה X של אנדרואיד, שהוחל (מועבר לאחור) על ידי היצרן על אנדרואיד X. עדכון זה נשלח במוצר ושעון הייצור מתחיל לתקתק בשנת אפס עם Android X.y2. בדוגמה זו, היצרן קיבל את ההחלטה שלא לשלוח את המהדורה השנתית העדכנית יותר של Android X+1. הסיבות למשלוח של המהדורה האחרונה כוללות הוספת תכונות חדשות, טיפול בפרצות אבטחה חדשות ו/או משלוח שירותי גוגל או צד שלישי הדורשים את גרסת האנדרואיד החדשה יותר. הסיבות נגד משלוח עם המהדורה העדכנית ביותר הן חוסר הזמן הגלום בתהליך הפיתוח וההשקה של הרכב הנדרש לשילוב, בדיקה ואימות של השינויים, כולל עמידה בכל דרישות הרגולציה וההסמכה.
③	עדכון מערכת הפעלה מלא	לאחר SOP, היצרן משחרר את עדכון מערכת ההפעלה Android X+2, שהוא שתי מהדורות אנדרואיד לאחר הגרסה ששימשה למוצר הראשוני (Android X0). עדכוני אבטחה ASB זמינים עבור רמת ה-API (נכון לתאריך המשלוח), כך שהעדכון יוצא כ-X+2.y0 כ-1.25 שנים לאחר SOP. עדכון מערכת הפעלה זה עשוי להיות תואם למוצרים בשטח או לא. אם כן, ניתן ליצור תוכנית לעדכון כלי רכב פרוסים. אלא אם כן קיימים הסכמים עסקיים אחרים, ההחלטה לבצע עדכון מלא של מערכת ההפעלה נתונה לחלוטין לשיקול דעתו של היצרן.
④	עדכון אבטחה	שנתיים לתוך אורך חיי הייצור של הרכב, היצרן מתקן את מערכת ההפעלה Android X+2. החלטה זו מבוססת על הערכת הסיכונים של היצרן. היצרן בוחר בעדכון האבטחה השלישי של ASB לגרסה X+2 כבסיס לעדכון. מוצרים שמקבלים את עדכון האבטחה נמצאים כעת ברמת (X+2.y3) OS + Android Security Patch. בעוד שיצרנים יכולים לבחור תיקוני אבטחה בודדים מכל ASB בודד, עליהם לתקן את כל הבעיות הנדרשות בעלון כדי להשתמש ברמת תיקון האבטחה של Android (SPL) המשויכת לעלון (לדוגמה, 2017-02-05). באחריות היצרן לבצע את היציאה האחורית ושחרור האבטחה עבור המוצר הנתמך.
⑤	עדכון מערכת הפעלה מלא	חזרה על שלב 3 (עדכון מערכת ההפעלה המלא), עדכון מערכת ההפעלה המלא השני מביא את המוצר ל-Android X+4, שלוש שנים לתוך אורך חיי הייצור של הרכב. היצרן מאזן כעת את דרישות החומרה החדשות יותר של גרסת אנדרואיד עדכנית מול החומרה במוצר והמשתמש נהנה ממערכת הפעלה אנדרואיד מעודכנת. היצרן משחרר עדכון ללא עדכוני אבטחה, כך שהמוצר נמצא כעת ב-(X+4.y0) OS + Android Security Patch Level. בדוגמה זו, עקב מגבלות חומרה, X+4 היא הגרסה העיקרית האחרונה של אנדרואיד שתסופק עבור מוצר זה, אם כי 6+ שנות חיים צפויות לרכב עדיין דורשות תמיכה באבטחה.
⑥	עדכון אבטחה	חזרה על שלב 4 (עדכון אבטחה). על היצרן מוטלת המשימה לקחת עדכוני אבטחה ASB מגרסה מאוחרת בהרבה של אנדרואיד (X+6) ולהעביר חלק מהעדכונים האלה או את כולם בחזרה לאנדרואיד X+4. באחריות היצרן למזג, לשלב ולבצע את העדכונים (או להתקשר עם צד שלישי). כמו כן, היצרן צריך להיות מודע לכך שבעיות אבטחה בגרסאות של אנדרואיד שאינן נתמכות עוד אינן מכוסות ב-ASB.
⑦	עדכון אבטחה	שמונה שנים לתוך מחזור חיי הייצור של הרכב, ארבע מהדורות אנדרואיד מאז עדכון מערכת ההפעלה האחרון בשלב 5 (עדכון מערכת הפעלה מלא), ועשר שנים מאז שצוין אנדרואיד X, הנטל של אצור והעברת תיקוני אבטחה לאחור מוטל כולו על היצרן עבור גרסאות אלה ישנות יותר משלוש שנים מההוצאה הציבורית ברמת ה-API.

שיטות עבודה מומלצות לאבטחה

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

הנחיות אבטחה

שיטות אבטחה מומלצות כוללות:

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

הנחיות לפיתוח תוכנה

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

• בצע מודל איומים כדי לדרג ולזהות נכסים, איומים והפחתות פוטנציאליות.
• בצע סקירת ארכיטקטורה/עיצוב כדי להבטיח עיצוב מאובטח ובריא.
• בצע ביקורות קוד קבועות כדי לזהות אנטי-דפוסים ובאגים בהקדם האפשרי.
• תכנן, הטמע והפעל בדיקות יחידות כיסוי בעלות קוד גבוה, כולל:
  • בדיקה פונקציונלית (כולל מקרי בדיקה שליליים)
  • בדיקות רגרסיה רגילות (כדי להבטיח שבאגים מתוקנים לא יופיעו מחדש)
  • בדיקות Fuzz (כחלק מחבילת הבדיקות של היחידה)
• השתמש בכלי ניתוח קוד מקור סטטי (סריקה-בנייה, מוך וכו') כדי לזהות בעיות אפשריות.
• השתמש בכלי ניתוח קוד מקור דינמיים, כגון AddressSanitizer, UndefinedBehaviorSanitizer ו- FORTIFY_SOURCE (עבור רכיבים מקוריים) כדי לזהות ולצמצם בעיות פוטנציאליות במהלך פיתוח המערכת.
• יש אסטרטגיית ניהול עבור קוד מקור תוכנה ותצורת גרסה/גרסה.
• יש לך אסטרטגיית ניהול תיקונים ליצירה ופריסה של תיקוני תוכנה.

מדיניות אחורי אבטחה

Google מספקת כיום תמיכה אקטיבית ליציאות אחוריות של אבטחה של פרצות אבטחה שהתגלו ודווחו במשך שלוש (3) שנים מהפרסום הציבורי ברמת ה-API . תמיכה פעילה מורכבת מהאפשרויות הבאות:

1. לקבל ולחקור דוחות פגיעות.
2. צור, בדוק ושחרר עדכוני אבטחה.
3. ספק מהדורות חוזרות של עדכוני אבטחה ופרטי עלון אבטחה.
4. בצע הערכת חומרה בהתאם להנחיות שנקבעו.

לאחר שלוש שנים מתאריך הפרסום הציבורי ברמת ה-API, Google ממליצה על ההנחיות הבאות:

• השתמש בגורם צד שלישי (כגון ספק SoC או ספק ליבה) לתמיכה ב-backport עבור עדכוני אבטחה של מערכת ההפעלה שישנים יותר משלוש שנים משחרור API.
• השתמש בצד שלישי כדי לבצע ביקורות קוד באמצעות ה-ASBs שסופקו לציבור. בעוד ASBs מזהים פגיעויות עבור הגרסה הנתמכת כעת, יצרן עשוי להשתמש במידע שסופק כדי להשוות את העדכונים החדשים שפורסמו מול גרסאות קודמות. ניתן להשתמש בנתונים אלה כדי לבצע ניתוח השפעה ופוטנציאל ליצור תיקונים דומים עבור גרסאות מערכת ההפעלה בנות יותר משלוש שנים משחרור ה-API.
• כאשר מתאים, העלה עדכוני אבטחה לפרויקט הקוד הפתוח של Android (AOSP).
• היצרן חייב לתאם את הטיפול בעדכוני אבטחה עבור קוד ספציפי לספק (לדוגמה, קוד קנייני למכשיר).
• היצרן צריך להצטרף לקבוצת ההתראות של NDA Android Security Bulletin Partner Preview (מחייב חתימה על הסכמים משפטיים כגון NDA למפתחים). עלונים צריכים לכלול:
  • הכרזות
  • סיכום של בעיות לפי רמת תיקון, כולל CVE וחומרת
  • פרטי פגיעות במידת הצורך

הפניות נוספות

להנחיות לגבי שיטות קידוד מאובטח ופיתוח תוכנה, עיין בסעיפים הבאים:

• איגוד אמינות התוכנה של תעשיית הרכב (MISRA) .
• כלים ושיטות של המכון להנדסת תוכנה (SEI) .
• המכון הלאומי לתקנים וטכנולוגיה (NIST).

שיטות מוצר מומלצות

Google מעודדת את השימוש בשיטות המומלצות הבאות.

הנחיות השקה כלליות

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

ההנחיות המומלצות כוללות:

• עקב זמני אספקת פיתוח ארוכים הטמונים בתהליך פיתוח הרכב, ייתכן שהיצרנים יצטרכו להשיק עם מערכת הפעלה n-2 ומעלה.
• שמור על התאמה לתאימות אנדרואיד עבור כל גרסת מערכת ההפעלה אנדרואיד שפורסמה עם מסע פרסום אויר (OTA).
• הטמעת מוצר Android Firmware-over-the-air (FOTA) המסוגלת לעדכונים מהירים וידידותיים ללקוח. FOTA צריך להיעשות באמצעות שיטות אבטחה מומלצות כגון חתימת קוד וחיבור TLS בין המוצר ל-IT Backoffice.
• שלח פרצות אבטחה מזוהות עצמאית של Android לצוות אבטחת Android.

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

הנחיות למחזור מוצר

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

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

מסמך הגדרת תאימות (CDD)

מסמך הגדרת התאימות (CDD) מתאר דרישות למכשיר להיחשב תואם אנדרואיד. ה-CDD הוא ציבורי וזמין לכולם; אתה יכול להוריד גרסאות CDD מאנדרואיד 1.6 לגרסה העדכנית ביותר מ source.android.com .

עמידה בדרישות אלה עבור מוצר כרוכה בשלבים הבסיסיים הבאים:

1. השותף חותם על התחייבות התאימות לאנדרואיד (ACC) עם Google. לאחר מכן יוקצה יועץ פתרון טכני (TSC) כמדריך.
2. שותף משלים את סקירת ה-CDD עבור גרסת מערכת ההפעלה Android של המוצר.
3. Partner מפעיל ומגיש את תוצאות ה-CTS (המתוארות להלן) עד שהתוצאות יהיו מקובלות עבור תאימות אנדרואיד.

חבילת בדיקת תאימות (CTS)

כלי הבדיקה של Compatibility Test Suite (CTS) מוודא שהטמעת מוצר תואמת ל-Android ושתיקוני האבטחה האחרונים כלולים. CTS הוא ציבורי, קוד פתוח וזמין לכולם; אתה יכול להוריד גרסאות CTS מאנדרואיד 1.6 לגרסה העדכנית ביותר מ source.android.com .

כל מבנה של תוכנת אנדרואיד ששוחרר לציבור (תמונות מהתקנה מפעל ועדכון שטח) חייב להוכיח תאימות אנדרואיד באמצעות תוצאות CTS. לדוגמה, אם המכשיר מריץ אנדרואיד 7.1, יש להתייחס לגרסה המתאימה ביותר של CDD 7.1 ו-CTS 7.1 כאשר נוצרת ונבדקת תמונת בנייה עם כוונת שחרור. מומלץ מאוד ליצרנים להשתמש ב-CTS מוקדם ובתדירות גבוהה כדי לזהות ולתקן בעיות.

הערה: ייתכן ששותפים שחותמים על הסכמים אחרים, כגון שירותי Google Mobile (GMS) , יצטרכו לעמוד בדרישות אחרות.

זרימת עבודה של CTS

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

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

תעבור את ה-CTS

עבור מוצר תואם אנדרואיד, Google מבטיחה שתוצאות הבדיקה של המכשיר ו-CTS Verifier מדווחות קבילות. עקרונית, כל המבחנים חייבים לעבור. עם זאת, בדיקה שנכשלת מסיבות שאינן עומדות בדרישות התאימות של אנדרואיד כפופה לבדיקה של Google. במהלך תהליך זה:

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

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

ה-CTS נשאר פתוח לביקורות על תיקוני בדיקה. לדוגמה, אנדרואיד 4.4 ממשיכה לקבל תיקונים (ראה https://android-review.googlesource.com/#/c/273371/ ).

שאלות נפוצות (שאלות נפוצות)

ש: מי אחראי להחלת עדכוני אבטחה למימוש ספציפי של אנדרואיד?

ת: היצרן המספק ישירות את המכשיר אחראי. ישות זו אינה גוגל, אשר מפרסמת עדכוני אבטחה ב-AOSP ולא עבור מכשיר ספציפי (כגון רכב).

ש: איך גוגל מטפלת בבעיות אבטחה באנדרואיד?

ת: גוגל חוקרת ללא הרף בעיות ומפתחת תיקונים פוטנציאליים, ש-Google מאפשרת לכל רמות ה-API הנתמכות כחלק מתהליך עדכון האבטחה הרגיל. מאז אוגוסט 2015, גוגל שומרת על קצב קבוע של פרסום עלונים וקישורים לעדכונים ל- source.android.com ; גוגל גם מפרסמת עדכוני אבטחה כחלק ממהדורות עיקריות של מערכת ההפעלה. ראה גם את מדיניות האבטחה האחורית .

ש: אם יצרן שילב את כל תיקוני ה-AOSP מ-ASB אך לא שילב תיקונים של ספק BSP שהוזכר באותו עלון, האם הוא עדיין יכול להעלות את רמת האבטחה (לדוגמה, להחיל את התיקון המתאים לפלטפורמה/בנייה) ?

ת: כדי להצהיר על רמת תיקון אבטחה של Android (SPL), היצרן חייב לטפל בכל הבעיות הנדרשות שפורסמו בעלון האבטחה של אנדרואיד ( כולל עלונים קודמים ) וממופות ל-Android SPL מסוים. לדוגמה, יצרן המשתמש בעלון האבטחה של מרץ 2017 (2017-03-01 SPL) טיפל בכל הבעיות הנדרשות שתועדו בעלון מרץ 2017 עבור אותו SPL ובכל העדכונים הקודמים, כולל עדכונים ספציפיים למכשיר עבור כל עלוני האבטחה הקודמים של Android, כולל העדכונים הספציפיים למכשיר המשויכים ל- 2017-02-05 SPL.

ש: מה קורה כאשר היצרן לא מסכים עם עדכוני אבטחה שסופקו על ידי ספק BSP או כאשר עדכוני אבטחה שנקבעו על ידי ASB אינם מסופקים על ידי ספקים?

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

לדוגמה, שקול מקרה שבו גוגל מטפלת בפגיעות אבטחה של AOSP באמצעות שינוי קוד המאפשר לרכיב להישאר פונקציונלי במלואו ותואם ל-CDD. אם היצרן מחליט שאין צורך ברכיב במכשיר או שאינו מחייב על ידי ה-CDD (או בדיקות הסמכה קשורות), היצרן יכול להסיר את הרכיב כדי להפחית את צרכי השירות העתידיים ולהפחית את משטח ההתקפה. למרות שהיצרן לא השתמש בעדכון האבטחה שסופק, הוא הבטיח שהמכשיר אינו פגיע ל-CVE המתועד בעלון האבטחה. עם זאת, בסטייה מעדכון האבטחה המומלץ, היצרן לוקח סיכון של טיפול שגוי בבעיה, הצגת פרצות אבטחה חדשות או הפחתת פונקציונליות אחרת של ה-build הסופי.

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

לבסוף, במקרים שבהם זה בלתי אפשרי לרכוש ישירות או ליצור באופן עצמאי תיקון לבעיה המתועדת ב-ASB, יצרן יכול לשמור על ה-SPL הקודם של Android ועדיין להוסיף את התיקונים הזמינים החדשים ל-build. עם זאת, נוהג זה יוביל בסופו של דבר לבעיות בהסמכת ה-build (כיוון ש-Android מבטיח שרמת תיקון האבטחה העדכנית ביותר זמינה במכשירים מאושרים). Google ממליצה לעבוד עם ה-SoC שלך מראש כדי להימנע מנוהג זה.

ש: אם היצרן קובע שפריט ASB אינו מתאים למוצר שלו, האם עדיין יש להחיל או לתקן את הפריט כדי לעמוד בדרישות האחרות של Google או לעבור CTS?

ת: אנחנו לא דורשים לקחת תיקונים כדי להצהיר על רמת תיקון אבטחה של אנדרואיד (SPL); אנו דורשים שהיצרן יעיד שהמבנה שלו אינו פגיע לבעיה.

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

זה שונה מהותית מיצרן שרוצה, למשל, לתקן רק תיקונים קריטיים, מבלי לקחת תיקונים ישימים אחרים שיגרמו למבחן אבטחה להיכשל. במקרה זה מניחים שה-SPL לא התקיים.