Si ha estado siguiendo los desarrollos en Android, debe haber escuchado bastante el nombre "Verified Boot" en los últimos años. Google introdujo la función de seguridad en Android 4.4 (Kitkat), de forma totalmente no intrusiva, y ha ido aumentando su visibilidad en las nuevas versiones de su sistema operativo Android.
En los últimos dos días, hemos visto noticias sobre la presencia de un " Arranque verificado estrictamente aplicado " en la última versión de Google del SO móvil más usado del mundo. Android Nougat utilizará un nivel más alto de comprobación de seguridad cuando se inicie el dispositivo. Mientras que, en Marshmallow, Verified Boot solo dio una advertencia al usuario, en caso de que detectara algo incorrecto con la partición del sistema, Android Nougat lo llevará un paso más allá y usará lo que Google está llamando un "Inicio Verificado Estrictamente Forzado", que no permita que el dispositivo arranque en absoluto, en caso de que detecte anomalías en la partición, los cambios realizados en el cargador de arranque o la presencia de un código "malicioso" en el dispositivo. Esto plantea la pregunta: "¿Qué significa esto exactamente para los usuarios?", La respuesta es diferente para las dos categorías principales de usuarios de Android (usuarios ocasionales y usuarios avanzados), y vamos a proporcionar la respuesta para ambos. .
Botas verificadas estrictamente aplicadas
Primero, un poco de historia sobre el Arranque Verificado: Normalmente, cuando Android ejecuta una prueba de verificación en particiones, lo hace dividiendo las particiones en bloques de 4 KB y comparándolos con una tabla firmada. Si todo sale bien, significa que el sistema está completamente limpio. Sin embargo, si algunos bloques se manipulan o corrompen, Android informa al usuario sobre los problemas y deja que el usuario lo resuelva (o no).
Todo lo que está a punto de cambiar con Android Nougat y Strictly Forcedced Verified Boot. Cuando el arranque verificado se ejecuta en modo forzado, no tolerará ninguna falla en las particiones. Si detecta algún problema, no permitirá que el dispositivo se inicie, y podría permitirle al usuario iniciar en un entorno de modo seguro para intentar corregir los problemas. Sin embargo, Strictly Enforced Verified Boot no es solo una comprobación de bloques de datos incorrectos. Por lo general, también puede corregir errores en bloques de datos. Esto es posible gracias a la presencia de códigos de corrección de errores hacia adelante, que pueden usarse para corregir errores en bloques de datos. Sin embargo, esto no siempre puede funcionar, y en los casos en que no lo hace, estás bastante muerto en el agua.
Bota verificada estrictamente aplicada: lo bueno, lo malo y lo feo
1. El bien
La aplicación de Arranque verificado en dispositivos Android mejorará la seguridad en los dispositivos. En caso de que el dispositivo se infecte con malware, Strictly Enforced Verified Boot lo detectará la próxima vez que inicie el dispositivo y lo arregle, o posiblemente le solicite que haga algo al respecto.
Esta función también comprobará la corrupción de datos y, en la mayoría de los casos, podrá corregir cualquier error introducido en los datos, gracias a los códigos FEC. Google usa códigos FEC que pueden corregir un error de bit desconocido en 255 bits . Claro, parece un número bastante pequeño, pero pongámoslo en perspectiva, con respecto a un dispositivo móvil:
Nota: Los valores a continuación se toman de la publicación del blog del ingeniero Google Sami Tolvanen en desarrolladores de Android.
Google podría haber usado códigos FEC RS (255, 223): estos códigos podrían haber corregido 16 errores de bit desconocidos en 255 bits, pero la sobrecarga de espacio debido a los 32 bits de datos redundantes hubiera sido de casi el 15%, Y eso es mucho, especialmente en dispositivos móviles. Agregue eso al hecho de que Android es el sistema operativo predominante en los teléfonos inteligentes de bajo costo que se entregan con 4 a 8 GB de memoria, y un 15% de espacio extra parece ser mucho.
Al sacrificar las capacidades de corrección de errores, a favor de ahorrar espacio, Google decidió utilizar códigos FEC RS (255, 253). Estos códigos pueden corregir un solo error desconocido en 255 bits, pero la sobrecarga de espacio es solo del 0, 8%.
Nota: RS (255, N) es una representación de los códigos Reed-Solomon, que son un tipo de códigos de corrección de errores.
2. El malo
¿Has oído hablar de "Hay dos lados de una moneda"? Por supuesto que tienes. Si bien las intenciones de Google con el Arranque Verificado Estrictamente Aplicado fueron sin duda puras como un unicornio de bebé, sí vienen con sus propios problemas.
Cuando Strictly Enforced Verified Boot comprueba si hay malware, también busca modificaciones ilegales en el kernel, el cargador de arranque y otras cosas con las que no voy a aburrirte, pero esto significa que Android Nougat probablemente encontrará muchos problemas con el rooting, y ROMs personalizadas parpadeantes, porque el arranque verificado no puede distinguir entre el código de malware no deseado y el código que desbloquea el cargador de arranque. Lo que significa que si su dispositivo vino con un cargador de arranque bloqueado, y su OEM no permite el desbloqueo del cargador de arranque, prácticamente no puede hacerlo. Con suerte, alguien descubrirá una hazaña para esto.
Afortunadamente, la mayoría de las personas que arraigan sus dispositivos y actualizan ROMs personalizadas para las funciones y funciones adicionales, van con teléfonos aptos para desarrolladores, como el Nexus. Hay mucho que considerar con respecto a este tema, y definitivamente no es el final de las ROM personalizadas, al menos no en los dispositivos que vienen con un cargador de arranque desbloqueado, o que permiten desbloquear el cargador de arranque. Sin embargo, los dispositivos como los teléfonos Samsung no permiten oficialmente el desbloqueo del cargador de arranque, y en estos dispositivos, el desbloqueo se verá definitivamente como un "problema" por parte de Verified Boot, lo que evita que el dispositivo se inicie.
Otro problema que surgirá con el arranque verificado estrictamente forzado es el que afectará incluso a los usuarios a los que no les importa realmente obtener privilegios de root o instalar ROM personalizadas. Con el tiempo, a medida que usa su dispositivo, es probable que haya corrupción de datos naturales en la memoria; No debido a la presencia de un malware, sino simplemente porque sucede. Por lo general, esto no es un problema, o al menos no es un problema tan grave como el que verificó el Arranque Verificado. Si tiene datos corruptos que Strictly Enforced Verified Boot no puede solucionar al iniciar, no permitirá que su dispositivo se inicie. En mi opinión, ese es un problema más grande y más visible que algunos datos corruptos en la partición del usuario.
3. el feo
En todos los beneficios de la aplicación de Arranque verificado, y en todos los problemas potenciales, el más perturbador, probablemente, es el hecho de que los fabricantes de equipos originales podrían comenzar a usarlo de forma indebida para bloquear sus dispositivos de forma tal que la gente no pueda usar Android por lo que estaba destinado a Ser: abierto, amigable para el desarrollador y completamente personalizable. Strictly Enforced Verified Boot pondrá en manos de los fabricantes de equipos originales, el poder para garantizar que las personas no puedan desbloquear los cargadores de arranque en sus dispositivos, lo que les impide instalar ROM personalizadas y herramientas de mejora de características como los módulos Xposed.
Android Turrón: ¿Un cambio radical en la forma en que funciona Android?
Aunque estamos seguros de que las intenciones de Google eran simplemente evitar problemas potenciales para los usuarios casuales de Android, quienes no sabrían qué hacer en caso de que su dispositivo se viera afectado por un malware, o si su memoria hubiera corrompido los bloques de datos, podría haberle entregado a los OEM y el fabricante es la herramienta perfecta para obligar a los usuarios a vivir con lo que se les ofreció, y nada más.
Por supuesto, alguien descubrirá un exploit o una solución alternativa para esta situación, y esperamos que así sea, con el verdadero espíritu de Android. Sin embargo, hasta que alguien encuentre una solución, todo lo que nosotros, como usuarios podemos hacer, es asegurarnos de que compramos nuestros dispositivos a fabricantes amigables con los desarrolladores.
Imagen destacada Cortesía: Flickr
