אבטחה של האפשרויות למפתחים

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

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

בדף הזה מתואר יישום לדוגמה שכולל אפליקציית בקרה להגבלת ניפוי באגים ונקודת קצה (endpoint) מרוחקת להנפקת טוקנים.

הסברים על המונחים

בנוסף למינוח, נעשה שימוש במונחים הבאים בדף הזה:

• חתימת רשת מבוססת JSON‏ (JWS), מוגדרת ב-RFC 7515
• המכון הלאומי לתקנים וטכנולוגיה (NIST)

עיצוב

יצרני ציוד מקורי יכולים להעניק הרשאה למפתחים באמצעות אסימוני JSON Web Signature‏ (JWS) (RFC7515). ביישום ההפניה, טוקנים לגישה מונפקים על ידי יצרני ציוד מקורי (OEM) ונצרכים על ידי אפליקציית בקרת ההגבלות. טוקנים לגישה מיועדים לעמוד בפני מתקפות שידור חוזר וטוקנים מזויפים.

איור 1. עיצוב

שילוב והגדרה

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

אפשר להגדיר את הגבלות ברירת המחדל למשתמש המערכת ללא ממשק משתמש באמצעות המחרוזת config_defaultFirstUserRestrictions ב- frameworks/base/core/res/res/values/config.xml, לדוגמה:

<!-- User restrictions set when the first user is created.
         Note: Also update appropriate overlay files. -->
    <string-array translatable="false" name="config_defaultFirstUserRestrictions">
        <item>no_debugging_features</item>
        <item>no_install_unknown_sources</item>
        <item>no_install_unknown_sources_globally</item>
    </string-array>

אפשר להגדיר את הגבלות ברירת המחדל לנהגים, לנוסעים ולאורחים ב-frameworks/base/core/res/res/xml/config_user_types.xml. יצרן ציוד מקורי יכול להוסיף את המחרוזות האלה כדי להגדיר את ההגבלות שמוגדרות כברירת מחדל על כל סוג משתמש, לדוגמה:

<user-types>
    <full-type name="android.os.usertype.full.SECONDARY" >
        <default-restrictions
            no_debugging_features="true"
            no_install_unknown_sources="true"/>
    </full-type>
    <full-type name="android.os.usertype.full.GUEST" >
        <default-restrictions
            no_debugging_features="true"
            no_install_unknown_sources="true"/>
    </full-type>
</user-types>

אמצעי בקרה להעדפות של מספר ה-Build

ב-AAOS, אינטראקציה של משתמש עם שורת ההעדפות מספר Build בהגדרות מטופלת על ידי BuildNumberPreferenceController.java שנמצא ב packages/apps/Car/Settings/src/com/android/car/settings/system/BuildNumberPreferenceController.java.

כשההגבלה על המשתמש no_debugging_features (UserManager.DISALLOW_DEBUGGING_FEATURES) מוגדרת, האפשרות BuildNumberPreferenceController משביתה את הספירה לאחור של המפתחים בגרסאות build של הייצור (user) כשמקישים עליה:

@Override
protected boolean handlePreferenceClicked(Preference preference) {
    if (DevelopmentSettingsUtil.isDevelopmentSettingsEnabled(getContext())) {
        return true;
    }

    // Enforce restriction on production (user) builds
    if (Build.IS_USER && mUserManager.hasUserRestriction(UserManager.DISALLOW_DEBUGGING_FEATURES)) {
        showToast(R.string.dev_access_blocked_toast);
        return true;
    }

    mDevHitCountdown--;
    if (mDevHitCountdown == 0) {
        DevelopmentSettingsUtil.setDevelopmentSettingsEnabled(getContext(), true);
        showToast(R.string.show_dev_on);
    }
    return true;
}

השימוש ב-Build.IS_USER מבטיח שגרסאות build לייצור יאכפו באופן מחמיר את נעילת האבטחה, בעוד שצוותי הנדסה פנימיים בגרסאות build של userdebug עדיין יכולים לגשת לאפשרויות למפתחים באמצעות תנועת 7 ההקשות לבדיקה, ללא ביטולים ידניים של ממשק שורת הפקודה (CLI).

ניפוי באגים ב-Restriction Controller

יישום לדוגמה של Debugging Restriction Controller (DRC) זמין ב-AOSP בכתובת packages/apps/Car/DebuggingRestrictionController.

ה-DRC מאפשר ליצרני ציוד מקורי (OEM) להסיר באופן דינמי וזמני את ההגבלה no_debugging_features על רכבים בייצור עבור טכנאי שירות ומפתחים מורשים. במקום להשאיר כלי ניפוי באגים פתוחים באופן קבוע או לדרוש שינוי קושחה, אפליקציית ה-DRC ברכב מבקשת מהמשתמש לאמת את עצמו באמצעות קצה העורף של יצרן הציוד המקורי (OEM) ולשלוח אסימון גישה חתום קריפטוגרפית כדי להפעיל את adb ואת אפשרויות הפיתוח לסשן אבחון מוגבל.

ההטמעה לדוגמה של DRC כוללת שני רכיבים מרכזיים:

• אפליקציית לקוח DRC ברכב (app/): אפליקציית מערכת בעלת הרשאות (עם ההרשאה MANAGE_USERS) במערכת המולטימדיה, שמאמתת מפתחים, מאמתת את החתימה של אישור X.509, את שם המארח, את הצופן החד-פעמי ואת תאריך התפוגה של אסימוני JWS נכנסים, ומפעילה או משביתה באופן דינמי את ההגבלה no_debugging_features באמצעות UserManager.
• Cloud Token Issuer ‏ (server/): שירות אינטרנט בקצה העורפי (ניתן לפריסה כ-Firebase Cloud Functions) שמאמת את פרטי הכניסה של המפתח ומנפיק אסימוני גישה של RS256 JWS בחתימה קריפטוגרפית עם חלון תפוגה סופי.

הוראות מלאות להגדרה, כלים ליצירת אישורים ושלבי פריסה מופיעים במדריך לשילוב של Debugging Restriction Controller.

בדיקה

‫Google ממליצה ליצרני ציוד מקורי (OEM) להתחיל בהטמעה לדוגמה ולהרחיב אותה משם.

1. אחרי שמגדירים את ההגבלות בקובצי שכבת העל, קומפלו את AAOS ומוודאים שהזרימות שהוגדרו תקינות. משתמשים באפליקציית ההפניה ובשירות מקומי עם תמיכה ב-JWS כדי לאמת את הגדרות הגישה.
2. אופציונלי: מגדירים את המערכת כך שתשתמש בשירות הענן עם JWS. מוודאים שאתם רואים את התהליך הצפוי בשירות הקצה העורפי.