En Android 14 ya no se permite modificar los certificados del sistema, ni siquiera siendo root

Hace unos días el Los desarrolladores del kit de herramientas HTTP compartieron a través de una publicación de blog, información sobre un detalle que notó en la forma en que se actualizan los certificados de la autoridad certificadora (CA) en Android 14.

Y los desarrolladores de HTTP Toolkit llamaron su atención sobre el hecho de que en Android 14, los certificados del sistema Ya no estarán vinculados al firmware.pero se entregará en un paquete separado que se actualiza a través de la tienda de aplicaciones del sistema «Google Play».

Cuando Android fue anunciado inicialmente en 2007 por la Open Handset Alliance (dirigida 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 total a capacidades y herramientas». de 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 algunas de sus preocupaciones en la evolución y sobre todo el camino que ha tomado el desarrollo de Android, que cada vez se aleja más de lo que se prometía «ser una plataforma abierta», ya que con el paso del lanzamiento de las diferentes versiones, el sistema se ha «cerrado más». y más.»

ellos mencionan que en la sección de certificados de autoridad «volverse significativamente más estricto y parecen hacer imposible modificar el conjunto de certificados confiables» incluso en dispositivos totalmente rooteados.

Respecto al cambio en el manejo de certificados en Android 14, Se «supone» que este enfoque facilita el mantenimiento de los certificados actualizados. y eliminar certificados de autoridades de certificación comprometidas, y también evitará que los fabricantes de dispositivos manipulen la lista de certificados raíz y hará que el proceso de actualización sea independiente de las actualizaciones de firmware.

En lugar del directorio /system/etc/security/cacertscertificados en Android 14 se cargan desde el directorio /apex/com.android.conscrypt/cacerts, alojado en un contenedor APEX (Android Pony EXpress) independiente, cuyo contenido se entrega a través de Google Play y cuya integridad está controlada y firmada digitalmente 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 de dispositivos (CA) que anteriormente eran totalmente modificables por el propietario del teléfono se dividieron en dos: el proveedor del sistema operativo proporcionó una lista de CA fijas. y utilizado de forma predeterminada por todas las aplicaciones en su teléfono, y otro conjunto de CA modificables por el usuario que los usuarios podían controlar, pero que se usaban solo para aplicaciones que específicamente optaron por participar (es decir, casi ninguna).

El nuevo esquema almacenamiento de certificados podría causar dificultades a los desarrolladores involucrados en ingeniería inversainspecció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.

Como no todo es tan bueno como parece y como ya mencionamos, HTTP Toolkit expresa su disconformidad 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 mismo. sistema y tener control total del firmware.

El cambio sólo afecta a los certificados de CA del sistema, Se utilizan de forma predeterminada en todas las aplicaciones del dispositivo y no afectan 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 o cambiar, independientemente de la presencia de acceso raíz. al dispositivo.

Finalmente siSi estás interesado en aprender más al respecto, puedes consultar los detalles En el siguiente enlace.