⏱️ Lectura: 12 min
El equipo de GrapheneOS publicó una advertencia en su cuenta oficial de Mastodon sobre lo que considera una tendencia preocupante: Apple y Google están ampliando de forma gradual el uso de hardware attestation, el mecanismo por el cual una aplicación puede pedirle al sistema operativo una prueba criptográfica de que el dispositivo corre firmware original, con bootloader bloqueado y sin modificaciones por parte del usuario.
📑 En este artículo
- TL;DR
- Qué pasó: GrapheneOS denuncia el avance silencioso
- Cómo funciona la hardware attestation
- El historial: de SafetyNet a Play Integrity y App Attest
- Datos y cifras: cuánto se está expandiendo
- Impacto y análisis: la propiedad del hardware en disputa
- Qué sigue: regulación, presión y workarounds
- Preguntas frecuentes
- Referencias
El efecto práctico ya se siente: cada vez más bancos, billeteras digitales, plataformas de streaming y hasta apps de transporte se niegan a funcionar en dispositivos con GrapheneOS, LineageOS u otras distribuciones alternativas de Android, incluso cuando esas distribuciones son demostrablemente más seguras que el sistema que viene de fábrica.
TL;DR
- GrapheneOS denuncia que Apple y Google amplían el uso de hardware attestation para validar la integridad del dispositivo en cada vez más apps.
- Bancos, billeteras digitales y servicios de streaming bloquean a usuarios de GrapheneOS, LineageOS y equipos con bootloader desbloqueado.
- Play Integrity API reemplazó a SafetyNet en 2024 y endurece la verificación: ya no basta con pasar checks por software.
- Apple usa App Attest desde iOS 14 con la misma lógica: solo binarios firmados corriendo sobre hardware verificado.
- Estos APIs equiparan seguro con stock, penalizando a usuarios técnicos que endurecen sus propios dispositivos.
- GrapheneOS pasa el nivel básico de Play Integrity pero no STRONG, dejando a sus usuarios fuera de apps críticas como banca.
- FSF y EFF impulsan presión regulatoria: el control remoto sobre qué software puede correr en tu hardware erosiona la propiedad.
Qué pasó: GrapheneOS denuncia el avance silencioso
En una publicación reciente, el proyecto GrapheneOS — un sistema operativo derivado de Android centrado en privacidad y endurecimiento de seguridad — alertó que Apple y Google están extendiendo el uso de hardware attestation más allá de los casos de uso tradicionales como banca de alto riesgo o autenticación de pagos. La acusación específica es que ambos gigantes están normalizando que cualquier desarrollador pueda exigir, antes de permitir el uso de una app, una prueba criptográfica firmada por el chip del fabricante de que el dispositivo corre exactamente la versión del sistema operativo que Google o Apple aprobaron.
El mensaje no llega en abstracto: durante 2025 y lo que va de 2026, usuarios de GrapheneOS y de otras ROMs alternativas reportaron de forma masiva que apps como Revolut, varias billeteras de bancos en Estados Unidos, Europa y América Latina, McDonald’s, Snapchat, plataformas de streaming, y hasta apps de gobiernos para identidad digital simplemente se niegan a iniciar en sus equipos. El mensaje suele ser genérico: dispositivo no soportado, entorno no seguro o un error sin más explicación.
Lo paradójico, argumenta GrapheneOS, es que muchos de esos usuarios eligieron una ROM alternativa precisamente para mejorar la seguridad de su dispositivo, no para empeorarla.
Cómo funciona la hardware attestation
Para entender la disputa hace falta entender qué es hardware attestation. En un teléfono moderno, además del procesador principal existe un componente aislado: el Secure Element o Trusted Execution Environment (TEE). En los Pixel se llama Titan M, en los iPhone es el Secure Enclave, en los Samsung es Knox, y en chips Qualcomm o MediaTek hay equivalentes basados en ARM TrustZone.
Este chip tiene llaves privadas que nunca salen del silicio, grabadas en fábrica. Cuando una app quiere verificar que el dispositivo es genuino y no fue manipulado, le pide al sistema operativo un token de integridad. El sistema deriva una prueba criptográfica firmada por la llave del Secure Element. Esa firma viaja hasta el servidor de la app, que consulta a Google o Apple para confirmar que es válida y, además, que el dispositivo está en un estado aprobado: bootloader bloqueado, sistema operativo firmado por el fabricante, sin modificaciones.
El flujo se ve así de forma simplificada:
graph LR
A["App movil"] --> B["Solicita token de integridad"]
B --> C["Play Integrity / App Attest"]
C --> D["Hardware Keystore (TEE)"]
D --> E["Token firmado por el chip"]
E --> F["Backend de la app"]
F --> G{"Verifica firma con Google/Apple"}
G -->|Valido| H["Acceso permitido"]
G -->|Invalido| I["Acceso bloqueado"]El problema central es que esa verificación no distingue entre dispositivo comprometido y dispositivo modificado por su dueño con intenciones legítimas. Para el servidor remoto, un teléfono con un troyano instalado en el firmware original y un teléfono con GrapheneOS oficial son ambos “no genuinos”, y por tanto rechazables.
El historial: de SafetyNet a Play Integrity y App Attest
Google introdujo SafetyNet Attestation en 2014 como un servicio para que apps detectaran roots y modificaciones. Durante años fue posible pasar SafetyNet desde ROMs alternativas usando trucos como Magisk Hide, porque la verificación era principalmente por software. En 2023 Google empezó a deprecar SafetyNet y lo reemplazó por Play Integrity API, que se volvió obligatorio durante 2024.
Play Integrity devuelve tres veredictos por capas:
- MEETS_BASIC_INTEGRITY — el dispositivo es razonablemente un Android, aunque sea un emulador o tenga modificaciones.
- MEETS_DEVICE_INTEGRITY — pasa checks de software pero también algunos de hardware.
- MEETS_STRONG_INTEGRITY — bootloader bloqueado y sistema operativo firmado por el fabricante.
⚠️ Ojo: GrapheneOS aprueba el nivel BASIC y DEVICE en algunos dispositivos, pero nunca STRONG, porque su bootloader queda firmado con la clave del usuario, no con la de Google. Muchas apps bancarias exigen STRONG.
Apple introdujo App Attest en iOS 14, con un diseño similar: el Secure Enclave firma un token y Apple verifica que la app sea un binario sin modificar corriendo en un iPhone genuino. Como en iOS no existe un equivalente real a una ROM alternativa, el debate es menor pero igualmente importante: jailbreaks y modificaciones quedan fuera del juego para cualquier app que use App Attest.
Datos y cifras: cuánto se está expandiendo
Según el propio proyecto GrapheneOS y reportes de comunidades como r/GrapheneOS y r/LineageOS, la lista de apps que rompen sobre ROMs alternativas creció en 2025 de unas decenas a varios cientos. Algunos puntos concretos:
- Más del 80% de las apps bancarias europeas y norteamericanas usan algún nivel de Play Integrity, según mediciones informales de la comunidad de modders.
- Revolut, Wise, N26, Nubank, Mercado Pago, BBVA, Santander, Itaú son reportadas como bloqueantes para usuarios de GrapheneOS por documentación pública.
- Google añadió en 2024 dos veredictos extra (recognised version y environment details) para que las apps verifiquen incluso qué versión específica del Play Store corre el dispositivo.
- Apple amplió App Attest en iOS 17 y iOS 18 con nuevas APIs de integrity tokens orientadas a anti-fraude general, no solo banca.
El impacto sobre los usuarios técnicos no es marginal: GrapheneOS reportó haber superado el millón de usuarios activos en 2024, y se estima que LineageOS suma varios millones más. Hablamos de una población pequeña pero significativa de personas que se quedaron sin acceso a servicios que el resto da por sentados.
Impacto y análisis: la propiedad del hardware en disputa
Para GrapheneOS, la Free Software Foundation, la Electronic Frontier Foundation y otras organizaciones de derechos digitales, este movimiento representa un cambio cualitativo en lo que significa ser dueño de un teléfono. Históricamente, ser dueño de una computadora implicaba poder ejecutar el software de tu elección sobre ella. Con la expansión de hardware attestation, ese principio se erosiona: tu hardware sigue siendo tuyo, pero el conjunto de software que puede acceder a servicios externos está restringido por una verificación remota.
El argumento técnico de Apple y Google es defendible: la attestation reduce el fraude, dificulta los emuladores que automatizan ataques, y protege a usuarios menos sofisticados frente a troyanos bancarios. Los números les ayudan: bancos reportaron caídas del fraude móvil tras adoptar Play Integrity STRONG.
💭 Clave: El problema no es la tecnología sino el criterio binario. Hardware attestation podría verificar “el dispositivo está en buen estado” sin verificar “el dispositivo corre exactamente el software que el fabricante quiere”. La fusión de ambas señales es una decisión política, no técnica.
La crítica de GrapheneOS es que la attestation no necesita ser binaria. Un dispositivo con bootloader desbloqueado y firmware original podría reportar ambos hechos al servidor, y cada app decidir su política. En cambio, el diseño actual castiga a usuarios que en muchos casos son más seguros que la base instalada.
Qué sigue: regulación, presión y workarounds
La conversación sobre regulación está abierta. En Europa, la Digital Markets Act (DMA) obliga a Apple y Google a permitir tiendas alternativas, pero no menciona explícitamente la attestation. En Estados Unidos, la FTC ha analizado prácticas similares en otros contextos. Algunos académicos de derecho informático argumentan que exigir hardware attestation para servicios esenciales (banca, identidad digital, salud) viola principios de neutralidad tecnológica.
💡 Tip: Si dependés de apps bancarias y querés usar GrapheneOS, una solución práctica es mantener un segundo dispositivo (un Pixel barato con stock Android, o incluso un iPad usado) exclusivo para esas apps. Tu dispositivo principal con GrapheneOS sigue siendo tu identidad digital primaria.
A nivel técnico, las soluciones desde la comunidad pasan por:
- Esfuerzos de GrapheneOS para que más fabricantes permitan firmar el bootloader con llaves del usuario sin perder hardware attestation (algo que técnicamente es posible).
- Versiones modificadas del Play Store con módulos como Universal SafetyNet Fix (cada vez menos efectivos).
- Lobby ante reguladores para que la attestation sea una señal entre muchas, no un veto.
En LATAM el escenario es particularmente delicado: la bancarización móvil avanzó más rápido que la cobertura de cajeros físicos. Quedar fuera de la app del banco no es una incomodidad sino una exclusión real de servicios financieros. Mercado Pago, PIX en Brasil, transferencias inmediatas, identidad digital en Chile o Uruguay — todo eso se mueve por apps que, cada vez más, exigen integridad fuerte.
📖 Resumen en Telegram: Ver resumen
Preguntas frecuentes
¿Qué es exactamente hardware attestation?
Es un mecanismo por el cual el chip de seguridad de un teléfono firma criptográficamente un token que prueba el estado del dispositivo: marca, modelo, versión del sistema operativo y si el bootloader está bloqueado. Una app puede pedir ese token y verificarlo contra Google o Apple antes de permitir el uso.
¿Por qué GrapheneOS no pasa el nivel STRONG de Play Integrity?
Porque GrapheneOS firma su bootloader con la llave del usuario, no con la de Google. Aunque el dispositivo es más seguro que muchos teléfonos con firmware stock, el criterio de STRONG es binario: solo bootloaders firmados con llaves de fabricantes aprobados pasan.
¿Puedo seguir usando mi banco con GrapheneOS?
Depende del banco. Algunos solo piden el nivel BASIC o DEVICE de Play Integrity, que GrapheneOS pasa en Pixels modernos. Otros exigen STRONG y bloquean cualquier ROM alternativa. La comunidad mantiene listas actualizadas en grapheneos.org/usage.
¿Esto pasa también en iPhone?
Sí, vía App Attest. La diferencia es que en iOS no existe una ROM alternativa popular, así que la discusión se centra en jailbreaks y en apps que rechazan dispositivos con modificaciones. El principio es el mismo: el Secure Enclave firma una prueba de integridad y la app la verifica con Apple.
¿Por qué los bancos quieren hardware attestation?
Para reducir fraude. Troyanos bancarios, emuladores que automatizan abuso, y dispositivos comprometidos son problemas reales. Hardware attestation hace mucho más difícil ejecutar la app del banco en un entorno controlado por un atacante.
¿Hay alguna forma de pasar la attestation sin perder GrapheneOS?
Para el nivel STRONG, no de forma estable. Existieron parches como Universal SafetyNet Fix y módulos de Magisk, pero Google los neutraliza con regularidad. La vía limpia es presión regulatoria y diálogo con bancos para que acepten niveles menos estrictos cuando hay alternativas equivalentes.
Referencias
- GrapheneOS Mastodon — publicación original donde el proyecto alerta sobre la expansión de attestation por parte de Apple y Google.
- grapheneos.org — sitio oficial del proyecto con documentación técnica sobre su modelo de seguridad y compatibilidad con Play Integrity.
- Play Integrity API — documentación oficial de Google sobre los veredictos BASIC, DEVICE y STRONG y su uso recomendado.
- Apple App Attest — documentación oficial de Apple sobre el equivalente de attestation en iOS basado en el Secure Enclave.
- GrapheneOS en Wikipedia — contexto sobre el proyecto, su historia, y su filosofía respecto a la seguridad sin sacrificar control del usuario.
📱 ¿Te gusta este contenido? Únete a nuestro canal de Telegram @programacion donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.
0 Comentarios