Entwickleroptionen schützen

Gemäß dem Android Compatibility Definition Document müssen OEMs eine Möglichkeit zur App-Entwicklung bieten. Wenn Entwicklern jedoch ähnliche Optionen wie bei Smartphones zur Verfügung gestellt werden, sind diese Autos anfällig für Angriffe. Der Zugriff auf Entwickleroptionen kann jetzt von einem OEM mithilfe eines authentifizierten kryptografischen Tokenmechanismus eingeschränkt werden. Insbesondere kann ein OEM:

  • Legen Sie die gewünschten Standardeinschränkungen vor dem ersten Start fest.
  • Entwickler sicher autorisieren, vorzugsweise mit Krypto-Tokens.
  • Änderungen an den Einschränkungen werden angewendet, sobald ein Entwickler sowohl authentifiziert als auch autorisiert ist.

In diesem Artikel wird eine Referenzimplementierung beschrieben, die aus einer App für die Begrenzung der Debug-Funktionen und einem Endpunkt für Remote-Tokenaussteller besteht.

Terminologie

Zusätzlich zu den Begriffen unter Terminologie werden in diesem Artikel 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 für die Einschränkungssteuerung verwendet. Zugriffstokens sind so konzipiert, dass sie Manipulationen und gefälschten Tokens standhalten.

Abbildung 1: Design

Integration und Konfiguration

OEMs müssen die gewünschten Standardeinschränkungen beim ersten Start angeben. Dazu werden mehrere statische Ressourcen-Overlays verwendet, um die Standardeinstellungen 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>
    </string-array>

Die Standardeinschränkungen für Fahrer, Mitfahrer 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 die einzelnen Nutzertypen festzulegen, z. B.:

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

Eine Referenzimplementierung finden Sie im AOSP an folgendem Ort:

packages/apps/Car/DebuggingRestrictionController

Testen

Google empfiehlt OEMs, mit der Referenzimplementierung zu beginnen und von dort aus weiterzuarbeiten.

  1. Nachdem Sie die gewünschten 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-kompatiblen Dienst, um Ihre Zugriffseinstellungen zu überprüfen.
  2. Konfigurieren Sie das System so, dass es Ihren JWS-kompatiblen Cloud-Dienst verwendet (optional). Prüfen Sie, ob der gewünschte Ablauf in Ihrem Backend-Dienst eingehalten wird.