Sécurisation des options de développement

Restez organisé à l'aide des collections Enregistrez et classez les contenus selon vos préférences.

Selon le document de définition de compatibilité Android , les OEM doivent fournir un moyen d'activer le développement d'applications. Cependant, fournir des options de développement de type mobile dans les voitures rend ces voitures vulnérables aux attaques. L'accès aux options de développement peut désormais être contrôlé 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 en toute sécurité, avec des jetons cryptographiques si vous préférez.
  • 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 jeton distant.

Terminologie

En plus de Terminologie , ces termes sont utilisés dans cet article :

  • Signature Web JSON (JWS), définie dans RFC 7515
  • Institut national des normes et de la technologie (NIST)

Concevoir

Les OEM peuvent autoriser les développeurs avec des jetons JSON Web Signature (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 de rejeu et aux jetons falsifiés.

Figure 1. Conception

Intégration et configuration

Les OEM doivent spécifier les restrictions par défaut souhaitées lors du premier démarrage. Cela se fait avec plusieurs superpositions de ressources statiques pour remplacer les valeurs par défaut dans le cadre AOSP.

Les restrictions par défaut pour l'utilisateur du système sans tête 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 respectivement, 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

Essai

Google recommande aux OEM de commencer par l'implémentation de référence et de partir de là.

  1. 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 compatible JWS local pour vérifier vos paramètres d'accès.
  2. Configurez le système pour utiliser votre service cloud compatible JWS (facultatif). Vérifiez que vous observez le flux souhaité sur votre service de backend.