Cómo proteger las opciones para desarrolladores

Según el Documento de definición de compatibilidad de Android, los OEMs deben proporcionar una forma de habilitar el desarrollo de apps. Sin embargo, proporcionar opciones para desarrolladores similares a las de los dispositivos móviles en los automóviles los deja vulnerables a ataques. Ahora, un OEM puede restringir el acceso a las opciones para desarrolladores con un mecanismo de token criptográfico autenticado. Específicamente, un OEM puede hacer lo siguiente:

  • Establece las restricciones predeterminadas deseadas antes del primer inicio.
  • Otorga autorizaciones a los desarrolladores de forma segura, con tokens criptográficos si lo prefieres.
  • Aplica los cambios de restricción una vez que un desarrollador esté autenticado y autorizado.

En este artículo, se describe una implementación de referencia que consta de una app de controlador de restricciones de depuración y un extremo de emisor de tokens remoto.

Terminología

Además de la terminología, en este artículo se usan los siguientes términos:

  • Firma web JSON (JWS), definida en RFC 7515
  • Instituto Nacional de Estándares y Tecnología (NIST)

Diseño

Los OEMs pueden autorizar a los desarrolladores con tokens de firma web JSON (JWS) (RFC7515). En la implementación de referencia, los OEMs emiten los tokens de acceso y la app del controlador de restricciones los consume. Los tokens de acceso están diseñados para resistir ataques de repetición y tokens falsificados.

Figura 1: Diseño

Integración y configuración

Los OEMs deben especificar las restricciones predeterminadas deseadas en el primer inicio. Esto se hace con varias superposiciones de recursos estáticos para anular los valores predeterminados en el framework de AOSP.

Las restricciones predeterminadas para el usuario del sistema sin cabeza se pueden configurar con la cadena config_defaultFirstUserRestrictions en frameworks/base/core/res/res/values/config.xml, por ejemplo:

<!-- 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>
    </string-array>

Las restricciones predeterminadas para conductores, pasajeros y huéspedes se pueden configurar en frameworks/base/core/res/res/xml/config_user_types.xml. Un OEM puede superponer| estas cadenas para establecer las restricciones predeterminadas en cada tipo de usuario, respectivamente, por ejemplo:

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

Se proporciona una implementación de referencia en la siguiente ubicación del AOSP:

packages/apps/Car/DebuggingRestrictionController

Prueba

Google recomienda que los OEM comiencen con la implementación de referencia y desarrollen a partir de allí.

  1. Después de configurar las restricciones deseadas en los archivos de superposición, compila AAOS y valida los flujos definidos. Usa la app de referencia y el servicio local habilitado para JWS para verificar la configuración de acceso.
  2. Configura el sistema para que use tu servicio en la nube habilitado para JWS (opcional). Verifica que observes el flujo deseado en tu servicio de backend.