מדריך ליצרנים בנושא אבטחה לטווח ארוך ב-Android

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

תודות וכתבי ויתור

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

משוב

המדריך הזה לא מיועד להיות מקיף, ואנחנו מתכננים לערוך בו עוד שינויים. אפשר לשלוח משוב לכתובת manufacturers-guide-android@googlegroups.com.

מילון מונחים

מונח הגדרה
ACC התחייבות לתאימות ל-Android. ההסכם נקרא בעבר 'הסכם למניעת פיצול של Android' (AFA).
AOSP פרויקט קוד פתוח של Android
ASB חדשות האבטחה של Android
BSP חבילת תמיכה של הלוח (BSP)
CDD מסמך הגדרת תאימות (CDD)
CTS חבילה לבדיקות תאימות (CTS)
FOTA קושחה אונליין
GPS מערכת מיקום גלובלית
MISRA Motor Industry Software Reliability Association
NIST המכון הלאומי לתקנים וטכנולוגיה (National Institute of Standards and Technology)
OBD אבחון במכונה (OBD-II הוא שיפור על פני OBD-I גם מבחינת היכולות וגם מבחינת התקינה)
OEM יצרן ציוד מקורי
מערכת הפעלה מערכת הפעלה
SEI Software Engineering Institute
SoC מערכת על שבב (SoC)
SOP תחילת הייצור
SPL רמת תיקון האבטחה
TPMS מערכת לניטור לחץ האוויר בצמיגים

מידע על Android OS

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

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

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

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

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

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

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

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

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

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

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

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

# שלב פעילויות

①

 Development Branch היצרן בוחר גרסת Android (Android X). בדוגמה הזו, 'Android X' הוא הבסיס למה שיישלח ברכב שנתיים לפני תחילת הייצור (SOP).
② השקה ראשונית כמה חודשים לפני ש-Android X הופכת לגרסה הראשונה של מערכת ההפעלה שמיוצרת במוצר, עדכוני האבטחה נלקחים מעדכוני האבטחה של Android‏ (ASB) וממקורות אחרים, אם היצרן סבור שהם מועילים. y2 = עדכון האבטחה השני לגרסה X של Android, שהוחל (הועבר לאחור) על ידי היצרן ב-Android X. העדכון הזה מגיע עם המוצר, והשעון של סבב הייצור מתחיל לתקתק בשנה אפס עם Android X.y2.

בדוגמה הזו, היצרן החליט לא לשלוח את הגרסה השנתית העדכנית יותר של Android X+1. הסיבות למהדורה האחרונה כוללות הוספת תכונות חדשות, תיקון נקודות חולשה חדשות באבטחה ו/או הפצה של שירותי Google או שירותים של צד שלישי שדורשים את הגרסה העדכנית יותר של Android. הסיבות לעומת השקת הגרסה האחרונה הן מחסור בזמן בתהליך הפיתוח וההשקה של הרכב, שנדרש כדי לשלב, לבדוק ולאמת את השינויים, כולל תאימות לכל הדרישות הרגולטוריות והאישורים.
③ עדכון מלא של מערכת ההפעלה לאחר השלמת תהליך ה-SOP, היצרן משחרר עדכון למערכת ההפעלה Android X+2, שזהו עדכון שני של Android אחרי הגרסה ששימשה את המוצר הראשוני (Android X0). עדכוני האבטחה של ASB זמינים לרמת ה-API (החל מתאריך השליחה), כך שהעדכון יוצא כ-X+2.y0 כ-1.25 שנה אחרי SOP. יכול להיות שעדכון מערכת ההפעלה הזה תואם למוצרים שמוצבים בשטח, ויכול להיות שלא. אם כן, אפשר ליצור תוכנית לעדכון רכבים שנפרסו.

אלא אם יש הסכמים עסקיים אחרים, ההחלטה לבצע עדכון מלא של מערכת ההפעלה היא לחלוטין בשיקול דעתו של היצרן.
④ עדכון אבטחה שנתיים לאחר תחילת חיי הרכב, היצרן מתקן את מערכת ההפעלה Android X+2. ההחלטה הזו מבוססת על הערכת הסיכון של היצרן. היצרן בוחר את עדכון האבטחה השלישי של ASB לגרסה X+2 כבסיס לעדכון. המוצרים שמקבלים את עדכון האבטחה כוללים עכשיו את מערכת ההפעלה (X+2.y3) ואת רמת תיקון האבטחה של Android.

יצרנים יכולים לבחור תיקוני אבטחה נפרדים מכל עדכון אבטחה ספציפי ל-Android, אבל הם חייבים לתקן את כל הבעיות הנדרשות בעדכון כדי להשתמש ברמת תיקון האבטחה (SPL) של Android שמשויכת לעדכון (לדוגמה, 2017-02-05). האחריות לבצע את ההעברה לאחור ואת פרסום הגרסה עם תיקוני האבטחה למוצר הנתמך היא של היצרן.
⑤ עדכון מלא של מערכת ההפעלה חזרה על שלב 3 (עדכון מלא של מערכת ההפעלה). עדכון מערכת ההפעלה המלא השני מעדכן את המוצר ל-Android X+4, שלוש שנים לאחר תחילת חיי הייצור של הרכב. היצרן יכול עכשיו לאזן בין דרישות החומרה החדשות יותר של גרסת Android עדכנית לבין החומרה במוצר, והמשתמש נהנה ממערכת Android OS מעודכנת. היצרן משחרר עדכון ללא עדכוני אבטחה, כך שהמוצר נמצא עכשיו ברמת (X+4.y0) OS + Android Security Patch.

בדוגמה הזו, עקב מגבלות חומרה, X+4 היא הגרסה הראשית האחרונה של Android שתהיה זמינה למוצר הזה, למרות שעדיין נדרשת תמיכת אבטחה ל-6 שנים ומעלה מחיי הרכב הצפויים.
⑥ עדכון אבטחה חזרה על שלב 4 (עדכון אבטחה). היצרן צריך להעביר עדכוני אבטחה של ASB מגרסה מאוחרת יותר של Android (X+6) ולהעביר חלק מהעדכונים האלה או את כולם חזרה ל-Android X+4. באחריות היצרן למזג, לשלב ולבצע את העדכונים (או לחתום על חוזה עם צד שלישי). בנוסף, היצרן צריך לדעת שבעיות אבטחה בגרסאות של Android שכבר לא נתמכות לא נכללות ב-ASB.
⑦ עדכון אבטחה אחרי שמונה שנים במחזור החיים של הרכב, ארבעה גרסאות Android מאז העדכון האחרון של מערכת ההפעלה בשלב 5 (עדכון מלא של מערכת ההפעלה) ועשר שנים מאז שהוגדרה Android X, נטל ניהול התיקוני האבטחה והעברתם לאחור (backport) מוטל על היצרן לגבי הגרסאות האלה, אם הן ישנות מ-3 שנים מהגרסה הציבורית ברמת ה-API.

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

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

הנחיות אבטחה

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

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

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

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

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

מדיניות להעברת תיקוני אבטחה לגרסאות קודמות

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

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

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

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

מקורות מידע נוספים

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

תהליך העבודה של CTS

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

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

עוברים את הבדיקה של CTS

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

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

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

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

שאלות נפוצות

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

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

שאלה: איך Google מטפלת בבעיות אבטחה ב-Android?

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

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

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

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

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

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

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

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

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

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

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

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