Conformément au document de définition de la compatibilité Android, les OEM doivent fournir un moyen d'activer le développement d'applications. Toutefois, fournir des options de développement semblables à celles des mobiles dans les voitures les rend vulnérables aux attaques. L'accès aux options pour les développeurs peut désormais être limité par un OEM à l'aide d'un mécanisme de jeton cryptographique authentifié. Plus précisément, un OEM peut:
- Définissez les restrictions par défaut souhaitées avant le premier démarrage.
- Autorisez les développeurs de manière sécurisée, avec des jetons cryptographiques si vous le souhaitez.
- Appliquez les modifications de restriction une fois qu'un développeur est à la fois authentifié et autorisé.
Cet article décrit une implémentation de référence composée d'une application de contrôleur de restriction de débogage et d'un point de terminaison d'émetteur de jetons à distance.
Terminologie
En plus de la terminologie, les termes suivants sont utilisés dans cet article:
- Signature Web JSON (JWS), définie dans la RFC 7515
- National Institute of Standards and Technology (NIST)
Conception
Les OEM peuvent autoriser les développeurs à l'aide de jetons de signature Web JSON (JWS, RFC7515). Dans l'implémentation de référence, les jetons d'accès sont émis par les OEM et consommés par l'application du contrôleur de restriction. Les jetons d'accès sont conçus pour résister aux attaques par rejeu et aux jetons contrefaits.
Figure 1 : Conception
Intégration et configuration
Les OEM doivent spécifier les restrictions par défaut souhaitées au premier démarrage. Pour ce faire, plusieurs superpositions de ressources statiques sont utilisées pour remplacer les valeurs par défaut du framework AOSP.
Les restrictions par défaut pour l'utilisateur système headless peuvent être configurées avec la chaîne config_defaultFirstUserRestrictions dans frameworks/base/core/res/res/values/config.xml, par exemple:
<!-- 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>Les restrictions par défaut pour les conducteurs, les passagers et les invités peuvent être configurées dans frameworks/base/core/res/res/xml/config_user_types.xml. Un OEM peut superposer ces chaînes pour définir les restrictions par défaut sur chaque type d'utilisateur, par exemple:
<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>
Une implémentation de référence est fournie à l'emplacement suivant dans AOSP:
packages/apps/Car/DebuggingRestrictionController
Tests
Google recommande aux OEM de commencer par l'implémentation de référence et de partir de là.
- Après avoir configuré les restrictions souhaitées dans les fichiers de superposition, compilez AAOS et validez les flux définis. Utilisez l'application de référence et le service local compatible avec JWS pour vérifier vos paramètres d'accès.
- Configurez le système pour qu'il utilise votre service cloud compatible avec JWS (facultatif). Vérifiez que vous observez le flux souhaité sur votre service de backend.