Hace unos días, Google experimentaba con la atestación por hardware de SafetyNet en Android. Cosa que podría transformar para siempre el ecosistema de este sistema y, en última instancia, toda la industria.

Vayamos por partes, SafetyNet es una suite de herramientas que, en general, sirven para evitar abusos. La parte que nos interesa de ella es la API de atestación, la cual comprueba que el dispositivo, dicho de forma vulgar, sea seguro y compatible según Google. Es decir, que haya pasado la famosa prueba para que los fabricantes puedan instalarle Gapps. Pero, SafetyNet no es una comprobación en fábrica, sino que se realiza cada vez que una app llame a su API y comprueba que el sistema no se encuentre modificado de ninguna forma o corrupto. Se sobrentiende que una Custom Rom, es un sistema modificado. Tener el móvil rooteado, es un sistema modificado. Tener un Recovery personalizado, un sistema modificado. Tener el Bootloader desbloqueado, un sistema modificado. Incluso, Samsung va más allá y cualquier móvil que ha sido desbloqueado quedará marcado como modificado para siempre, a través de la quema de un fusible.

Google ha vendido bien esta tecnología, ya que sobre lo que se oye es un “antimalware”, anti vulnerabilidades y una plataforma que asegura compatibilidad evitando dispositivos corruptos o mal modificados, más adelante veremos que en realidad es seguridad por “Walled Garden”, inspirada en "Trust Zero".

Cualquiera sin conocer SafetyNet, pensaría que seria fácil de parchear o hacer un Bypass. Pero, en verdad es un sistema bien diseñado. De esta forma, la cuestión gira en que las apps sean SaaS, es decir toda su lógica importante sea de lado de servidor: Videojuegos online, apps de bancos, tickets, cupones, compras, streaming, firma, redes sociales y un largo etc. En este tipo, se manda a certificar (atestar) el dispositivo desde los servidores de la app a los de Google. Estos últimos, a través de los servicios de Google, hacían una serie de comprobaciones, que llegaban a cambiar hasta cada mes y su código está altamente ofuscado. Algunas veces, mandan partes del SO a ser analizados por los servidores. Si los tests no encuentran ningún indicio de modificación, darán una respuesta positiva a los servidores de la app, que autorizaran las credenciales de acceso. SafetyNet se encontraba roto desde hace tiempo, Magisk con MagiskHide siempre consiguió una manera de ocultarse o incluso algunos cogían credenciales de acceso de su dispositivo cuando no estaba modificado y luego simplemente las restauraban.

Ahora todo ha cambiado. Para entender el nuevo sistema, tenemos que analizar una serie de tecnologías de seguridad, que en principio son bastante positivas, pero fácilmente usables para ser liberticidas.

La primera pieza fundamental es el TEE (Trusted Execution Enviroment). En un procesador normal, hay muchas maneras de lo que se esté ejecutando no esté 100% aislado. Así, la memoria de un proceso es accesible por otro o incluso extraíble a escala de hardware. Los TEE son espacios especiales dentro de un procesador que se encuentran lo más aislados posibles, tanto su memoria volátil como la que no. Además, suelen incluir extensiones criptográficas. Por otra parte, normalmente son coprocesadores que funcionan en paralelo con el procesador o incluso chips aparte. Por lo tanto, necesitan su propio sistema operativo. De esta forma, muchos fabricantes como Qualcomm proveen uno, aunque Google, para estandarizar y facilitar el acceso a fabricantes pequeños ha sacado un sistema propio llamado Trusty. El boot de este sistema depende mucho del fabricante, pero según el análisis de varios bootloader de móviles, estos contienen imágenes de estos SO, indicando seguramente que se encarguen de cargar el SO al TEE al arranque.

Dentro del SO se ejecutarán “pequeñas apps” llamadas formalmente Trustlets. Estas estarán en un espacio aislado y tendrán acceso a una memoria completamente sellada. El destacable es Keystore TA, parte de Android, es una especie de base de datos que se encarga de** almacenar información de forma segura y limitar su acceso**. Por ejemplo, almacena las claves de descifrado del almacenamiento, solo permite el acceso con la contraseña que introduce el usuario y para evitar ataques de fuerza bruta, establece un tiempo entre intento e intento. En sus otras muchas funcionalidades, destaca la de atestar, es decir, firma un mensaje con un certificado que se encuentra en su memoria desde fábrica. De hecho, es emitido por el fabricante y está firmado por el certificado raíz de Google. En cuanto al mensaje de atestación, contiene metadatos interesantes del dispositivo, como varios IDs del dispositivo (IMEI, SN, …), información del propio sistema y datos pasados por el bootloader desde un primer momento, incluyendo si ha sido desbloqueado.

