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

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

Figure 1. Exemple d'application RDC.

Architecture

L'architecture DRC est illustrée dans la figure 2. Les composants soulignés en rouge (émetteur de jetons et DRC) 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 comprend 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 permettant de recevoir un jeton d'accès de l'émetteur du jeton, de valider le jeton, puis d'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.

Quel est l’émetteur du token ?

Il s'agit d'un service Web qui émet des jetons d'accès signés cryptographiquement (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 Cloud Functions for Firebase ).

Conditions préalables

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

Préparer les certificats pour signer les jetons d'accès

L'émetteur de jetons génère des signatures Web JSON (JWS) comme 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 composé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érielle. 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 du token ne prend en charge que 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

L'émetteur du jeton de référence 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 Get Started .
  4. Si ce n'est pas déjà fait, installez les outils Node.js , NPM et Firebase pour compiler et déployer l'émetteur de jetons.

Intégrez l'application RDC

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

Construction 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 cette option est activée, l'application DRC fait confiance uniquement au certificat d'autorité de certification racine codé en 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 au nom alternatif 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 peuvent être pré-provisionnées 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. Sous Android 9 et versions ultérieures, vous devez configurer la liste blanche des autorisations privilégiées . La liste verte 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 dé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éfinir 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 builds groupés, vous devez spécifier :
    • $TOKEN_USES_SELF_SIGNED_CA : vrai ou faux ;
    • $ROOT_CA_CERT : chemin d'accès au certificat CA racine encodé 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égrer l'émetteur du token

L'émetteur du jeton de référence est une fonction Firebase Cloud 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 classé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. Téléchargez la configuration sur 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éfinir des restrictions par défaut

Des 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, consultez Prise en charge multi-utilisateurs .

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>