Según el Documento de definición de compatibilidad de Android , los OEM deben proporcionar una forma de permitir el desarrollo de aplicaciones. Sin embargo, ofrecer opciones de desarrollo similares a las de 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 mediante 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 cambios de restricciones una vez que un desarrollador esté autenticado y autorizado.
Este artículo describe una implementación de referencia que consta de una aplicación de controlador de restricción de depuración y un punto final de emisor de token remoto.
Terminología
Además de la terminología , en este artículo se utilizan estos términos:
- 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 OEM emiten tokens de acceso y la aplicación del controlador de restricción 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 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 para 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 de AOSP:
packages/apps/Car/DebuggingRestrictionController
Pruebas
Google recomienda que los OEM comiencen con la implementación de referencia y desarrollen a partir de ahí.
- Después de configurar las restricciones deseadas en los archivos superpuestos, compile AAOS y valide los flujos definidos. Utilice la aplicación de referencia y el servicio local habilitado para JWS para verificar su configuración de acceso.
- Configure el sistema para utilizar su servicio en la nube habilitado para JWS (opcional). Verifique que esté observando el flujo deseado en su servicio backend.