Ahora habrá que hablar del ciclo de arranque de Android. Al pulsar el botón de encendido, lo primero que se ejecutará es la BootRom, un pequeño programa normalmente quemado en el chip, que se dedicará a elegir el modo de arranque y en algunos pocos casos, precargar ciertas cosas, como el TEE. Así, cargará el famoso Bootloader, o cargador de arranque, este es como la BIOS en un PC y se encargará de preinicializar ciertas cosas. De hecho, la primera imagen que vemos en nuestras pantallas es de este. A continuación, se elegirá el modo de arranque (fastboot, recovery o el sistema). Después, se cargará el kernel (núcleo). Pero un momento, antes de seguir hay que hablar de una tecnología relativamente nueva, el Verifiedboot, es decir el arranque verificado. Básicamente, el bootloader comprobará el hash o firma del núcleo. Si no coinciden con el de fábrica, pueden ocurrir tres cosas a elección del fabricante. La primera, si el bootloader está desbloqueado, avisará de que el sistema ha sido modificado. La segunda, es que el bootloader no este desbloqueado, pero actúe como la primera. La tercera, que se niegue a arrancar. En todos los casos al TEE ya le habrá llegado que el sistema se encuentra modificado. Ahora, siguiendo con la carga del núcleo, y de una forma más estandarizada por el módulo dm-verity, se comprobará que el resto del sistema se encuentre íntegro y firmado. Dentro ya del sistema, la libertad de modificación dependerá del fabricante y en última instancia, de lo que permita el CTS.

De esta forma, cuando una app solicite SafetyNet, este enviará el mensaje de atestación recibido desde el keystore a los servidores. Este mensaje es claramente inalterable, debido a su firma criptográfica hecha con los estándares que mueven medio mundo. Además, Google ya ha fardado que si alguna llave privada se filtra, revocará sin dudar el certificado de ese fabricante.

Curiosamente, en las últimas versiones de Android, las copias de seguridad se han restringido aún más. Por otra parte, las apps solo confiarán, al conectarse a la red, en certificados del sistema que no pueden ser modificados. Por lo que el truco de restaurar una copia de las credenciales o snifear el tráfico de red y sacar las credenciales ya no funciona.

Finalmente, Google ha conseguido sellar todos los dispositivos de su ecosistema, evitando cualquier modificación. Para tal, ha usado técnicas y limitaciones muy similares a los sistemas DRM de las consolas de hoy en día. Aunque, en principio solo algunas aplicaciones requieren SafetyNet, el número va en aumento y se está vendiendo muy bien a los desarrolladores como algo esencial para sus apps conectadas a la “nube”.

Epílogo: Pasos hacia el futuro

La verdad es que con la publicidad de Google y varias asociaciones de seguridad, no será de extrañar un aumento en su uso. En última instancia, sellando todo el ecosistema de apps de Android. Marginando sistemas alternativos basados en este, emuladores, y una comunidad que lleva desde sus inicios logrando grandes hitos y mantenido dispositivos por años. La comunidad de Roms y más, como gran parte de XDA Developers.

Por otra parte, algo que reluce en esta tecnología, es la capacidad de traspasar el ecosistema Android y expandirse a más. Es decir, Google sabe que no dominará todos los sistemas operativos del mercado, pero con que sus tecnologías se incrusten en los otros, ya le aportaría suficientes ganancias. Sobretodo algunas que le den tanto control como SafetyNet. Aunque, lo lógico es que los otros sistemas no tengan interés en ello o incluso vaya en contra de sus intereses, lo fundamental es el entorno de programas o aplicaciones disponibles. Si los creadores de App se acostumbran a que esta sea segura e inabusable por SafetyNet, no pondrán su app disponible en otras plataformas en la que no exista esta tecnología o una copia. En pocas palabras, este paso no solo supone una auténtica integración vertical, controlando lo que pueden hacer los fabricantes, sino que puede convertirse en una tendencia peligrosa.

Hay que subrayar, que el ámbito político puede frenar el avance de estas tecnologías. Tanto en el ambito internacional, haciendo que SafetyNet no pueda estar disponible en todos los dispositivos (Véase el caso de Huawei), creando una fragmentación que complicaría demasiado a los desarrolladores. Tanto a un nivel local, ya que la “antimanipulación” han creado varios escenarios problemáticos (limitación de reparación, restricción de derechos del consumidor, creación de obsolescencia programada, privación del derecho a la competencia, etc).

