Google se compromete a impulsar la igualdad racial para las comunidades afrodescendientes. Obtén información al respecto.

Protección de las opciones de desarrollador

Según el Documento de definición de compatibilidad de Android , los OEM deben proporcionar una forma de habilitar el desarrollo de aplicaciones. Sin embargo, proporcionar opciones de desarrollo similares a las de los dispositivos móviles dentro de los automóviles deja a esos automóviles vulnerables a los ataques. El acceso a las opciones de desarrollador ahora puede ser controlado por un OEM utilizando un mecanismo de token criptográfico autenticado. Específicamente, un OEM puede:

  • Establezca las restricciones predeterminadas deseadas antes del primer arranque.
  • Autorice de forma segura a los desarrolladores, con tokens criptográficos si lo prefiere.
  • Aplique 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 consiste en una aplicación de controlador de restricción de depuración y un extremo de emisor de token remoto.

Terminología

Además de Terminología , estos términos se utilizan en este artículo:

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

Diseño

Los OEM pueden autorizar a los desarrolladores con tokens JSON Web Signature (JWS) (RFC7515). En la implementación de referencia, los tokens de acceso los emiten los OEM y los consume la aplicación del controlador de restricciones. 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 OEM deben especificar las restricciones predeterminadas deseadas en el primer arranque. Esto se hace con varias superposiciones de recursos estáticos para anular los valores predeterminados en el marco 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 e invitados 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 en AOSP:

packages/apps/Car/DebuggingRestrictionController

Pruebas

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

  1. Después de configurar las restricciones deseadas en los archivos de superposición, compile AAOS y valide los flujos definidos. Utilice la aplicación de referencia y el servicio habilitado para JWS local para verificar su configuración de acceso.
  2. Configure el sistema para usar su servicio en la nube habilitado para JWS (opcional). Verifique que esté observando el flujo deseado en su servicio de back-end.