Options pour les développeurs sécurisées

Conformément au document de définition de compatibilité Android, les OEM doivent fournir un moyen d'activer le développement d'applications. Toutefois, proposer des options pour les développeurs semblables à celles des appareils mobiles dans les voitures les rend vulnérables aux attaques. Les OEM peuvent désormais limiter l'accès aux options pour les développeurs à l'aide d'un mécanisme de jeton cryptographique authentifié. Plus précisément, un OEM peut :

  • spécifier des restrictions par défaut avant le premier démarrage ;
  • autoriser les développeurs de manière sécurisée, avec des jetons cryptographiques si vous le préférez ;
  • appliquer les modifications de restriction une fois qu'un développeur est authentifié et autorisé.

Cette page 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 Terminologie, les termes suivants sont utilisés sur cette page :

  • Signature Web JSON (JWS), définie dans le document RFC 7515
  • NIST (National Institute of Standards and Technology)

Conception

Les OEM peuvent autoriser les développeurs avec des 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 utilisés par l'application de contrôleur de restriction. Ils sont conçus pour résister aux attaques par relecture et aux jetons falsifiés.

Figure 1. Conception

Intégration et configuration

Les OEM doivent spécifier des restrictions par défaut lors du premier démarrage. Pour ce faire, ils utilisent plusieurs superpositions de ressources statiques afin de remplacer les valeurs par défaut dans le framework AOSP.

Les restrictions par défaut pour l'utilisateur du système sans interface graphique 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>
        <item>no_install_unknown_sources</item>
        <item>no_install_unknown_sources_globally</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 pour chaque type d'utilisateur, par exemple :

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

Contrôleur de préférence du numéro de build

Dans AAOS, l'interaction de l'utilisateur avec la ligne de préférence Numéro de build dans les paramètres est gérée par BuildNumberPreferenceController.java, qui se trouve dans packages/apps/Car/Settings/src/com/android/car/settings/system/BuildNumberPreferenceController.java.

Lorsque la restriction utilisateur no_debugging_features (UserManager.DISALLOW_DEBUGGING_FEATURES) est définie, BuildNumberPreferenceController supprime le compte à rebours du développeur sur les builds de production (user) lorsque l'utilisateur appuie dessus :

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

L'utilisation de Build.IS_USER garantit que les builds de production appliquent strictement le verrouillage de sécurité, tandis que les équipes d'ingénierie internes des builds userdebug peuvent toujours accéder aux options pour les développeurs à l'aide du geste à sept doigts pour les tests sans remplacement manuel de l'interface de ligne de commande (CLI).

Contrôleur de restriction de débogage

Une implémentation de référence du contrôleur de restriction de débogage (DRC) est fournie dans AOSP à l'adresse packages/apps/Car/DebuggingRestrictionController.

Le DRC permet aux OEM de lever temporairement et de manière dynamique la restriction no_debugging_features sur les véhicules de production pour les techniciens de maintenance et les développeurs autorisés. Au lieu de laisser les outils de débogage ouverts en permanence ou de nécessiter des réinstallations de micrologiciel, l'application DRC intégrée au véhicule invite l'utilisateur à s'authentifier auprès du backend OEM et à envoyer un jeton d'accès signé cryptographiquement pour activer adb et les options pour les développeurs pendant une session de diagnostic limitée.

L'implémentation de référence du DRC comprend deux composants principaux :

  • Application cliente DRC intégrée au véhicule (app/) : application système privilégiée (détenant l'autorisation MANAGE_USERS) sur l'unité principale qui authentifie les développeurs, valide la signature du certificat X.509, le nom d'hôte, le nonce et l'expiration des jetons JWS entrants, et active/désactive dynamiquement la restriction no_debugging_features à l'aide de UserManager.
  • Émetteur de jetons cloud (server/) : service Web backend (déployable en tant que fonctions Cloud Firebase) qui authentifie les identifiants de développeur et émet des jetons d'accès JWS RS256 signés cryptographiquement avec une fenêtre d'expiration limitée.

Pour obtenir des instructions de configuration complètes, des outils de génération de certificats et des étapes de déploiement, consultez le guide d'intégration du contrôleur de restriction de débogage.

Tests

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

  1. Après avoir configuré les restrictions 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.
  2. Facultatif : Configurez le système pour qu'il utilise votre service cloud compatible avec JWS. Vérifiez que le flux attendu est observé sur votre service backend.