Guide d'intégration du contrôleur de restriction de débogage

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

Utilisez les instructions suivantes pour intégrer le contrôleur de restriction de débogage AAOS (DRC).

Figure 1. Exemple d'application DRC

Architecture

L'architecture de la RDC est illustrée ci-dessous. Les composants indiqués en rouge (émetteur de jeton et contrôleur de restriction débutant) sont accompagnés d'implémentations de référence que vous pouvez personnaliser.

Figure 2. Architecture de la RDC

Qu'est-ce que la RDC ?

L'unité principale de la voiture inclut l'application DRC (voir l'implémentation de référence dans packages/apps/Car/DebuggingRestrictionController ). L'application de référence inclut la logique pour recevoir un jeton d'accès de l'émetteur de jeton, valider le jeton, puis appliquer les modifications de restriction de débogage comme spécifié dans le jeton. La logique comprend des éléments UX de base côté voiture.

Qu'est-ce que l'émetteur de jetons ?

Il s'agit d'un service Web qui émet des jetons d'accès signés de manière cryptographique (voir l'implémentation de référence dans packages/apps/Car/DebuggingRestrictionController/server ). Le service web de référence est une fonction Firebase Cloud déployable (pour en savoir plus, consultez Fonctions Cloud pour Firebase ).

Conditions préalables

Avant de déployer une implémentation de référence, veillez à effectuer les tâches suivantes.

Préparation des certificats pour la signature des jetons d'accès

L'émetteur de jetons génère des signatures Web JSON (JWS) en tant que jetons d'accès. Pour une compatibilité optimale, l'émetteur de référence ne supporte que l'algorithme RS256 (signatures RSA avec SHA256). Pour faciliter la rotation des clés, utilisez une chaîne de certificats au lieu d'un seul certificat pour signer les jetons d'accès. Une chaîne de certificats typique doit être constituée d'un certificat d'autorité de certification racine, d'un certificat d'autorité de certification intermédiaire et d'un certificat d'entité finale.

