Cette page a été traduite par l'API Cloud Translation.

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

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

Figure 1 : Exemple d'application DRC.

Architecture

L'architecture de DRC est illustrée à la figure 2. Composants encadrés en rouge (émetteur et DRC) sont accompagnées 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 de réception d'un jeton d'accès de l'émetteur de jeton, de validation du jeton et puis en appliquant les modifications de restriction de débogage comme spécifié dans le jeton. La logique comprend : les éléments UX de base côté voiture.

Quel est l'émetteur du jeton ?

Il s'agit d'un service Web qui émet des jetons d'accès avec signature cryptographique (voir la documentation l'implémentation 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 pour (Firebase).

Prérequis

Avant de déployer une implémentation de référence, assurez-vous d'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) en tant que jetons d'accès. Pour une l'émetteur de référence n'accepte 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 à signer des jetons d'accès. Une chaîne de certificats type doit être constituée d'un certificat CA racine, d'une un certificat CA intermédiaire et un certificat d'entité finale.

Le certificat d'entité finale qui signe les jetons JWS n'est pas différent d'un certificat TLS standard certificat. 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 CA racine autosignés ou de modules de sécurité matériels. Le certificat d'entité finale doit être un certificat X509v3 avec un autre nom d'objet (SAN). L'extension SAN contient l'identifiant (par exemple, le nom d'hôte) du jeton de l'émetteur. Enfin, les certificats RSA doivent être privilégiés par rapport aux certificats EC, car le jeton l'émetteur n'accepte que RS256.

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

Configurer Firebase

L'émetteur du jeton de référence utilise Firebase Authentication et Fonction Cloud Firebase.

Pour configurer votre compte Firebase:

Pour créer un projet Firebase, consultez Ajouter Firebase à votre projet Android.
Pour activer certains authentificateurs Firebase, consultez Où puis-je commencer par Firebase Authentication.
Pour ajouter une fonction Firebase Cloud vide, consultez la page Obtenir Début.
Si ce n'est pas déjà fait, installez les outils Node.js, NPM et Firebase pour compiler et pour déployer l'émetteur de jetons. <ph type="x-smartling-placeholder">
</ph> Remarque:Une fois que vous avez créé un projet Firebase, pour télécharger un fichier de configuration nommé google-services.json. Ce fichier ne contient pas informations sensibles et est consommée à la fois par l'application DRC de référence et par l'émetteur de jetons plus tard.

Intégrer l'application DRC

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

Compilation groupée

Pour créer une application groupée:

Copiez les éléments applicationId, projectId et apiKey. de google-services.json à packages/apps/Car/DebuggingRestrictionController/soong/FirebaseApplication.java Cela permet à l'application DRC de se connecter correctement à Firebase.
Mettez à jour ces constantes dans packages/apps/Car/DebuggingRestrictionController/soong/BuildConfig.java: <ph type="x-smartling-placeholder">
- TOKEN_USES_SELF_SIGNED_CA indique si les certificats CA racine autosignés sont utilisé. Si cette option est activée, l'application DRC n'approuve que le certificat CA racine encodé au format 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 de l'objet dans le certificat d'entité finale qui signera les jetons d'accès.
- DRC_TEST_EMAIL et DRC_TEST_PASSWORD sont des identifiants pour de test facultatif, qui peut être pré-provisionné dans Firebase si vous avez activé Connexion par adresse e-mail/mot de passe. Ils ne sont utilisés que pour les tests d'instrumentation.

L'application est maintenant configurée pour utiliser votre compte Firebase et vos certificats. Sur Android 9 ou version ultérieure, vous devez configurer ajout d'autorisations privilégiées à la liste d'autorisation. La liste d'autorisation doit contenir au moins android.permission.MANAGE_USERS. Exemple :

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

Compilation sans catégorie

Les builds DRC non groupés utilisent Gradle pour compiler l'application.

Pour créer une compilation sans bundle:

Vérifiez que vous avez installé le SDK Android.
Créez un fichier texte nommé local.properties dans le répertoire racine de l'application.
Définissez l'emplacement du SDK Android:
```
 sdk.dir=path/to/android/sdk
```
Pour configurer Firebase, copiez google-services.json dans packages/apps/Car/DebuggingRestrictionController/app Gradle analyse le fichier et configure automatiquement le reste.
Définissez les variables d'environnement. Comme pour les builds groupés, vous devez spécifier les éléments suivants: <ph type="x-smartling-placeholder">
- $TOKEN_USES_SELF_SIGNED_CA: true ou false;
- $ROOT_CA_CERT: chemin d'accès au certificat CA racine encodé au format PEM.
- $TOKEN_ISSUER_API_NAME: nom de la fonction Firebase Cloud.
- $TOKEN_ISSUER_HOST_NAME: SAN du certificat
- $DRC_TEST_EMAIL et $DRC_TEST_EMAIL: identifiants pour un test les versions de débogage uniquement.
Pour compiler l'application avec Gradle, exécutez une commande comme celle-ci:
```
$ ./gradlew build
```
<ph type="x-smartling-placeholder">
</ph> Remarque:Une application pour la DRC sans catégorie doit être signée avec la plate-forme. certificat, car il nécessite une autorisation privilégiée, MANAGE_USERS. l'ajout d'autorisations privilégiées à la liste d'autorisation pour la même raison.

Intégrer l'émetteur de jetons

L'émetteur de jeton de référence est une fonction Cloud Firebase 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 définir la clé privée et les certificats utilisés pour signer les jetons JWS.

Dans un fichier JSON, insérez 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 CA racine à la fin. Vous pouvez personnaliser le délai d'expiration et le définir sur une durée plus longue si une il faut un certain temps pour qu'une application RDC puisse le recevoir et l'utiliser. Jeton la révocation n'est pas prise en charge.

Importez la configuration dans Firebase:

$ firebase functions:config:set api_config="$(cat YOUR_CONFIG.json)"

Déployez la fonction Firebase Cloud:

$ firebase deploy --only functions

Pour gérer et surveiller l'émetteur de votre jeton, consultez Gérer de déploiement et d'exécution de Cloud Functions.

Définir des restrictions par défaut

Les restrictions par défaut peuvent être appliquées avant le premier démarrage. Utilisez pour cela une ressource statique des superpositions pour remplacer les valeurs par défaut dans le framework Android. Les restrictions peuvent être respectivement appliquées à différents types d'utilisateurs. Pour en savoir plus sur les différents types d'utilisateurs, consultez Compatibilité multi-utilisateur :

La restriction par défaut pour l'utilisateur du système headless peut être configurée à l'aide de la commande suivante : le tableau de chaînes config_defaultFirstUserRestrictions frameworks/base/core/res/res/values/config.xml Définir 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 standards (chauffeurs et passagers, par exemple) ; et les invités peuvent être configurés dans frameworks/base/core/res/res/xml/config_user_types.xml Vous pouvez superposer ces 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"/>
  </full-type>
  <full-type name="android.os.usertype.full.GUEST" >
    <default-restrictions no_debugging_features="true"/>
  </full-type>
</user-types>