Entwickleroptionen schützen

Gemäß dem Android Compatibility Definition Document, müssen OEMs eine Möglichkeit zur App-Entwicklung bieten. Wenn jedoch Entwickleroptionen für Mobilgeräte in Autos bereitgestellt werden, sind diese Autos anfällig für Angriffe. Der Zugriff auf Entwickleroptionen kann jetzt von einem OEM mithilfe eines authentifizierten kryptografischen Token-Mechanismus eingeschränkt werden. Ein OEM kann Folgendes tun:

  • Standardeinschränkungen vor dem ersten Start festlegen.
  • Entwickler sicher autorisieren, bei Bedarf mit Kryptotokens.
  • Einschränkungen anwenden, sobald ein Entwickler authentifiziert und autorisiert wurde.

Auf dieser Seite wird eine Referenzimplementierung beschrieben, die aus einer App zur Steuerung von Debugging-Einschränkungen und einem Remote-Endpunkt für die Token-Ausstellung besteht.

Terminologie

Zusätzlich zu Terminologie, werden auf dieser Seite die folgenden Begriffe verwendet:

  • JSON Web Signature (JWS), definiert in RFC 7515
  • National Institute of Standards and Technology (NIST)

Design

OEMs können Entwickler mit JSON Web Signature (JWS)-Tokens (RFC7515) autorisieren. In der Referenzimplementierung werden Zugriffstokens von OEMs ausgestellt und von der App zur Steuerung von Einschränkungen verwendet. Zugriffstokens sind so konzipiert, dass sie Replay-Angriffen und gefälschten Tokens widerstehen.

Abbildung 1. Design

Integration und Konfiguration

OEMs müssen beim ersten Start Standardeinschränkungen festlegen. Dazu verwenden sie mehrere statische Ressourcen-Overlays, um die Standardwerte im AOSP-Framework zu überschreiben.

Die Standardeinschränkungen für den Headless-Systemnutzer können mit dem String config_defaultFirstUserRestrictions in frameworks/base/core/res/res/values/config.xml konfiguriert werden, z. B.:

<!-- 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>

Die Standardeinschränkungen für Fahrer, Beifahrer und Gäste können in frameworks/base/core/res/res/xml/config_user_types.xml konfiguriert werden. Ein OEM kann diese Strings überlagern, um die Standardeinschränkungen für jeden Nutzertyp festzulegen, z. B.:

<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>

Controller für die Build-Nummer-Einstellung

In AAOS wird die Nutzerinteraktion mit der Einstellungszeile Build-Nummer in den Einstellungen von BuildNumberPreferenceController.java verarbeitet, das sich in packages/apps/Car/Settings/src/com/android/car/settings/system/BuildNumberPreferenceController.java befindet.

Wenn die Nutzereinschränkung no_debugging_features (UserManager.DISALLOW_DEBUGGING_FEATURES) festgelegt ist, unterdrückt BuildNumberPreferenceController den Countdown für Entwickler in Produktionsversionen (user), wenn darauf getippt wird:

@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;
}

Mit Build.IS_USER wird sichergestellt, dass in Produktionsversionen die Sicherheitsbeschränkungen strikt durchgesetzt werden. Interne Entwicklungsteams können in userdebug-Versionen weiterhin über die 7-mal-Tippen-Geste auf Entwickleroptionen zugreifen, um Tests durchzuführen, ohne manuelle Überschreibungen über die Befehlszeilenschnittstelle (Command-Line Interface, CLI) vornehmen zu müssen.

Controller für Debugging-Einschränkungen

Eine Referenzimplementierung des Controllers für Debugging-Einschränkungen (Debugging Restriction Controller, DRC) ist in AOSP unter packages/apps/Car/DebuggingRestrictionController verfügbar.

Mit dem DRC können OEMs die Einschränkung no_debugging_features für Produktionsfahrzeuge für autorisierte Servicetechniker und Entwickler dynamisch und vorübergehend aufheben. Anstatt Debugging-Tools dauerhaft geöffnet zu lassen oder Firmware-Updates zu erzwingen, fordert die DRC-App im Fahrzeug den Nutzer auf, sich beim OEM-Back-End zu authentifizieren und ein kryptografisch signiertes Zugriffstoken zu senden, um adb und Entwickleroptionen für eine begrenzte Diagnosesitzung zu aktivieren.

Die DRC-Referenzimplementierung besteht aus zwei Hauptkomponenten:

  • DRC-Client-App im Fahrzeug (app/) : Eine privilegierte System-App (mit der Berechtigung MANAGE_USERS) auf der Head-Unit, die Entwickler authentifiziert, die X.509-Zertifikatsignatur, den Hostnamen, die Nonce und das Ablaufdatum eingehender JWS-Tokens validiert und die Einschränkung no_debugging_features dynamisch mit UserManager aktiviert oder deaktiviert.
  • Cloud-Token-Aussteller (server/) : Ein Back-End-Webdienst (der als Firebase Cloud Functions bereitgestellt werden kann), der Entwickleranmeldedaten authentifiziert und kryptografisch signierte RS256-JWS-Zugriffstokens mit einem begrenzten Ablaufzeitraum ausstellt.

Eine vollständige Einrichtungsanleitung, Tools zur Zertifikatsgenerierung und Bereitstellungsschritte finden Sie im Integrationsleitfaden für den Controller für Debugging-Einschränkungen.

Test

Google empfiehlt OEMs, mit der Referenzimplementierung zu beginnen und diese dann weiterzuentwickeln.

  1. Nachdem Sie die Einschränkungen in den Overlay-Dateien konfiguriert haben, kompilieren Sie AAOS und validieren Sie die definierten Abläufe. Verwenden Sie die Referenz-App und den lokalen JWS-fähigen Dienst , um Ihre Zugriffseinstellungen zu überprüfen.
  2. Optional: Konfigurieren Sie das System so, dass es Ihren JWS-fähigen Clouddienst verwendet. Prüfen Sie, ob der erwartete Ablauf in Ihrem Backend-Dienst beobachtet wird.