Le certificat d'entité finale signant les jetons JWS n'est pas différent d'un certificat TLS standard. Vous pouvez soit acheter un certificat auprès d'autorités de certification publiques telles que DigiCert, soit gérer votre propre chaîne de certificats à l'aide de certificats d'autorité de certification racine auto-signés ou de modules de sécurité matériels. Le certificat d'entité finale doit être un certificat X509v3 avec une extension SAN (Subject Alternative Name). L'extension SAN contient un identifiant (par exemple, le nom d'hôte) de l'émetteur du jeton. Enfin, les certificats RSA doivent être préférés aux certificats EC car l'émetteur de jetons ne prend en charge que le RS256.

Google fournit un script shell pour générer des certificats auto-signés dans packages/apps/Car/DebuggingRestrictionController/server/genkey.sh .

Configurer Firebase

La référence Token Issuer utilise Firebase Authentication et Firebase Cloud Function .

Pour configurer votre compte Firebase :

  1. Pour créer un projet Firebase, consultez Ajouter Firebase à votre projet Android .
  2. Pour activer certains authentificateurs Firebase, consultez Par où commencer avec l'authentification Firebase ? .
  3. Pour ajouter une fonction Firebase Cloud vide, consultez Premiers pas .
  4. Si ce n'est déjà fait, installez Node.js, NPM et Firebase Tools pour compiler et déployer l'émetteur de jetons.

Intégration de l'application DRC

L'application DRC de référence se trouve dans packages/apps/Car/DebuggingRestrictionController . L'application peut être intégrée dans AOSP avec Soong ou dégroupée avec Gradle .

Version groupée

Pour créer une application groupée :

  1. Copiez les applicationId , projectId et apiKey de google-services.json dans packages/apps/Car/DebuggingRestrictionController/soong/FirebaseApplication.java . Cela permet à l'application DRC de se connecter correctement à Firebase.
  2. Mettez à jour ces constantes dans packages/apps/Car/DebuggingRestrictionController/soong/BuildConfig.java :
    • TOKEN_USES_SELF_SIGNED_CA indique si des certificats d'autorité de certification racine auto-signés sont utilisés. Si elle est activée, l'application DRC n'approuve que le certificat d'autorité de certification racine codé PEM spécifié dans ROOT_CA_CERT .
    • TOKEN_ISSUER_API_NAME est le nom de la fonction Firebase Cloud et doit correspondre à la fonction Cloud que vous avez créée précédemment dans la console Firebase.
    • TOKEN_ISSUER_HOSTNAME doit correspondre à l'autre nom du sujet dans le certificat d'entité finale qui signera les jetons d'accès.
    • DRC_TEST_EMAIL et DRC_TEST_PASSWORD sont des informations d'identification pour un compte de test facultatif, qui peut être pré-provisionné dans Firebase si vous avez activé la connexion par e-mail/mot de passe. Ceux-ci sont utilisés uniquement pour les tests instrumentés.

L'application est maintenant configurée pour utiliser votre compte Firebase et vos certificats. Dans Android 9 et versions ultérieures, vous devez configurer la liste d' autorisation des autorisations privilégiées . La liste d'autorisation doit contenir au moins android.permission.MANAGE_USERS . Par exemple:

<permissions>
  <privapp-permissions package="com.android.car.debuggingrestrictioncontroller">
    <permission name="android.permission.INTERNET"/>
    <permission name="android.permission.MANAGE_USERS"/>
  </privapp-permissions>
</permissions>

Version dégroupée

Les versions DRC dégroupées utilisent Gradle pour compiler l'application.

Pour créer une version non groupée :

  1. Confirmez que vous avez installé le SDK Android.
  2. Créez un fichier texte nommé local.properties dans le répertoire racine de l'application.
  3. Définissez l'emplacement du SDK Android :
     sdk.dir=path/to/android/sdk
    
  4. Pour configurer Firebase, copiez google-services.json dans packages/apps/Car/DebuggingRestrictionController/app . Gradle analyse le fichier et configure automatiquement le reste.
  5. Définissez les variables d'environnement. Comme pour les versions groupées, vous devez spécifier :
    • $TOKEN_USES_SELF_SIGNED_CA : vrai ou faux ;
    • $ROOT_CA_CERT : chemin d'accès au certificat de l'autorité de certification racine encodé en PEM ;
    • $TOKEN_ISSUER_API_NAME : nom de la fonction Firebase Cloud ;
    • $TOKEN_ISSUER_HOST_NAME : SAN dans le certificat ;
    • $DRC_TEST_EMAIL et $DRC_TEST_EMAI L : informations d'identification pour un compte de test, versions de débogage uniquement.
  6. Pour créer l'application avec Gradle, exécutez une commande comme celle-ci :
    $ ./gradlew build
    

Intégration de l'émetteur de jetons

Le Token Issuer de référence est une Firebase Cloud Function implémentée dans Node.js. La fonction ne peut être appelée que par un utilisateur authentifié. Avant de déployer l'application, vous devez configurer la clé privée et les certificats utilisés pour signer les jetons JWS.

  1. Remplissez un fichier JSON avec le contenu suivant :
    {
        "key": "---BEGIN PRIVATE KEY---\nRSA_PRIVATE_KEY\n-----END PRIVATE KEY-----\n",
        "certificates.0": "-----BEGIN CERTIFICATE-----\nTOKEN_SIGNING_CERT\n-----END CERTIFICATE-----\n",
        "certificates.1": "-----BEGIN CERTIFICATE-----\nINTERMEDIATE_CA_CERT\n-----END CERTIFICATE-----\n",
        "certificates.2": "-----BEGIN CERTIFICATE-----\nROOT_CA_CERT\n-----END CERTIFICATE-----\n",
        "expiration": "30m",
        "issuer": "Debugging Access Token Issuer",
        "audience": "IHU"
    }
    

    Les certificats sont commandés avec le certificat d'entité finale en premier et le certificat d'autorité de certification racine à la fin. La période d'expiration est personnalisable et peut être définie sur une durée plus longue si un jeton émis prend un certain temps avant de pouvoir être reçu et consommé par une application DRC. La révocation de jeton n'est pas prise en charge.

  2. Importez la configuration dans Firebase :
  3. $ firebase functions:config:set api_config="$(cat YOUR_CONFIG.json)"
    
  4. Déployez la fonction Firebase Cloud :
  5. $ firebase deploy --only functions
    
  6. Pour gérer et surveiller votre émetteur de jetons, consultez Gérer les options de déploiement et d'exécution des fonctions .

Définition des restrictions par défaut

Les restrictions par défaut peuvent être appliquées avant le premier démarrage. Faites cela avec des superpositions de ressources statiques pour remplacer les valeurs par défaut dans le framework Android. Des restrictions peuvent être respectivement appliquées sur différents types d'utilisateurs. Pour en savoir plus sur les différents types d'utilisateurs, voir Support multi-utilisateur .

La restriction par défaut pour l' utilisateur du système sans tête peut être configurée avec le tableau de chaînes config_defaultFirstUserRestrictions dans frameworks/base/core/res/res/values/config.xml . La définition de cette restriction désactive automatiquement Android Debug Bridge (ADB) jusqu'à ce que la restriction soit supprimée, par exemple :

<string-array translatable="false" name="config_defaultFirstUserRestrictions">
  <item>no_debugging_features</item>
</string-array>

Les restrictions par défaut pour les utilisateurs réguliers (par exemple, les conducteurs et les passagers) et les invités peuvent être configurées dans frameworks/base/core/res/res/xml/config_user_types.xml . Vous pouvez superposer ces chaînes pour définir respectivement 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>