> For the complete documentation index, see [llms.txt](https://docs.blerify.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.blerify.com/es/introduccion-a-la-verificacion/learn/platform-attestation.md). # Atestación de plataforma Android e iOS exponen capacidades de atestación fundamentalmente diferentes a las apps de billetera de terceros. Esta página explica qué puede y qué no puede demostrar cada plataforma, cómo esa asimetría determina la evidencia que Blerify devuelve a tu endpoint de verificación y cómo redactar una política que la tenga en cuenta. *** ## Requisitos previos Debes estar familiarizado con los niveles de garantía de Blerify (Básico, Estándar, Premium) y la estructura general de la response de evidencia de verificación. Si aún no has leído [niveles de garantía](/es/introduccion-a-la-verificacion/learn/assurance-tiers.md) todavía, comienza por ahí. *** ## Por qué difieren las plataformas En los niveles Estándar y Premium, Blerify solicita a la billetera que envíe datos de atestación junto con la presentación de la credencial. Esos datos respaldan dos afirmaciones: la clave de firma se encuentra en hardware seguro y el usuario se autenticó con sus datos biométricos antes de cada operación de firma. En Android, una sola API —Android Key Attestation— permite que la billetera produzca una cadena de certificados X.509 firmada hasta una raíz administrada por Google. Esa cadena codifica directamente las propiedades de la clave: dónde se encuentra (TEE o StrongBox), si se requieren datos biométricos para usarla y si la clave se destruye cuando se registra un nuevo dato biométrico. Cada propiedad está firmada por el hardware y no puede ser falsificada por software, incluso en un dispositivo con root. En iOS, la API equivalente es Apple App Attest. Demuestra que una copia sin modificar de la app registrada, ejecutándose en hardware Apple genuino, posee la clave de firma. Lo que no puede demostrar es dónde se encuentra la clave dentro del dispositivo, si se requieren datos biométricos para cada firma o si la clave se invalidará al cambiar el registro biométrico. Apple no proporciona ninguna API que atestigüe las propiedades de las claves de Secure Enclave a apps de terceros; la billetera informa esas propiedades por sí misma. Esta es una decisión arquitectónica de Apple, no una limitación de ninguna implementación de billetera. La brecha existe desde que se lanzó App Attest en 2021 y afecta a todas las billeteras de terceros en iOS. *** ## Qué significa esto en la response de evidencia La asimetría aparece en dos lugares: campos cuyos valores difieren según la plataforma y `_reason` campos que explican por qué un campo está ausente. ### `security_level_attested` En Android, `key_attestation.security_level` — ya sea `STRONG_BOX` o `TRUSTED_ENVIRONMENT` — se extrae directamente de la cadena de certificados firmada por hardware. Blerify establece `security_level_attested: true`. En iOS, la billetera informa por sí misma `SECURE_ENCLAVE`. Blerify establece `security_level_attested: false`. ```json // Android — Estándar tier "key_attestation": { "security_level": "STRONG_BOX", "security_level_attested": true, "platform": "android", "format": "android_key_attestation", "key_biometric_binding": { "biometric_required": true, "auth_type": ["FINGERPRINT", "FACE"], "auth_timeout_seconds": 0, "invalidated_on_enrollment_change": true, "attested": true } } ``` ```json // iOS — Estándar tier "key_attestation": { "security_level": "SECURE_ENCLAVE", "security_level_attested": false, "platform": "ios", "format": "app_attest", "key_biometric_binding": { "biometric_required": true, "auth_type": ["FACE"], "auth_timeout_seconds": 0, "invalidated_on_enrollment_change": true, "attested": false } } ``` `attested: false` en iOS significa que las `key_biometric_binding` propiedades son informadas por la billetera. En un dispositivo genuino que ejecuta una app sin modificar, reflejan con precisión cómo se configuró la clave de Secure Enclave. En un dispositivo con jailbreak, pueden ser falsificadas. Android Key Attestation no puede falsificarse porque la cadena de certificados está firmada por hardware al que el sistema operativo no puede acceder. ### `key_biometric_binding` campos Estos cinco campos describen la política de control de acceso que rige la clave de firma. | Campo | Qué significa | Android | iOS | | ---------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------- | --------------------------------- | | `biometric_required` | Se requiere autenticación biométrica antes de cada operación de firma | Atestado por hardware | Informado por la propia billetera | | `auth_type` | Qué autenticador acepta la clave: `FINGERPRINT`, `FACE`, o `DEVICE_CREDENTIAL` | Atestado por hardware | Informado por la propia billetera | | `auth_timeout_seconds` | Segundos de reutilización permitidos después de la autenticación. `0` significa que cada operación de firma requiere una autenticación nueva; no hay ventana de caché | Atestado por hardware | Informado por la propia billetera | | `invalidated_on_enrollment_change` | La clave se destruye si se agrega cualquier nueva biometría al dispositivo | Atestado por hardware | Informado por la propia billetera | | `atestiguado` | Si los cuatro campos anteriores están atestiguados por hardware (`true`) o autodeclarados (`false`) | Siempre `true` | Siempre `false` | `auth_timeout_seconds: 0` combinado con `invalidated_on_enrollment_change: true` es la configuración más sólida. La clave no se puede usar sin la biometría del titular en el momento de la firma, y registrar cualquier nueva biometría en el dispositivo destruye permanentemente la clave. ### Biometría fuerte vs. credencial del dispositivo Ambas plataformas admiten dos rutas de vinculación de claves: la **ruta biométrica fuerte** (huella dactilar o reconocimiento facial) y la **ruta de credenciales del dispositivo** (PIN, patrón o código de acceso). La ruta elegida al momento de crear la clave determina qué `auth_type` informes. En la ruta biométrica fuerte, `auth_type` es `["FINGERPRINT"]`, `["FACE"]`, o ambos, y `invalidated_on_enrollment_change` es `true`. En la ruta de credencial del dispositivo, `auth_type` es `["DEVICE_CREDENTIAL"]` y `invalidated_on_enrollment_change` es `false` — un cambio de PIN no destruye la clave. Esta distinción importa para las afirmaciones de no repudio: no se puede volver inaccesible a un atacante que conoce el PIN una clave en la ruta de credencial del dispositivo. ### `device_attestation` en Premium en iOS En Premium, una billetera de Android envía un token de Play Integrity que produce un veredicto de integridad del dispositivo: bootloader bloqueado, imagen del SO certificada, fuente legítima de instalación de la app y parches de seguridad recientes. Estas son señales independientes que la attestation de clave no cubre. iOS no tiene una API equivalente para apps de terceros. App Attest, que ya se consume por completo en el nivel Estándar, verifica la identidad de la app frente a los servidores de Apple, pero no produce un veredicto de integridad del dispositivo, no puede detectar jailbreaks y no inspecciona la imagen del SO. En Premium en iOS, `device_attestation` siempre es `null` con `device_attestation_reason: "platform_not_available"`. ```json // iOS — Premium tier "device_attestation": null, "device_attestation_reason": "platform_not_available" ``` Esto no es un fallo — es una restricción estructural de la plataforma. La consecuencia práctica es que la mejora a Premium en iOS proviene por completo de la capa biométrica. `liveness_verification` y `coercion_check` funcionan de manera idéntica en ambas plataformas. ### `device_metadata` atestación Android Key Attestation incorpora el modelo del dispositivo y la versión del sistema operativo en la cadena de certificados firmada por hardware, por lo que `device_metadata.attested` es `true` en Android. App Attest demuestra la autenticidad del dispositivo, pero no incluye el modelo ni la versión del sistema operativo en el objeto de atestación, por lo que esos valores son autoinformados por la billetera en iOS y `device_metadata.attested` es `false`. ```json // Android "device_metadata": { "device_model": "Pixel 8", "os_version": "Android 15 (patch 2026-03-05)", "attested": true, "attestation_source": "android_key_attestation" } // iOS "device_metadata": { "device_model": "iPhone 15 Pro", "os_version": "iOS 18.3", "attested": false, "attestation_source": "billetera_self_reported" } ``` *** ## El `_reason` campo Cada campo de evidencia opcional tiene un campo complementario `_reason` campo. Cuando se completa el campo principal, `_reason` es `null`. Cuando el campo principal está `null`, `_reason` explica por qué. | Valor | Significado | Qué hacer | | --------------------------- | ----------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------ | | `null` | El campo está completado | N/D | | `platform_not_available` | La plataforma no tiene API para esta capacidad — por ejemplo, iOS `device_attestation` en Premium | Límite estructural — acepta o aplica una regla de política específica de la plataforma | | `billetera_no_compatible` | La billetera no implementa las extensiones de Blerify | Brecha de capacidad — reduce la garantía o dirige a los usuarios a una billetera compatible | | `sin_solicitud` | Tu configuración de verificación no realizó una solicitud de este nivel o función | Ausencia esperada | | `usuario_denegó` | El usuario denegó un permiso requerido (acceso a la cámara, solicitud biométrica) | Negativa Activa — enrútalo a revisión manual en lugar de tratarlo igual que un límite estructural de la plataforma | | `fallido` | Se intentó la validación, pero los datos fueron rechazados — token no válido, suplantación detectada, desajuste de afirmación | Trátalo como una señal sólida de integridad — investiga | | `attestation_not_supported` | Dispositivo Android antiguo donde la clave está en hardware pero la atestación criptográfica no está disponible | Respaldado por hardware, pero no demostrable — acéptalo o reduce el nivel según tu política | El `_reason` el campo siempre está presente en el esquema de respuesta — `null` cuando el campo principal está completado. Puedes confiar en una estructura consistente y nunca necesitas inferir la semántica de ausencia a partir de un campo faltante. La distinción entre `platform_not_available` y `usuario_denegó` importa para la política. Un dispositivo que estructuralmente no puede producir una señal es diferente de un usuario que eligió activamente no proporcionar una. Considera enrutar `usuario_denegó` a una cola de revisión separada en lugar de tratarlo igual que un límite de la plataforma. De manera similar, `attestation_not_supported` en un dispositivo Android antiguo es diferente de `fallido`. La primera es una limitación heredada de hardware que afecta a menos del 1 % de la flota Android Activa; la segunda es una falla de integridad Activa. *** ## Comparación de plataformas | Campo de evidencia | Android | iOS | | ----------------------------------------- | ------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------ | | `key_attestation.security_level` | Atestación por hardware (`STRONG_BOX` o `TRUSTED_ENVIRONMENT`) | Autoinformado (`SECURE_ENCLAVE`) | | `key_attestation.security_level_attested` | `true` | `false` | | `key_biometric_binding.*` | Los cinco campos están atestiguados por hardware | Los cinco campos son autoinformados | | `key_biometric_binding.attested` | `true` | `false` (siempre) | | `device_metadata.attested` | `true` | `false` | | `device_metadata.attestation_source` | `android_key_attestation` | `billetera_autoinformada` | | `device_attestation` en Premium | Play Integrity — integridad del dispositivo, certificación del sistema operativo, integridad de la app | `null`, `_reason: "platform_not_available"` | | `liveness_verification` en Premium | Vivacidad total — independiente de la plataforma | Vivacidad total — independiente de la plataforma | | `coercion_check` en Premium | Análisis facial en cuadros de vivacidad — independiente de la plataforma | Análisis facial en cuadros de vivacidad — independiente de la plataforma | *** ## Invalidación de la clave al cambiar el registro ### Android Cuando se registra una nueva biometría después de que se creó la clave de firma — por ejemplo, si alguien agrega su propia huella digital a un teléfono robado — la clave se destruye automáticamente en la ruta biométrica fuerte. La `invalidated_on_enrollment_change: true` campo te indica que esta protección está Activa, y `attested: true` te indica que está impuesta por hardware. En la ruta de credencial del dispositivo (`auth_type: ["DEVICE_CREDENTIAL"]`), la clave está protegida por PIN y un cambio de PIN no la destruye. Verifica `auth_type` para comprender qué ruta se utiliza antes de hacer afirmaciones de no repudio. ### iOS La protección equivalente proviene de una marca de control de acceso establecida en la clave de Secure Enclave al momento de su creación. Una clave creada con esta marca se vuelve inaccesible cuando se registra cualquier biometría nueva; Secure Enclave aplica esto localmente. La billetera lo informa automáticamente mediante `invalidated_on_enrollment_change: true`, y `attested: false` te indica que se aplica localmente en lugar de poder verificarse de forma remota. En la ruta de credencial del dispositivo, los cambios de registro no invalidan la clave, en concordancia con el comportamiento de las credenciales de dispositivo de Android. *** ## TEE frente a StrongBox en Android La atestación de claves de Android distingue dos niveles de seguridad de hardware. **TEE (Entorno de ejecución confiable)** es un entorno de ejecución aislado por hardware presente en prácticamente todos los dispositivos Android desde Android 7.0. Se ejecuta en una partición segura del mismo procesador, aplicando la separación de memoria entre el SO Android normal y el mundo seguro donde se administran las claves. TEE tiene una superficie de ataque más amplia que el hardware seguro discreto: existen CVE conocidos para implementaciones específicas de chipsets, y su explotación normalmente requiere que un atacante primero obtenga ejecución de código en el dispositivo. **StrongBox** es un procesador seguro dedicado y resistente a manipulaciones, con su propia CPU, almacenamiento y generador de números aleatorios. No está presente en todos los dispositivos: es común en teléfonos modernos de gama alta, pero está ausente en muchos dispositivos de gama media y económicos. StrongBox es considerablemente más difícil de atacar que TEE porque es hardware físicamente independiente. Ambos se aceptan en los niveles Estándar y Premium. Blerify informa `security_level` para que puedas aplicar tu propia política de aceptación. La mayoría de los casos de uso regulados de verificación de identidad aceptan TEE: explotarlo para omitir la firma de claves protegida por biometría requiere encadenar múltiples vulnerabilidades específicas de chipsets. Si tus requisitos exigen únicamente StrongBox, evalúa `security_level` en la evidencia y aplica tu política en consecuencia. *** ## Dispositivos Android antiguos y `attestation_not_supported` Una pequeña fracción de los dispositivos Android, menos del 1 % de la flota Activa, se lanzó antes de Android 8.0 con módulos de seguridad de hardware anteriores a la atestación de claves. En estos dispositivos, la clave de firma sigue estando en hardware y las protecciones biométricas siguen funcionando, pero Blerify no puede generar la cadena de certificados X.509 que demuestra la residencia en hardware. En este caso, `key_attestation_reason` es `"attestation_not_supported"`. Aceptar o no una clave respaldada por hardware pero no demostrable es una decisión de política. La mayoría de los verificadores la tratan igual que una clave respaldada por hardware comprobada, dada la baja prevalencia y el hecho de que el usuario aún se autenticó con su biometría para autorizar la presentación. *** ## Redactar una política que considere iOS **Acepta iOS sin atestación del dispositivo.** La mayoría de los casos de uso regulados aceptan que iOS no expone un equivalente de Play Integrity para aplicaciones de terceros. La combinación de App Attest en Estándar, que demuestra hardware Apple genuino y una aplicación sin modificar, más la prueba de vida en Premium cubre la mayoría de los flujos de verificación de identidad y apertura de cuentas. Documenta explícitamente la aceptación en tu evaluación de riesgos. **Diferencia `security_level_attested: false` por plataforma.** En iOS, este valor siempre refleja una restricción de la plataforma, no un resultado degradado o sospechoso. Combínalo con una verificación del campo `plataforma` para confirmar que estás viendo el caso esperado de iOS informado automáticamente, en lugar de una anomalía. **Trata `attested: false` de manera diferente de `fallido`.** Una clave de iOS con `attested: false` y una afirmación válida de App Attest es significativamente diferente de una clave cuya atestación no superó la validación. La primera es una limitación conocida de la plataforma; la segunda es una falla de integridad Activa que vale la pena investigar. La lógica de tu política debe tratarlas por separado. **Usa `usuario_denegó` como señal de escalamiento.** Un usuario que rechaza el aviso biométrico o el permiso de cámara ha interrumpido activamente el flujo. Esta es una categoría de riesgo diferente de la de un dispositivo iOS que estructuralmente no puede generar una atestación del dispositivo. Dirige `usuario_denegó` a una cola de revisión, en lugar de tratarlo como equivalente a una ausencia estructural. **Exige prueba de vida para flujos de iOS de alto valor.** Dado que la atestación del dispositivo no está disponible en iOS, `liveness_verification` en Premium es el principal control compensatorio para las transacciones que lo ameriten. Si necesitas el mayor nivel de garantía disponible en iOS, convierte la prueba de vida en un requisito estricto en tu configuración de verificación. **No bloquees por `"platform_not_available"`.** Bloquear a los usuarios de iOS porque la plataforma no puede generar un equivalente de Play Integrity excluiría a una gran proporción de usuarios legítimos sin un beneficio de seguridad correspondiente. Ten en cuenta la limitación, compénsala con prueba de vida cuando el riesgo lo amerite y documenta la brecha residual aceptada. *** ## Lo que aporta la evidencia en capas de iOS En Premium en iOS, la combinación de evidencia en todas las capas respalda un nivel de garantía defendible incluso sin `key_biometric_binding` certificación de hardware y sin atestación del dispositivo. 1. **App Attest** demuestra que la solicitud provino de un dispositivo Apple genuino que ejecuta una instancia sin modificar de la aplicación registrada. Una aplicación modificada o no autorizada no supera App Attest antes de que ocurra cualquier firma. 2. **Clave de Secure Enclave** está configurada por la billetera con invalidación por cambio de registro. La clave está vinculada al conjunto de registros biométricos al momento de crearla y se vuelve inaccesible si ese conjunto cambia. Secure Enclave aplica esto localmente: Apple no proporciona una atestación remota de ello, pero la billetera no tiene ningún mecanismo para omitirlo en un dispositivo genuino y sin modificar. 3. **Verificación de prueba de vida** confirma que la persona físicamente presente es el titular de la credencial al comparar una captura facial en vivo con el retrato incrustado en la presentación de la credencial. La diferencia frente a Android es que la configuración de Secure Enclave se impone mediante el hardware de Apple en lugar de demostrarse con una cadena de certificados verificable. Para la mayoría de los casos de uso regulados, ese es un riesgo residual aceptable. *** ## No repudio y la cadena de vinculación biométrica En el nivel Estándar, la combinación de atestación de claves y vinculación biométrica sustenta un argumento de no repudio: la credencial fue presentada por alguien que tenía el dispositivo, se autenticó con la biometría registrada y cuya clave de firma se habría destruido si alguien hubiera modificado el conjunto de registro biométrico. El argumento es más sólido en Android, donde cada propiedad en `key_biometric_binding` está atestiguada por hardware. En iOS, depende de la aplicación local de Apple de la configuración de Secure Enclave en lugar de una prueba verificable. En la mayoría de las jurisdicciones, esto es suficiente para trasladar la carga de la prueba al titular de la credencial para demostrar que no autorizó la presentación. En Premium en iOS, `liveness_verification` refuerza la cadena al confirmar que la persona que autorizó la presentación estaba físicamente presente y coincidía con el retrato de la credencial. Que esta evidencia constituya un no repudio legalmente suficiente depende de la jurisdicción y del marco regulatorio aplicable. Tu equipo legal debería evaluar la cadena de evidencia frente a tus requisitos específicos. *** ## Próximos pasos **Continúa con** [**niveles de garantía**](/es/introduccion-a-la-verificacion/learn/assurance-tiers.md) — en qué se diferencian Básico, Estándar y Premium, qué demuestra cada uno por plataforma y cómo elegir el nivel adecuado para tu caso de uso. Ver también: [Vinculación biométrica](/es/introduccion-a-la-verificacion/learn/biometric-binding.md) · [Leer un resultado de verificación](/es/introduccion-a-la-verificacion/build/read-a-verification-result.md) · [Referencias de la API](https://dev.blerify.com) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.blerify.com/es/introduccion-a-la-verificacion/learn/platform-attestation.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.