Opções seguras para desenvolvedores

De acordo com o Documento de definição de compatibilidade do Android, os OEMs precisam oferecer uma maneira de ativar o desenvolvimento de apps. No entanto, oferecer opções de desenvolvedor semelhantes a dispositivos móveis em carros os deixa vulneráveis a ataques. O acesso às opções de desenvolvedor agora pode ser controlado por um OEM usando um mecanismo de token criptográfico autenticado. Especificamente, um OEM pode:

  • Especificar restrições padrão antes da primeira inicialização.
  • Autorizar desenvolvedores com segurança, com tokens criptográficos, se preferir.
  • Aplicar mudanças de restrição depois que um desenvolvedor for autenticado e autorizado.

Esta página descreve uma implementação de referência que consiste em um app controlador de restrição de depuração e um endpoint de emissor de token remoto.

Terminologia

Além da terminologia, estes termos são usados nesta página:

  • Assinatura JSON da Web (JWS, na sigla em inglês), definida na RFC 7515
  • Instituto Nacional de Padrões e Tecnologia (NIST)

Design

Os OEMs podem autorizar desenvolvedores com tokens de assinatura JSON da Web (JWS) (RFC7515). Na implementação de referência, os tokens de acesso são emitidos por OEMs e consumidos pelo app controlador de restrição. Os tokens de acesso são projetados para resistir a ataques de repetição e tokens falsificados.

Figura 1. Design

Integração e configuração

Os OEMs precisam especificar restrições padrão na primeira inicialização. Os OEMs fazem isso com várias sobreposições de recursos estáticos para substituir os padrões no framework do AOSP.

As restrições padrão para o usuário do sistema sem periféricos podem ser configuradas com a string config_defaultFirstUserRestrictions em frameworks/base/core/res/res/values/config.xml, por exemplo:

<!-- User restrictions set when the first user is created.
         Note: Also update appropriate overlay files. -->
    <string-array translatable="false" name="config_defaultFirstUserRestrictions">
        <item>no_debugging_features</item>
        <item>no_install_unknown_sources</item>
        <item>no_install_unknown_sources_globally</item>
    </string-array>

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

<user-types>
    <full-type name="android.os.usertype.full.SECONDARY" >
        <default-restrictions
            no_debugging_features="true"
            no_install_unknown_sources="true"/>
    </full-type>
    <full-type name="android.os.usertype.full.GUEST" >
        <default-restrictions
            no_debugging_features="true"
            no_install_unknown_sources="true"/>
    </full-type>
</user-types>

Controlador de preferência de número da versão

No AAOS, a interação do usuário com a linha de preferência Número do build em "Configurações" é processada por BuildNumberPreferenceController.java, localizado em packages/apps/Car/Settings/src/com/android/car/settings/system/BuildNumberPreferenceController.java.

Quando a restrição de usuário no_debugging_features (UserManager.DISALLOW_DEBUGGING_FEATURES) é definida, BuildNumberPreferenceController suprime a contagem regressiva do desenvolvedor em builds de produção (user) quando tocada:

@Override
protected boolean handlePreferenceClicked(Preference preference) {
    if (DevelopmentSettingsUtil.isDevelopmentSettingsEnabled(getContext())) {
        return true;
    }

    // Enforce restriction on production (user) builds
    if (Build.IS_USER && mUserManager.hasUserRestriction(UserManager.DISALLOW_DEBUGGING_FEATURES)) {
        showToast(R.string.dev_access_blocked_toast);
        return true;
    }

    mDevHitCountdown--;
    if (mDevHitCountdown == 0) {
        DevelopmentSettingsUtil.setDevelopmentSettingsEnabled(getContext(), true);
        showToast(R.string.show_dev_on);
    }
    return true;
}

O uso de Build.IS_USER garante que os builds de produção apliquem estritamente o bloqueio de segurança, enquanto as equipes de engenharia internas em builds userdebug ainda podem acessar as opções de desenvolvedor usando o gesto de sete toques para testes sem substituições manuais da interface de linha de comando (CLI).

Controlador de restrição de depuração

Uma implementação de referência do Controlador de restrição de depuração (DRC, na sigla em inglês) é fornecida no AOSP em packages/apps/Car/DebuggingRestrictionController.

O DRC permite que os OEMs suspendam de forma dinâmica e temporária a restrição no_debugging_features em veículos de produção para técnicos de serviço e desenvolvedores autorizados. Em vez de deixar as ferramentas de depuração permanentemente abertas ou exigir novas atualizações de firmware, o app DRC no veículo solicita que o usuário faça a autenticação com o back-end do OEM e envie um token de acesso assinado criptograficamente para ativar o adb e as opções de desenvolvedor para uma sessão de diagnóstico finita.

A implementação de referência do DRC consiste em dois componentes principais:

  • App cliente do DRC no veículo (app/) : um app de sistema privilegiado (com a permissão MANAGE_USERS) na unidade principal que autentica desenvolvedores, valida a assinatura do certificado X.509, o nome do host, o nonce e a expiração dos tokens JWS recebidos e alterna dinamicamente a restrição no_debugging_features usando UserManager.
  • Emissor de token na nuvem (server/) : um serviço da Web de back-end (implementável como o Firebase Cloud Functions) que autentica as credenciais do desenvolvedor e emite tokens de acesso JWS RS256 assinados criptograficamente com uma janela de expiração finita.

Para instruções completas de configuração, ferramentas de geração de certificados e etapas de implantação, consulte o guia de integração do Controlador de restrição de depuração.

Teste

O Google recomenda que os OEMs comecem com a implementação de referência e criem a partir dela.

  1. Depois de configurar as restrições nos arquivos de sobreposição, compile o AAOS e valide os fluxos definidos. Use o app de referência e o serviço local ativado para JWS para verificar as configurações de acesso.
  2. Opcional: configure o sistema para usar o serviço de nuvem ativado para JWS. Verifique se você está observando o fluxo esperado no serviço de back-end.