Guia de integração do controlador de restrição de depuração

Use as seguintes instruções para integrar o AAOS Debugging Restriction Controller (DRC).

Figura 1. Exemplo de aplicativo DRC

Arquitetura

A arquitetura DRC é ilustrada abaixo. Os componentes destacados em vermelho (Emissor de Token e Controlador de Restrição Estreante) têm implementações de referência que você pode personalizar.

Figura 2. Arquitetura DRC

O que é a RDC?

A unidade principal do carro inclui o aplicativo DRC (consulte a implementação de referência em packages/apps/Car/DebuggingRestrictionController ). O aplicativo de referência inclui a lógica para receber um token de acesso do emissor do token, validar o token e aplicar as alterações de restrição de depuração conforme especificado no token. A lógica inclui elementos básicos de UX no lado do carro.

O que é o emissor do token?

Este é um serviço da web que emite tokens de acesso assinados criptograficamente (consulte a implementação de referência em packages/apps/Car/DebuggingRestrictionController/server ). O serviço da Web de referência é uma função implantável do Firebase Cloud (para saber mais, consulte Cloud Functions for Firebase ).

Pré-requisitos

Antes de implantar uma implementação de referência, certifique-se de concluir as tarefas a seguir.

Preparando certificados para assinar tokens de acesso

O Token Issuer gera JSON Web Signatures (JWS) como tokens de acesso. Para compatibilidade ideal, o emissor de referência suporta apenas o algoritmo RS256 (assinaturas RSA com SHA256). Para facilitar a rotação de chaves, use uma cadeia de certificados em vez de um único certificado para assinar tokens de acesso. Uma cadeia de certificados típica deve consistir em um certificado de CA raiz, um certificado de CA intermediário e um certificado de entidade final.

O certificado de entidade final que assina os tokens JWS não é diferente de um certificado TLS padrão. Você pode comprar um certificado de CAs públicas, como a DigiCert, ou manter sua própria cadeia de certificados usando certificados CA raiz autoassinados ou módulos de segurança de hardware. O certificado de entidade final deve ser um certificado X509v3 com uma extensão de nome alternativo da entidade (SAN). A extensão SAN contém um identificador (por exemplo, nome do host) do emissor do token. Por fim, os certificados RSA devem ser preferidos aos certificados EC, pois o emissor do token suporta apenas RS256.

O Google fornece um script de shell para gerar certificados autoassinados em packages/apps/Car/DebuggingRestrictionController/server/genkey.sh .

Configurando o Firebase

O emissor do token de referência usa o Firebase Authentication e o Firebase Cloud Function .

Para configurar sua conta do Firebase:

  1. Para criar um projeto do Firebase, consulte Adicionar o Firebase ao seu projeto Android .
  2. Para habilitar alguns autenticadores do Firebase, consulte Por onde começo com o Firebase Authentication? .
  3. Para adicionar uma função vazia do Firebase Cloud, consulte Primeiros passos .
  4. Se ainda não tiver feito, instale o Node.js, NPM e Firebase Tools para compilar e implantar o Token Issuer.

Integrando o aplicativo DRC

O aplicativo DRC de referência está localizado em packages/apps/Car/DebuggingRestrictionController . O aplicativo pode ser compilado no AOSP com o Soong ou desagregado com o Gradle .

Compilação em pacote

Para criar um aplicativo em pacote:

  1. Copie applicationId , projectId e apiKey de google-services.json em packages/apps/Car/DebuggingRestrictionController/soong/FirebaseApplication.java . Isso permite que o aplicativo DRC se conecte corretamente ao Firebase.
  2. Atualize essas constantes em packages/apps/Car/DebuggingRestrictionController/soong/BuildConfig.java :
    • TOKEN_USES_SELF_SIGNED_CA indica se os certificados de CA raiz autoassinados são usados. Se ativado, o aplicativo DRC confia apenas no certificado de CA raiz codificado por PEM especificado em ROOT_CA_CERT .
    • TOKEN_ISSUER_API_NAME é o nome da função do Firebase Cloud e deve corresponder à função do Cloud que você criou anteriormente no Firebase Console.
    • TOKEN_ISSUER_HOSTNAME deve corresponder ao nome alternativo da entidade no certificado de entidade final que assinará os tokens de acesso.
    • DRC_TEST_EMAIL e DRC_TEST_PASSWORD são credenciais para uma conta de teste opcional, que pode ser pré-provisionada no Firebase se você tiver ativado o login por e-mail/senha. Estes são usados ​​apenas para testes instrumentados.