Dentro de poco, supondrá una solución definitiva a los desarrolladores de apps. Aun así, para buenas o malas, fallará. Aunque, a nivel general, Android no será modificable, el paradigma cambiará a “jailbreaks” a determinados dispositivos. Con millones de fabricantes, no seria de extrañar que se acabase filtrando algunas claves y puede que Google no tenga piedad y las desactive a pequeños fabricantes o dispositivos viejos. Pero, ¿Y si es un modelo de alta/media gama que acaba de salir? Al menos que el fabricante sea bondadoso y haga un recall o cifre sus actualizaciones (cerrando aún más todo) pudiendo actualizar al nuevo certificado, al motor de brusquedad le temblará la mano. Denotar que dispositivos que seguramente sea fácil hacerles jailbreak serian las tablets x86. Pues tienen un sistema de arranque generalmente más estandarizado y fácil de modificar. Por otro lado, si la defensa se mueve al hardware, el ataque se mueve al hardware. Es decir, existen muchos SoCs y dispositivos muy bien documentados y usar técnicas de hardware para escalar los privilegios no seria imposible. Cierto es que en muchos casos sería una locura que requeriría trabajo, dinero y tiempo. También, aparecerán bugs en Android que permitan la escalada y algunos fabricantes no actualizarán el parche de seguridad por pereza, dejando una puerta de entrada. Por último, Google ha aplicado una técnica de divide y vencerás, pero puede convertirse en divide y perderás, ya que puede haber un aflore de una gran cantidad de métodos de bypass específicos que requerirán un parche por su parte.

Cambiando de tema, lo más probable es que veamos la aparición de un símil al Card Sharing, un dispositivo completamente comprometido que genere atestaciones válidas totalmente falsificadas para el resto. Igualmente, todas las formas de saltarse este mecanismo nunca llegarán a ser tan fáciles y universales como las actuales. Esto generará que mientras que algunos grupos simplemente se rindan, otros, que muchas veces tienen un interés de abusar unido a uno económico, sí invertan en saltárselas. Estos pueden ser cheaters que venden cuentas, piratas, scrappers de datos o incluso, la competencia de una app que quiere crearle problemas. Al final del día, los únicos perjudicados serán la comunidad de modders, los forks de Android y las apps no oficiales.

Por último, todo esto lo que supone es un cambio en el paradigma de la seguridad hacia una más orientada al Walled Garden (jardín vallado). Ya no hará falta en ofuscar APIs privadas, invertir en probar y comprobar la seguridad de estas y Apps. Tampoco se necesitarán complicados sistemas antiabusos. Simplemente aislar la app a usuarios con dispositivos sellados. De esta forma con que la API sea suficientemente robusta como para que rechace todas las peticiones que no provengan de estos, ni siquiera auditorias se le podrá hacer.

Epílogo 2: Opinión

Jardín vallado, el nombre no puede ser más exacto. No hace falta que podes y arregles tu jardín, simplemente vállalo y confía en el fabricante de esa valla. Pero el día que los vientos soplen. Pero el día que el dueño de la valla sea tu competencia. Pero el día que haya demasiadas manos empujando al otro lado. Pero el día que este agrietada y vieja. Ese día, la valla caerá y los cuervos negros y langostas entraran a pastar tu jardín. Porque la seguridad no es eso, no es levantar vallas, muros, segregar, discriminar… Levantar muros, algo que se ve cada día más en nuestro mundo y que ha llegado a arraigarse hasta en lo tecnológico.

Y en todo esto te preguntas, ¿Por qué? Porque los usuarios son tontos, que crean inseguridad. Y entonces si las personas somos borregos que necesitamos un pastor, ¿ Por qué tenemos a esto, a lo otro?¿Por qué tenemos derecho a votar? ¿Por qué tenemos derecho a la libertad? El paternalismo tiene sus límites. Si aún así el miedo a un sistema inseguro sigue acosando, desde siempre existen cucharas de palo para estos problemas. Estas son los hardwares de seguridad a parte, como los DNIe o las crypto wallets de hardware, que por lo menos no restringen nada y no tienen conexión a X servidor, millones de sensores y toda tu información. Y lo mismo con el DRM, que incluso las versiones para HTML5 están requiriendo “dispositivos certificados”.

En este mundo ya vemos paisajes con montañas de móviles de hace dos años. Aun así, la exquisitez por el beneficio, va a hacer que para estar en la última, hasta en software, tengamos que comprar los últimos modelos. Ya no habrá excusa de ROM customs sin ser segregado. Si esto es por seguridad, cuánta traerá no poder actualizar de un sistema viejo, lleno de puertas traseras o incluso con malware preinstalado.

Todavía existen alternativas que nunca estarán bajo estos sistemas, como puede ser las PWA y la web en general (Oh, espera un momento) y siempre quedarán los PCs, libres de todo esto (oh no no no).

“Quien renuncia a su libertad por seguridad, no merece ni libertad ni seguridad”
― Benjamin Franklin