Android 14 presenta cambios en el manejo de los certificados de autoridad

Hace pocos días los desarrolladores de HTTP Toolkit compartieron mediante una publicación de blog, información sobre un detalle que notaron en la forma en que se actualizan los certificados de autoridad certificadora (CA) en Android 14.

Y es que los desarrolladores de HTTP Toolkit les llamo la atención que en Android 14, los certificados del sistema ya no estarán vinculados al firmware, pero sí se entregará en un paquete por separado el cual es actualizado a través de la tienda de aplicaciones del sistema «Google Play».

Cuando Android fue anunciado inicialmente en 2007 por la Open Handset Alliance (encabezada por Google), su proyecto estrella fue anunciado como una «plataforma abierta», «que proporcionaba a los desarrolladores un nuevo nivel de apertura» y les daba «acceso completo a las capacidades y herramientas de los teléfonos». «.

Hemos recorrido un largo camino desde entonces, alejándonos constantemente de la apertura y el control de los dispositivos por parte del usuario, y avanzando hacia un mundo mucho más cerrado y controlado por los proveedores.

En su publicación los desarrolladores comparten parte de sus preocupaciones en la evolución y sobre todo el camino que ha tomado el desarrollo de Android, el cual cada vez más se va alejando de lo prometido «ser una plataforma abierta», ya que con el paso del lanzamiento de las diferentes versiones, el sistema se ha «cerrado cada vez más».

Mencionan que en el apartado de certificados de autoridad «se vuelven significativamente más estrictas y parecen hacer imposible modificar el conjunto de certificados confiables» incluso en dispositivos totalmente rooteados.

Sobre el cambio en el manejo de los certificados en Android 14, se «supone» que este enfoque facilitará el mantenimiento de certificados actualizados y la eliminación de certificados de autoridades de certificación comprometidas, y también evitará que los fabricantes de dispositivos manipulen la lista de certificados root y hará que el proceso de actualización sea independiente de las actualizaciones de firmware.

En lugar del directorio /system/etc/security/cacerts, los certificados en Android 14 se cargan desde el directorio /apex/com.android.conscrypt/cacerts, alojado en un contenedor APEX (Android Pony EXpress) separado, cuyo contenido es se entrega a través de Google Play y la integridad está controlada digitalmente y firmada por Google. Por lo tanto, incluso con el control total del sistema con derechos de root, el usuario, sin realizar cambios en la plataforma, no podrá cambiar el contenido de la lista de certificados del sistema.

El punto de inflexión clave en este proceso fue Android 7 (Nougat, lanzado en 2016), en el que las autoridades de certificación (CA) del dispositivo que anteriormente eran totalmente modificables por el propietario del teléfono se dividieron en dos: se proporcionó una lista fija de CA por el proveedor del sistema operativo y utilizado de forma predeterminada por todas las aplicaciones de su teléfono, y otro conjunto de CA modificables por el usuario que los usuarios podían controlar, pero que se usaba solo para aplicaciones que específicamente optaban por participar (es decir, casi ninguna).

El nuevo esquema de almacenamiento de certificados podría causar dificultades a los desarrolladores involucrados en ingeniería inversa, inspección de tráfico o investigación de firmware, y podría complicar potencialmente el desarrollo de proyectos que desarrollen firmware alternativo basado en Android, como GrapheneOS y LineageOS.

Dado que no todo es tan bueno como suena y como ya mencionamos, los HTTP Toolkit expresan su desacuerdo con el nuevo método de entrega, ya que no permitirá al usuario realizar cambios en los certificados del sistema, incluso si tiene acceso root al sistema y tiene control total del firmware.

El cambio solo afecta a los certificados de CA del sistema, que se utilizan de forma predeterminada en todas las aplicaciones del dispositivo, y no afecta el procesamiento de certificados de usuario ni la capacidad de agregar certificados adicionales para aplicaciones individuales (por ejemplo, la capacidad de agregar certificados adicionales para el navegador permanece).

Al mismo tiempo, el problema no se limita solo al paquete con certificados: a medida que la funcionalidad del sistema se traslada a paquetes APEX actualizados por separado, aumentará la cantidad de componentes del sistema que el usuario no puede controlar ni cambiar, independientemente de la presencia de acceso root al dispositivo.

Finalmente si estás interesado en poder conocer más al respecto, puedes consultar los detalles en el siguiente enlace.