> 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/biometric-binding.md). # Vinculación biométrica La vinculación biométrica es la cadena de evidencia que conecta a la persona físicamente presente durante una verificación con la persona cuya identidad se verificó cuando se emitió la credencial. Esta página explica qué verifica Blerify en cada nivel de garantía, qué garantiza el hardware seguro, dónde están los límites y cómo la prueba de vida del lado del servidor cierra la brecha que el hardware por sí solo no puede cerrar. *** ## Qué significa en la práctica la vinculación biométrica Cuando alguien presenta una credencial digital, importan tres preguntas: 1. **¿La credencial es auténtica?** ¿Fue emitida por una autoridad de confianza, la firma criptográfica es válida y no ha sido revocada? 2. **¿El presentador controla la credencial?** ¿La clave privada está vinculada a esta credencial en el dispositivo que se está utilizando en este momento? 3. **¿El presentador es el titular de la credencial?** ¿La persona frente a ti es la misma persona a la que se emitió la credencial? {% hint style="info" %} Una autoridad de confianza —el emisor de la credencial— es la entidad que verificó la identidad del titular y firmó la credencial: normalmente una agencia gubernamental, un registro civil o una autoridad nacional de identificación. Esto es independiente del país donde tú, el verificador, operas; un banco de un país puede aceptar una credencial emitida por una autoridad de otro, siempre que ese emisor esté en tu lista de confianza. {% endhint %} La verificación Básico responde la pregunta 1 y confirma la pregunta 2 mediante una prueba de vinculación del titular. Estándar agrega evidencia atestiguada por hardware sobre cómo se protege la clave privada. Premium responde las tres preguntas —incluida la pregunta 3— mediante prueba de vida del lado del servidor y comparación facial. *** ## Cómo funciona la clave del dispositivo Cada credencial en la Blerify billetera está vinculada a una clave privada almacenada en el hardware seguro del teléfono: Secure Enclave en iOS, StrongBox o un Entorno de Ejecución Confiable (TEE) en Android. La clave nunca sale de ese hardware. La billetera nunca la conserva en software. La clave se configura con dos restricciones en el momento de su creación. **Autenticación obligatoria en cada uso.** La clave solo puede activarse después de que el usuario se autentique con un método biométrico o una credencial del dispositivo (PIN, patrón o contraseña). Ninguna app puede activar una operación de firma silenciosamente en segundo plano: cada presentación requiere un desbloqueo activo, sin ventana de almacenamiento en caché. **Invalidación ante cambios en el registro biométrico.** Si alguien registra un nuevo dato biométrico en el dispositivo después de crear la clave, la clave se destruye automáticamente. Una persona que agrega su propia huella digital a un teléfono robado no puede usar la credencial: la clave ya no existe y el titular legítimo tendría que realizar un nuevo registro completo —incluida la verificación de identidad— para obtener una nueva. La billetera selecciona el factor de autenticación según lo que admita el dispositivo. En dispositivos con un sensor biométrico robusto registrado, la clave está restringida por biometría y configurada para invalidarse si se agregan nuevos datos biométricos. En dispositivos sin biometría robusta, la clave recurre a la credencial del dispositivo, aplicada a nivel de hardware. En ambos casos, la clave de firma siempre está respaldada por hardware. La billetera rechaza el registro en cualquier dispositivo que carezca de almacenamiento seguro respaldado por hardware o que no tenga configurado un bloqueo de pantalla. Cuando una billetera presenta una credencial, realiza una operación de firma mediante esta clave. La prueba de vinculación del titular resultante demuestra dos cosas: que el presentador posee el dispositivo específico al que se vinculó la credencial en el momento de la emisión y que pudo desbloquear su hardware seguro. *** ## Qué verifica cada nivel de garantía ### Básico Blerify valida la firma criptográfica de la credencial, la verifica contra el registro de revocación del emisor, comprueba que el emisor esté en tu lista de confianza configurada y confirma que el presentador completó un desafío de autenticación del dispositivo que demuestra que posee la clave de firma de la credencial. Un resultado Básico satisfactorio te indica que la credencial es válida y que el presentador controla una clave de dispositivo vinculada a ella. No te indica nada sobre cómo se almacena esa clave ni qué se requiere para desbloquearla. Básico también es el nivel efectivo para presentaciones provenientes de billeteras de terceros. Esas billeteras pueden operar internamente con un nivel de seguridad superior, pero sin evidencia atestiguada por hardware en la presentación, esto no puede confirmarse. La garantía que informa Blerify refleja lo que el verificador puede comprobar de forma independiente, no lo que la billetera pueda hacer internamente. Básico es adecuado para operaciones donde el costo de una respuesta incorrecta es bajo: verificaciones de edad, control de acceso y consultas de identidad de bajo valor. ### Estándar Estándar amplía Básico con atestación de clave. La billetera envía una cadena de certificados —firmada por la raíz de hardware de Google o Apple— junto con la presentación. Blerify valida esa cadena para confirmar: * La clave de firma reside en hardware resistente a manipulaciones (StrongBox, TEE o Secure Enclave), no en software. * La clave requiere autenticación del usuario para cada operación de firma, sin ventana de almacenamiento en caché. * La clave está configurada para destruirse si alguien agrega un nuevo dato biométrico al dispositivo después de la emisión. Esta información aparece en los `key_attestation` y `key_biometric_binding` campos del resultado de la verificación. En Android, estos campos están firmados directamente por el TEE o StrongBox y se pueden verificar contra las raíces de certificados de atestación de hardware de Google; la app de billetera no puede falsificarlos. En iOS, la API de atestación de Apple confirma que la app y el dispositivo son auténticos, pero no incluye los indicadores de control de acceso de la clave, por lo que `key_biometric_binding.attested` será `false` en los resultados de iOS. Secure Enclave sigue aplicando localmente el requisito biométrico; simplemente no se puede atestiguar de forma remota mediante la API actual de Apple. [Atestación de plataforma](/es/introduccion-a-la-verificacion/learn/platform-attestation.md) cubre estas diferencias en detalle. Estándar también incluye evidencia de auditoría firmada: direcciones IP observadas en el momento de la presentación, geolocalización aproximada derivada del lado del servidor, modelo del dispositivo y versión del SO, y un `signed_evidence` JWT que puedes conservar para tus propios registros de cumplimiento. Ese JWT está firmado por Blerify y cualquier tercero puede verificarlo con la clave pública de Blerify —sin contactar a Blerify— mediante el endpoint JWKS descrito en [Referencias de la API](https://dev.blerify.com). Estándar no demuestra que la persona que presenta sea el titular de la credencial. Demuestra que está presentando quien posee el teléfono y puede desbloquear su sensor biométrico. Esta distinción importa para operaciones de alto valor. Estándar es adecuado para apertura de cuentas, KYC, banca habitual y acceso a servicios gubernamentales. ### Premium Premium agrega verificación de prueba de vida del lado del servidor a todo lo que proporciona Estándar. La billetera captura una breve sesión de cámara durante la presentación. Blerify procesa esa sesión mediante: * Una comprobación contra suplantación que detecta fotos, videos, máscaras 3D e imágenes deepfake. * Una comparación facial con el retrato incorporado en la credencial: la foto que la autoridad emisora colocó en la credencial en el momento de la emisión. Un resultado Premium satisfactorio significa que la persona frente a la cámara era un ser humano vivo cuyo rostro coincide con alta confianza con el retrato de la credencial. Combinado con la atestación de clave de Estándar, esto cierra la brecha que Estándar no puede abordar por sí solo: tienes evidencia independiente, producida por el servidor, de que el presentador es el titular de la credencial. Premium también incluye atestación del dispositivo. En Android, Play Integrity proporciona veredictos explícitos sobre si el dispositivo ha sido rooteado, el cargador de arranque ha sido manipulado o la app ha sido modificada. En iOS, no hay una API equivalente disponible para apps de terceros; `device_attestation` será `null` con `_reason: "platform_not_available"` en los resultados Premium de iOS. La prueba de vida y la comparación facial se ejecutan de forma idéntica en ambas plataformas. La selfie capturada para la prueba de vida nunca se almacena. Blerify la procesa para la comparación y la elimina inmediatamente. Solo se conservan el resultado booleano y una puntuación de confianza en el registro de verificación. Tu backend nunca recibe datos biométricos sin procesar. Premium es adecuado para solicitudes de préstamos, contratos de alto valor, procedimientos legales y cualquier operación en la que confirmar la presencia física justifique el paso adicional para el usuario. *** ## La brecha de vinculación biométrica y por qué existe El nivel Estándar demuestra que la clave de firma está en hardware y configurada para requerir autenticación biométrica. No demuestra que los datos biométricos registrados en el dispositivo pertenezcan al titular de la credencial. Si el dato biométrico de otra persona se registró en el dispositivo antes de emitir la credencial, esa persona puede desbloquear la clave. El mecanismo de invalidación ante cambios en el registro no cubre este caso: solo detecta los datos biométricos agregados *después* después de la creación de la clave. Esta no es una limitación específica de Blerify. iOS y Android deliberadamente no exponen datos de plantillas biométricas a las aplicaciones. No existe una API de plataforma que permita a una billetera verificar de quién son los datos biométricos registrados en un dispositivo. Cualquier billetera que delegue la autenticación biométrica al SO enfrenta la misma restricción: las passkeys, las apps de banca móvil y el inicio de sesión del dispositivo comparten este diseño. Para Básico y Estándar, esta brecha se acepta como coherente con el funcionamiento de la autenticación basada en dispositivos en toda la industria. Para operaciones donde importa la presencia física, usa Premium: la comparación facial del lado del servidor con el retrato de la credencial cierra la brecha en el momento de la verificación, independientemente de lo que esté registrado en el dispositivo. *** ## Por qué usar prueba de vida del lado del servidor en lugar de comparación facial en el dispositivo Una comparación facial en el dispositivo añadiría complejidad sin proporcionar lo que Premium está diseñado para ofrecer: evidencia independiente y auditable de un servidor fuera del control del titular. Un resultado producido por completo en el dispositivo del usuario —incluso en un dispositivo certificado con código atestiguado por hardware— es una declaración del propio equipo del titular. Cuando se impugna una transacción, la evidencia del teléfono del titular tiene menos peso que la evidencia de un servidor independiente. Las instituciones financieras que actualmente usan comparación facial para operaciones de alto riesgo —solicitudes de préstamos, registro de nuevos dispositivos, firma de contratos de alto valor— dirigen a los usuarios a través de un paso de verificación del lado del servidor precisamente por esta razón. La prueba de vida del lado del servidor también proporciona una protección contra suplantación más sólida. Las comprobaciones pasivas en el dispositivo detectan ataques casuales: impresiones de fotos y reproducción simple de videos. El procesamiento del lado del servidor mediante mapeo facial 3D y análisis temporal de video detecta ataques sofisticados: deepfakes, máscaras impresas en 3D y reproducción de video de alta fidelidad. La atestación del dispositivo confirma que la app es auténtica y no ha sido modificada, pero no puede confirmar que lo que ve la cámara sea una persona real. Esa confirmación requiere análisis del lado del servidor. El resultado combinado —la atestación del dispositivo que confirma el entorno, más la prueba de vida del lado del servidor que confirma la presencia física— te proporciona evidencia auditable de forma independiente que no requiere enviar datos biométricos a una base de datos centralizada. *** ## Sin almacenamiento biométrico El modelo de prueba de vida de Blerify es estructuralmente diferente de los servicios tradicionales de verificación de identidad. Los proveedores tradicionales suelen almacenar una imagen facial o una representación matemática de ella. Se convierten en custodios de datos biométricos sujetos a obligaciones estrictas conforme al RGPD y leyes equivalentes. Si su infraestructura sufre una vulneración, quedan expuestos los datos biométricos de todos los usuarios que hayan verificado alguna vez y, a diferencia de las contraseñas, los rostros no se pueden cambiar. El modelo de Blerify elimina este riesgo por diseño. La credencial emitida por una autoridad gubernamental ya contiene el retrato del titular, firmado por el emisor. Blerify no almacena una foto de referencia. Cuando se ejecuta la verificación Premium: 1. El retrato se extrae de la credencial firmada durante la validación. Como viaja dentro de la credencial firmada, cualquier manipulación habría invalidado la firma del emisor antes de este paso. 2. La billetera captura una breve sesión de prueba de vida y la envía a Blerify. 3. Blerify compara la sesión con el retrato y elimina ambos inmediatamente después de la comparación. 4. El único artefacto que se conserva es el resultado booleano y una puntuación de confianza. Tu backend recibe el resultado. Nunca recibe una imagen facial, una plantilla ni ningún dato biométrico. Blerify nunca crea una base de datos facial. La consecuencia práctica es que una vulneración de la infraestructura de verificación de Blerify expondría resultados booleanos ("credencial verificada en el momento Y con confianza de 0.97"), pero ningún dato biométrico, porque no hay ninguno que encontrar. *** ## Qué necesitan las credenciales para Premium Premium requiere un campo de retrato en la credencial. Sin él, Blerify no tiene una imagen de referencia con la que comparar y no puede realizar la verificación de prueba de vida. **Credenciales mDoc ISO 18013** siempre contienen un `retrato` en el espacio de nombres Estándar. Este es un elemento obligatorio de la especificación ISO 18013-5. **Credenciales W3C y credenciales SD-JWT** pueden incluir o no una foto, según el emisor. Si la declaración de foto se revela selectivamente y el titular no la revela, la prueba de vida no puede continuar. Cuando se solicita Premium pero la credencial no contiene un retrato utilizable, Blerify limita el resultado a Estándar e incluye `"liveness_not_possible": "credential_has_no_photo_claim"` en la response. Tú decides en tu propia lógica si Estándar es aceptable para esa operación. La calidad de la foto también importa. El motor de comparación facial necesita que el rostro sea reconocible con una resolución razonable. El emisor controla la calidad del retrato en el momento de la emisión; cuando una presentación llega a Blerify, la comparación se ejecuta con lo que el emisor haya codificado. Los retratos muy comprimidos, las regiones faciales muy pequeñas o las imágenes con reflejos u oclusiones significativos reducirán la confianza de la coincidencia. *** ## No repudio y evidencia de auditoría El nivel Estándar genera una cadena de no repudio. Si un titular posteriormente impugna haber autorizado una acción, la evidencia de atestación de hardware aborda cada argumento común: | Argumento del titular | Por qué no es válido | | ------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | "Alguien copió mi clave" | La clave reside en hardware resistente a manipulaciones y no puede extraerse mediante software. La atestación de clave lo demuestra criptográficamente. | | "Alguien usó mi clave sin mi consentimiento" | Cada operación de firma requiere autenticación aplicada por hardware sin ventana de reutilización. | | "Alguien registró su dato biométrico en mi dispositivo" | Si se agregó un nuevo dato biométrico después de la creación de la clave, la clave se destruyó automáticamente. La presentación no pudo haber ocurrido. | | "La evidencia de auditoría fue fabricada" | El `signed_evidence` JWT está firmado por Blerify y cualquier auditor puede verificarlo de forma independiente con la clave pública de Blerify. No puede modificarse después de la emisión. | Para Premium, el registro de prueba de vida agrega que la persona físicamente presente coincidió con el retrato de la credencial, lo que fortalece aún más la cadena para operaciones que requieren evidencia de presencia física. Blerify firma el `signed_evidence` JWT, pero no lo conserva después de que expire la sesión. Tú eres el custodio del registro de auditoría: almacénalo conforme a tus propios requisitos de conservación. *** ## Detección de coacción Premium incluye una señal adicional: análisis de patrones de mirada y microexpresiones faciales capturados durante la sesión de prueba de vida. Esto se ejecuta silenciosamente junto con la comparación facial; el usuario solo ve el desafío de prueba de vida Estándar y un posible coaccionador ve lo mismo. Si el análisis detecta una anomalía —mirada sostenida hacia un punto fijo fuera de cámara o expresiones de estrés involuntarias— el `coercion_check` campo del resultado de la verificación tendrá un estado distinto de claro. El flujo de verificación nunca se interrumpe ante una señal de coacción. Blerify informa la señal; tú decides cómo responder según tus propias políticas de riesgo. Interrumpir el flujo ante una detección de coacción revelaría al coaccionador que se activó una señal, lo que podría aumentar el peligro. La detección de coacción es exclusiva de Premium. Las API biométricas de plataforma tanto en iOS como en Android deliberadamente no exponen qué plantilla biométrica coincidió. Esto hace imposible implementar una señal de dedo bajo coacción en el nivel Estándar. La sesión de prueba de vida basada en cámara en Premium permite el análisis de mirada y expresiones que el flujo Estándar estructuralmente no puede admitir. *** ## Contexto regulatorio Los nombres de nivel de Blerify —Básico, Estándar, Premium— son definiciones específicas de Blerify. No son certificaciones formales de equivalencia con eIDAS o NIST. **Básico** está por debajo de eIDAS Substantial y NIST AAL2. Establece la posesión de un solo factor de la clave de firma de la credencial sin atestación de cómo se protege esa clave. **Estándar** se alinea informalmente con eIDAS Substantial y NIST AAL2: dos factores de categorías diferentes (posesión e inherencia), con la clave de firma en hardware resistente a manipulaciones. Los componentes individuales de seguridad de hardware en teléfonos de consumo suelen contar con certificaciones de seguridad relevantes, pero actualmente ningún dispositivo final de consumo posee las certificaciones requeridas por una interpretación estricta de eIDAS High o NIST AAL3 a nivel de todo el dispositivo. Esta es una limitación de toda la industria para los despliegues de billeteras móviles, no específica de Blerify. **Premium** supera lo que eIDAS, NIST, PSD2 o los reguladores bancarios de la mayoría de las jurisdicciones exigen para la autenticación por transacción. La prueba de vida y la comparación facial del lado del servidor son controles diseñados para operaciones en las que se justifica volver a verificar la identidad en un punto específico de fricción: apertura de cuentas, solicitudes de préstamos y registro de dispositivos de alto riesgo. Ni eIDAS ni NIST requieren que los datos biométricos registrados en un dispositivo pertenezcan al titular de la credencial. Ambos marcos asumen que el propietario del dispositivo registró sus propios datos biométricos. El Marco de Referencia de Arquitectura de la Billetera de Identidad Digital de la UE (EUDIW ARF) va más allá y exige que el registro biométrico esté vinculado a la verificación de identidad. La hoja de ruta de Blerify está alineada con esta dirección. Para consultar el mapeo informativo detallado entre los niveles de Blerify y los niveles de eIDAS/NIST —incluidas las brechas de certificación específicas que impiden la equivalencia formal— consulta [niveles de garantía](/es/introduccion-a-la-verificacion/learn/assurance-tiers.md). *** ## Próximos pasos **Continúa con** [**Atestación de plataforma**](/es/introduccion-a-la-verificacion/learn/platform-attestation.md) — cómo Android e iOS producen diferentes formas de evidencia en el resultado de la verificación y cómo escribir una política de riesgo que tenga en cuenta la asimetría de atestación de iOS. Ver también: [niveles de garantía](/es/introduccion-a-la-verificacion/learn/assurance-tiers.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/biometric-binding.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.