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

Use as instruções a seguir 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 inicial) têm implementações de referência que podem ser personalizadas.

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, em seguida, 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 de tokens?

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 web de referência é uma função implantável do Firebase Cloud (para saber mais, consulte Funções do Cloud para 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 emissor de token 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 DigiCert, ou manter sua própria cadeia de certificados usando certificados de 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 Subject Alternative Name (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 porque 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 Token Issuer de referência usa Firebase Authentication e Firebase Cloud Function .

Para configurar sua conta do Firebase:

  1. Para criar um projeto Firebase, consulte Adicionar 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 Introdução .
  4. Se ainda não tiver feito isso, instale 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 construído junto com o AOSP com o Soong ou separado com o Gradle .

compilação empacotada

Para criar um aplicativo integrado:

  1. Copie applicationId , projectId e apiKey de google-services.json para 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 certificados de CA raiz autoassinados são usados. Se ativado, o aplicativo DRC confia apenas no certificado CA raiz codificado por PEM especificado em ROOT_CA_CERT .
    • TOKEN_ISSUER_API_NAME é o nome da função Firebase Cloud e deve corresponder à função Cloud que você criou anteriormente no Firebase Console.
    • TOKEN_ISSUER_HOSTNAME deve corresponder ao nome alternativo do assunto no certificado da 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 lista de permissões de permissão privilegiada . 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

Compilações DRC desagregadas usam 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 resto.
  5. Defina as variáveis ​​de ambiente. Tal como acontece com as compilações agrupadas, você deve especificar:
    • $TOKEN_USES_SELF_SIGNED_CA : verdadeiro ou falso;
    • $ROOT_CA_CERT : caminho para o certificado CA raiz codificado por PEM;
    • $TOKEN_ISSUER_API_NAME : nome da função 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 criar o aplicativo com Gradle, execute um comando como este:
    $ ./gradlew build
    

Integrando o emissor de token

O Token Issuer de referência é uma Firebase Cloud Function implementada 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 de entidade final primeiro e o certificado CA raiz no final. O período de expiração é personalizável e pode ser definido para uma duração mais longa 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. Carregue a configuração no Firebase:
  3. $ firebase functions:config:set api_config="$(cat YOUR_CONFIG.json)"
    
  4. Implante a função Firebase Cloud:
  5. $ firebase deploy --only functions
    
  6. Para gerenciar e monitorar seu emissor de token, consulte Gerenciar funções de implementação e opções de tempo de execução .

Definindo 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 em 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 desativa 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>