Me he dado cuenta de que Android aparece automáticamente para las nuevas actualizaciones y parches.
¿Estas actualizaciones están firmadas para que el dispositivo sepa que es del editor oficial y no de algún spoofer del servidor?
¿Las actualizaciones están firmadas digitalmente antes de ser enviadas?
Sí, las actualizaciones están firmadas criptográficamente por el editor. Esto es para asegurar la integridad de la actualización, tanto de la corrupción no intencional durante la transmisión, como de la manipulación intencional de un atacante.
¿Quién firma las actualizaciones? ¿Es Google?
Eso depende de quién publique las actualizaciones para tu teléfono. Si tienes un teléfono Nexus o Pixel, es probable que la actualización esté publicada y firmada por Google.
Otros fabricantes, como Samsung, por ejemplo, modifican Android antes de distribuirlo. Esto puede incluir sus propias aplicaciones de sistema, sus propios lanzadores, etc. En estos casos, el fabricante es el editor de la actualización y, por tanto, el responsable de firmarla.
¿Pero no es Google quien desarrolla Android?
No es sólo Google, es el OHA - Resulta que Google es su miembro más destacado. Además, Android es Código abierto Esto significa que las contribuciones provienen de muchas empresas y personas diferentes, no sólo de Google.
Como se explica muy bien en el artículo de @MechMK1 respuesta Google es el principal contribuyente al desarrollo de AOSP. Pero AOSP no es el único software en los dispositivos Android, hay una serie de piezas de código específicas para el hardware. Por encima de todo está el kernel (basado en AOSP núcleo común source), pero que debe ser de código abierto debido a la GPL, por lo que los fabricantes de equipos originales y los vendedores de productos terminados están obligados a liberar el código fuente. Sin embargo, otras partes, en particular las HAL del espacio de usuario, que incluyen una gran parte de los controladores de hardware, y el firmware del cargador de arranque que se carga antes del núcleo en la cadena de arranque, son completamente de código cerrado en la mayoría de los casos (propiedad intelectual del OEM/vendedor de equipos). Así que el software de los dispositivos Android que conocemos es, al menos, AOSP + kernel + HALs + bootloaders (y otro firmware del SoC).
Los fabricantes de equipos originales obtienen una copia de la versión AOSP de Google de forma gratuita (en teoría; en realidad están obligados por contratos), añaden su código propietario, que también puede reemplazar innecesariamente el código AOSP (por ejemplo, para cambiar los elementos visuales) y añaden nuevas aplicaciones/características, crean la ROM y la liberan con el dispositivo (o como paquete de actualización OTA más adelante). Las claves - que se utilizan para firmar las aplicaciones del sistema/marco y actualizar el paquete después - se construyen/definen durante Proceso de compilación de la ROM que es llevado a cabo por el OEM, por lo que el OEM es dueño de las claves privadas. Esto asegura que los componentes principales del sistema operativo no reciban futuras actualizaciones de fuentes no confiables. La mayoría de los fabricantes de equipos originales también añaden los servicios de Google Play y otras aplicaciones (GMS) ya firmadas con las claves privadas de Google, de modo que estas reciben las actualizaciones directamente de Google.
El programa Android One era ligeramente diferente al principio. Una cita de Para los próximos cinco mil millones: Android One :
"Para ayudar a garantizar una experiencia consistente, los dispositivos Android One recibirán las últimas versiones de Android directamente de Google".
Pero su visión de Android puro en dispositivos con estrictos requisitos de hardware no era atractiva para los OEM, así que en un año tuvieron que estrategia de tweak de Android One y el plan cambió a:
"Los teléfonos Android One reciben la última versión de Android de los socios de hardware de Google. Los socios de Google envían las actualizaciones en función de su calendario, intentando que lleguen lo antes posible".
* Citado de Google's actualizar la página de soporte , ahora eliminado.
En resumen, las actualizaciones OTA -ya sean relacionadas con el hardware o con el framework de Android- provienen de los OEM. Ellos lo construyen y lo firman con sus claves. Google firma las actualizaciones OTA solo para sus propios dispositivos (por ejemplo, Pixel), o las aplicaciones propietarias (por ejemplo, Play Store) como cualquier desarrollador de aplicaciones.
También para Actualizaciones A/B :
"Para los dispositivos que utilizan la infraestructura OTA de Google, los cambios del sistema están todos en AOSP, y el código del cliente lo proporcionan los servicios de Google Play. Los OEM que no utilizan Infraestructura OTA de Google podrán reutilizar el código del sistema AOSP pero tendrán que suministrar su propio cliente".
Las API de actualización del sistema de AOSP ( update_engine ) por defecto utilice La CA root de Google ( /system/etc/security/cacerts_google ) para establecer https conexión con (¿Omaha?) el servidor de actualización. Pero los OEM son libres de modificar el código. En cada caso, la aplicación cliente OTA, el demonio del sistema y el servidor de actualizaciones son gestionados por el OEM.
En los dispositivos de producción release key se utiliza para firmar la actualización .zip y posiblemente también algunas aplicaciones. Su par de claves públicas se guarda en el dispositivo en /system/etc/security/otacerts.zip , utilizado para verificar la firma criptográfica del paquete de actualización. Pero adicionalmente existe otro mecanismo de firma disponible en muchos dispositivos desde Android 5, que es Bota verificada ( dm-verity ). Los OEM utilizan un par de claves RSA como parte del mecanismo de (A)VB. La clave privada se utiliza para firmar criptográficamente el árbol hash de todo /system mientras que la clave pública ( /verity_key ) se almacena en el ramdisk (dentro de boot.img en dispositivos no SAR) o del kernel llavero del sistema que verifica la integridad de dm-verity tabla de asignación (metablock) añadida después del último bloque del sistema de archivos al final de /system partición. dm-verity tabla (árbol de hash) a su vez verifica todo /system partición por coincidencia de hashes. Esto es para proteger /system de cualquier modificación involuntaria por parte de un malware o de un usuario, por ejemplo, montando R/W.
Durante actualización OTA en bloque se aplica un parche binario a todo el system archivo de dispositivo de bloque de partición. Este parche se genera tomando una diferencia binaria entre el antiguo y el actualizado system.img . La tabla actualizada debe estar firmada por la misma clave privada que posee el desarrollador de la ROM original, de lo contrario dm-verity fallaría. De la misma manera dm-verity protege /vendor y /odm particiones. boot y recovery están firmados por otra clave, ya sea proporcionado manualmente o construido con el gestor de arranque de la aplicación o guardado en algún otro lugar seguro. Así que es sólo el OEM quien asegura esta cadena de confianza durante el proceso de arranque, crea todas las llaves inicialmente y posteriormente firma y envía las actualizaciones OTA.
PreguntAndroid es una comunidad de usuarios de Android en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros usuarios, hacer tus propias preguntas o resolver las de los demás.
3 votos
Al igual que la mayoría de los teléfonos, mi teléfono no acude a Google para las actualizaciones, sino al fabricante del teléfono. Su pregunta se basa en un malentendido ..
2 votos
Las versiones/actualizaciones de Android son certificadas (no firmadas) por Google antes de ser publicadas. La certificación incluye una prueba de conformidad con respecto a la suite de compatibilidad de Android. La certificación es un proceso más legal que técnico.