Hace apenas un año, instalar GrapheneOS significaba resignarse a que el banco mostrara una pantalla roja de "dispositivo no compatible". Hoy varias apps bancarias que antes bloqueaban cualquier Android que no fuera de fábrica dejan pasar al mismo teléfono sin que el usuario cambie nada de su lado. El cambio no vino de una app para falsear datos ni de un hackeo: vino de cómo funciona realmente la verificación que esas apps usan por debajo, llamada Play Integrity API.
Entender esa verificación explica por qué GrapheneOS puede superarla de forma legítima, sin ocultar nada y sin depender de que Google avale su sistema operativo.
TL;DR
- Play Integrity API reemplaza a SafetyNet y clasifica cada equipo en tres niveles: básico, dispositivo y fuerte.- La atestación de hardware depende del chip de seguridad del teléfono, no del sistema operativo que corra encima.- GrapheneOS relockea el bootloader con su propia llave y conserva intacta la cadena de confianza del hardware Pixel.- Una app bancaria nunca decide sola: envía un token a los servidores de Google y espera un veredicto firmado.- El estado 'amarillo' de Verified Boot certifica un sistema distinto al de fábrica sin marcarlo como comprometido.
¿Qué es Play Integrity API?
Play Integrity API es el servicio de Google Play que permite a una aplicación Android preguntarle al sistema si el dispositivo, la app y la cuenta son genuinos antes de ejecutar una acción sensible. Sustituye a la antigua SafetyNet Attestation y entrega un veredicto firmado criptográficamente, no una opinión que el propio teléfono se hace sobre sí mismo.
Google retiró SafetyNet Attestation por completo y migró el ecosistema bancario, de delivery y de videojuegos hacia Play Integrity API, que depende de criptografía respaldada por hardware en lugar de una lista de chequeos de software fáciles de imitar. La diferencia es clave: SafetyNet se podía falsear con módulos que inyectaban las respuestas correctas, mientras que Play Integrity API exige una firma que solo un chip físico puede producir.
Por qué importa para quien usa GrapheneOS
Durante años, buena parte de la banca móvil en LATAM y Europa rechazaba cualquier Android que no fuera "de fábrica", sin importar si pasaba o no la verificación oficial de Google. Esa política dependía de cada equipo de desarrollo: algunos añadían sus propios chequeos (buscar binarios de root, mirar si el bootloader estaba desbloqueado) por encima del veredicto oficial, y rechazaban todo lo que no reconocían.
La cuenta de GrapheneOS en Mastodon reporta cada vez más casos de bancos que simplifican esa lógica y confían directamente en el veredicto de la API en lugar de mantener sus propias listas negras. Eso abre la puerta a cualquier sistema que lo apruebe de forma legítima, GrapheneOS incluido, sin que el usuario tenga que esconder nada.
💭 Clave: el veredicto de la API no dice "es Android de fábrica". Dice "el hardware es genuino y el arranque está verificado". Son dos preguntas distintas, y solo la segunda es la que de verdad le importa a un banco.
Los tres niveles de verdicto de la atestación de hardware
Play Integrity devuelve un campo llamado deviceRecognitionVerdict que puede incluir hasta tres etiquetas acumulativas. Cuantas más aparecen en la respuesta, más estricta es la garantía que recibe el backend que pregunta.
NivelQué certifica¿GrapheneOS lo alcanza?MEETS_BASIC_INTEGRITYEl equipo no muestra señales obvias de ser un emulador o un root sin ocultarSíMEETS_DEVICE_INTEGRITYEs un modelo certificado por Google (Play Protect certified) con una clave de atestación de hardware válidaSí, en los Pixel soportadosMEETS_STRONG_INTEGRITYHardware certificado más arranque verificado con bootloader bloqueado, sin desbloqueos recientes detectadosSí, si el usuario relockea el bootloader tras instalar
Un dispositivo puede recibir los tres niveles a la vez porque son acumulativos: alcanzar el nivel fuerte implica automáticamente los otros dos. Lo que determina el resultado no es la marca del sistema operativo, sino el estado físico del chip y del arranque en el momento exacto de la consulta.
Cómo funciona la cadena de confianza por hardware
Cada teléfono con un chip de seguridad dedicado (en los Pixel, el Titan M2) trae grabada de fábrica una clave de atestación única, firmada por un certificado que remonta hasta el fabricante. Cuando una app pide un veredicto, Google Play Services le pasa la solicitud a ese chip, que firma una declaración sobre el estado del sistema: si el arranque verificado está activo, qué clave lo verificó y si el bootloader está bloqueado.
Esa firma, no el sistema operativo, es la prueba de genuinidad. El teléfono nunca se autoevalúa: entrega un certificado que terceros pueden validar contra la raíz de confianza publicada por Google, según documenta Android Key and ID Attestation.
flowchart TD
A["App bancaria"] --> B["SDK Play Integrity"]
B --> C["Google Play Services"]
C --> D["Chip de seguridad (Titan M2)"]
D --> E["Clave de atestacion de fabrica"]
E --> F["Certificado firmado"]
F --> G["Servidor de Google verifica la cadena"]
G --> H["Veredicto: BASIC / DEVICE / STRONG"]
H --> I["Backend del banco"]
El Titan M2 firma el estado del arranque antes de que cualquier app vea el resultado.
Ejemplos prácticos: cómo lo usa el backend de un banco
El flujo completo involucra al menos tres actores: la app en el teléfono, los servidores de Google y el servidor propio del banco. La app nunca ve el veredicto real, solo reenvía un token opaco.
sequenceDiagram
participant App as App bancaria
participant PS as Google Play Services
participant HW as Chip de seguridad
participant Srv as Servidor del banco
App->>PS: solicita token con nonce
PS->>HW: pide firma de atestacion
HW-->>PS: certificado firmado
PS-->>App: token opaco
App->>Srv: envia token
Srv->>Srv: llama a decodeIntegrityToken en Google
Srv-->>App: permite o bloquea la operacion
En el lado del cliente, el código es breve. Pide un token atado a un nonce que generó el propio servidor del banco, para evitar que alguien reutilice una respuesta vieja:
val integrityManager = IntegrityManagerFactory.create(applicationContext)
val request = IntegrityTokenRequest.builder()
.setNonce(nonceDelServidor)
.build()
integrityManager.requestIntegrityToken(request)
.addOnSuccessListener { response ->
enviarAlBackend(response.token())
}
Ese código devuelve una cadena opaca: un JWT que el cliente no puede leer ni manipular, porque la clave para decodificarlo solo la tiene Google. El paso real ocurre en el servidor del banco, que llama a la API con ese token:
const { google } = require('googleapis');
const playintegrity = google.playintegrity('v1');
const auth = new google.auth.GoogleAuth({
scopes: ['https://www.googleapis.com/auth/playintegrity'],
});
const res = await playintegrity.v1.decodeIntegrityToken({
packageName: 'com.banco.app',
requestBody: { integrityToken: tokenDelCliente },
auth,
});
console.log(res.data.tokenPayloadExternal.deviceIntegrity);
La salida esperada es un objeto JSON con el campo que define todo el resto del artículo:
{
"deviceRecognitionVerdict": ["MEETS_STRONG_INTEGRITY", "MEETS_DEVICE_INTEGRITY", "MEETS_BASIC_INTEGRITY"]
}
Si el arreglo incluye los tres niveles, el backend del banco sabe que corre sobre hardware Pixel genuino con el bootloader bloqueado, sin importar qué sistema firmó esa imagen de arranque.
Cómo GrapheneOS logra superar la verificación de integridad de Android sin depender de Google
GrapheneOS no pide permiso a Google ni modifica el chip de seguridad: aprovecha una función que Google ya documenta como parte del estándar de Android Verified Boot. Cualquier Pixel compatible permite generar una clave propia y relockear el bootloader con ella en lugar de dejarlo desbloqueado o usar la clave de fábrica.
El chip sigue firmando el estado del arranque igual que en un Pixel de fábrica, solo que ahora el campo que identifica qué clave verificó esa firma apunta a la clave del usuario en vez de a la de Google. La cadena de confianza del hardware (la que de verdad le importa a Play Integrity API) sigue intacta, porque nunca dependió del sistema operativo que corre encima, sino del chip grabado en fábrica.
Esa es la diferencia con un Android rooteado con herramientas como Magisk: ahí la estrategia es ocultar señales (módulos como Shamiko esconden el root) en una carrera constante contra las actualizaciones de detección de Google. GrapheneOS no oculta nada porque no hay nada que ocultar: no instala root de sistema, documenta públicamente su estado de arranque y pasa el chequeo porque, en los términos exactos que define Google, es un dispositivo con hardware genuino y arranque verificado.
stateDiagram-v2
Verde: Clave oficial del fabricante, Android de fabrica
Amarillo: Clave propia del usuario, caso GrapheneOS
Naranja: Bootloader desbloqueado, sin verificacion
Rojo: Firma invalida o arranque corrupto
[*] --> Verde
[*] --> Amarillo
[*] --> Naranja
[*] --> Rojo
Naranja --> Amarillo: relockear con llave propia
Amarillo --> Verde: volver a firmware de fabrica
Ese estado "amarillo" es, según la documentación oficial de Android Verified Boot, una verificación legítima, distinta de la roja (firma inválida) o la naranja (sin bloqueo alguno). Un banco que lee únicamente los niveles oficiales de integridad no distingue entre verde y amarillo; solo los que agregan una verificación extra sobre la clave específica de arranque llegan a notar la diferencia, y esa es una decisión de cada equipo bancario, no una limitación de la API.
Errores comunes y gotchas
- Confundir aprobar la verificación con desbloquear todo: algunos bancos suman validaciones propias por fuera de la API (huella del modelo, geolocalización, listas negras) y bloquean GrapheneOS aunque el veredicto sea el más alto.- Dejar el bootloader desbloqueado: el estado pasa a naranja y ninguna app bancaria lo acepta, con o sin Google Play en sandbox instalado.- Creer que el sandbox de Google Play rompe la atestación: ese sandbox corre sin privilegios de sistema, pero el campo que lee el chip vive en el hardware, no en el paquete de Google Play.- Combinar GrapheneOS con Magisk esperando mantener el nivel fuerte: reintroduce justo el root que Play Integrity API busca detectar, y el proyecto GrapheneOS lo evita por diseño.
Comparativa con alternativas
OpciónVeredicto típicoCompromisoAndroid de fábrica (Pixel, Samsung)STRONGNinguno, pero sin control real del sistemaGrapheneOS con bootloader relockeadoSTRONG en la mayoría de bancosAlgunas apps agregan chequeos extra y lo rechazan igualCustom ROM sin relock, bootloader abiertoBASIC como máximoRechazado por casi toda la bancaAndroid rooteado con Magisk y ocultamientoVariable e inestableDepende de esconder señales; se rompe con cada actualización de Google
Cómo empezar: comprobar el veredicto en tu propio teléfono
No hace falta escribir código para ver dónde queda tu equipo. La app gratuita Play Integrity API Checker, disponible en Play Store y funcional dentro del Google Play en sandbox de GrapheneOS, llama a la misma API que usaría un banco.
- Instalá la app desde Play Store en tu dispositivo.- Abrila y tocá el botón de comprobación.- Leé el campo
deviceRecognitionVerdicten el resultado.
Si el bootloader quedó relockeado correctamente, el resultado lista los tres niveles: MEETS_BASIC_INTEGRITY, MEETS_DEVICE_INTEGRITY y MEETS_STRONG_INTEGRITY. No hay forma directa de verificar desde afuera qué hace cada banco con ese resultado, porque la política final vive en su propio servidor, no en el teléfono: ese dato no es público.
Quien quiera un chequeo más técnico puede usar Auditor, una app que se apoya en el mismo mecanismo de atestación de hardware pero muestra el certificado completo al usuario en vez de ocultarlo detrás del backend de un banco.
Profundizando: la extensión del certificado que lo hace posible
Por dentro, el chip no devuelve un simple "sí" o "no". Firma un certificado X.509 que incluye una extensión específica (la Key Attestation extension, identificada con el OID 1.3.6.1.4.1.11129.2.1.17) con una estructura de datos que describe, entre otras cosas, si el dispositivo está bloqueado, el estado de Verified Boot, el hash de la clave que verificó el arranque y el nivel de parche de seguridad instalado.
La cadena de certificados sube del chip a una clave intermedia del fabricante y de ahí a una raíz de confianza que Google mantiene y publica. Esa raíz no cambia según el sistema operativo: es una propiedad del hardware, grabada una sola vez en la fábrica. Por eso un chip legítimo sigue produciendo certificados válidos sin importar qué firmware corra arriba, siempre que el arranque se mantenga verificado contra alguna clave, oficial o propia.
📖 Resumen en Telegram: Ver resumen
Tu próximo paso: instalá Play Integrity API Checker en tu Android actual y compará el campo deviceRecognitionVerdict antes y después de bloquear el bootloader con una clave propia.
Preguntas frecuentes
¿Play Integrity API reemplaza por completo a SafetyNet Attestation?
Sí, Google retiró SafetyNet Attestation y migró a los desarrolladores hacia esta nueva API, basada en atestación de hardware en lugar de chequeos de software.
¿GrapheneOS necesita rootear el teléfono para funcionar?
No, y de hecho evita el root de sistema a propósito: esa decisión de diseño es parte de por qué conserva un veredicto alto en Play Integrity API.
¿Cualquier banco que acepta Android de fábrica acepta automáticamente GrapheneOS?
No. Algunos agregan validaciones propias (modelo del equipo, geolocalización) por fuera del veredicto oficial, así que el resultado varía de un banco a otro.
¿Qué pasa si dejo el bootloader desbloqueado en GrapheneOS?
El estado de arranque verificado cae a "naranja" y el nivel más alto de verificación deja de estar disponible para cualquier app, incluidas las bancarias.
¿La app Auditor hace lo mismo que Play Integrity API?
Usa el mismo mecanismo de atestación de hardware, pero lo muestra directamente al usuario en vez de ocultarlo detrás del backend de una app bancaria.
Referencias
- GrapheneOS en Mastodon: hilo original sobre bancos que cambian su política de verificación.- GrapheneOS FAQ: documentación oficial del proyecto sobre atestación y compatibilidad bancaria.- Android Developers: Play Integrity API: documentación oficial de los niveles de verdicto y la migración desde SafetyNet.- Android Open Source Project: Verified Boot: especificación de los estados verde, amarillo, naranja y rojo del arranque verificado.- Android Developers: Key and ID Attestation: detalle de la extensión de certificado que respalda la atestación de hardware.
📱 ¿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.
Top comments (0)