O aplicativo agora está configurado para usar sua conta do Firebase e seus certificados. No Android 9 e superior, você deve configurar a Privileged Permission Allowlisting . A lista de permissões deve conter pelo menos android.permission.MANAGE_USERS . Por exemplo:

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

Compilação desagregada

As compilações de DRC desagregadas usam o Gradle para compilar o aplicativo.

Para criar uma compilação desagregada:

  1. Confirme se você instalou o Android SDK.
  2. Crie um arquivo de texto chamado local.properties no diretório raiz do aplicativo.
  3. Defina a localização do Android SDK:
     sdk.dir=path/to/android/sdk
    
  4. Para configurar o Firebase, copie google-services.json para packages/apps/Car/DebuggingRestrictionController/app . Gradle analisa o arquivo e configura automaticamente o restante.
  5. Defina as variáveis ​​de ambiente. Assim como nas compilações em pacote, você deve especificar:
    • $TOKEN_USES_SELF_SIGNED_CA : verdadeiro ou falso;
    • $ROOT_CA_CERT : caminho para o certificado de CA raiz codificado por PEM;
    • $TOKEN_ISSUER_API_NAME : nome da função do Firebase Cloud;
    • $TOKEN_ISSUER_HOST_NAME : SAN no certificado;
    • $DRC_TEST_EMAIL e $DRC_TEST_EMAI L: credenciais para uma conta de teste, apenas compilações de depuração.
  6. Para construir o aplicativo com Gradle, execute um comando como este:
    $ ./gradlew build
    

Integrando o Emissor de Token

O emissor do token de referência é um Firebase Cloud Function implementado em Node.js. A função só pode ser chamada por um usuário autenticado. Antes de implantar o aplicativo, você deve configurar a chave privada e os certificados usados ​​para assinar os tokens JWS.

  1. Preencha um arquivo JSON com o seguinte conteúdo:
    {
        "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"
    }
    

    Os certificados são solicitados com o certificado da entidade final primeiro e o certificado da CA raiz no final. O período de expiração é personalizável e pode ser definido para uma duração maior se um token emitido demorar algum tempo antes de ser recebido e consumido por um aplicativo DRC. A revogação de token não é suportada.

  2. Faça upload da configuração para o Firebase:
  3. $ firebase functions:config:set api_config="$(cat YOUR_CONFIG.json)"
    
  4. Implante a função do Firebase Cloud:
  5. $ firebase deploy --only functions
    
  6. Para gerenciar e monitorar seu emissor de token, consulte Gerenciar implantação de funções e opções de tempo de execução .

Definir restrições padrão

As restrições padrão podem ser aplicadas antes da primeira inicialização. Faça isso com sobreposições de recursos estáticos para substituir os padrões na estrutura do Android. As restrições podem ser aplicadas respectivamente a diferentes tipos de usuários. Para saber mais sobre os diferentes tipos de usuários, consulte Suporte multiusuário .

A restrição padrão para o usuário do sistema headless pode ser configurada com o string-array config_defaultFirstUserRestrictions em frameworks/base/core/res/res/values/config.xml . Definir essa restrição desabilita automaticamente o Android Debug Bridge (ADB) até que a restrição seja removida, por exemplo:

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

As restrições padrão para usuários regulares (por exemplo, motoristas e passageiros) e convidados podem ser configuradas em frameworks/base/core/res/res/xml/config_user_types.xml . Você pode sobrepor essas strings para definir as restrições padrão em cada tipo de usuário, respectivamente, por exemplo:

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