Antes de entrar en el detalle de la puesta en producción, conviene fijar algunas definiciones. Esta página describe cómo se entrega e integra el enfoque de comparación biométrica con cómputo cifrado en un sistema de verificación que ya existe. No es un catálogo de funciones ni una promesa de resultados: es el recorrido operativo desde que el banco decide evaluar la arquitectura hasta que define qué se despliega, dónde vive el cómputo y qué datos conviene no retener.
El banco conserva su captura de imagen o su plantilla en el dispositivo o dentro de su propio perímetro. La plantilla se cifra con la clave pública del esquema y solo el criptograma viaja al servicio de comparación. El motor existente sigue siendo el que decide umbrales y políticas; lo que cambia es que el cálculo ocurre sobre datos que el servicio nunca ve en claro.
Definir dónde se generan las claves, quién custodia la clave privada, cómo se rota y qué ocurre si un nodo de cómputo se reinicia es parte del trabajo de entrega, no un detalle posterior. Si esa custodia queda en manos de un tercero, la garantía de no retención pierde sentido aunque el esquema criptográfico sea correcto.
Medir latencia por operación, costo de CPU por comparación y volumen de tráfico no es opcional. El tamaño de los textos cifrados crece con la profundidad del cálculo, y eso se traduce en hardware, presupuesto de latencia y decisiones sobre qué operaciones conviene mantener cifradas y cuáles no.
El hecho del acuerdo, su alcance, su vigencia y su revocación viven en un registro auditable independiente de la comparación. Mezclar ambos genera dos problemas: se conserva biometría sin necesidad y se pierde la trazabilidad cuando alguien pide explicaciones sobre una verificación concreta.
No se describen certificaciones, clientes, resultados numéricos ni garantías comerciales, porque no forman parte de lo verificable. Tampoco se presenta la entrega como un producto cerrado con condiciones fijas: cada entidad parte de un estado distinto de su sistema de identificación y de sus restricciones regulatorias.
Esta página describe cómo se entrega e integra el enfoque de comparación biométrica con cómputo cifrado en un sistema de identificación que el banco ya opera. Antes de escribir, conviene tener claro qué se está evaluando: si el cómputo vive en infraestructura propia, en una nube privada dedicada o en un modelo híbrido, y quién custodia la clave privada del esquema. Las consultas que llegan con ese contexto se responden con más precisión que las que piden una descripción general.
El canal de correo sirve para plantear dudas sobre rotación de claves, latencia por operación o el registro de consentimiento como evento separado del cálculo biométrico. Adjuntar el diagrama de arquitectura actual ayuda a acotar la respuesta.
support@ltcforher.comPara ordenar un punto puntual del despliegue, como el volumen de tráfico esperado o el comportamiento del nodo de cómputo ante un reinicio. No es una mesa de soporte permanente ni un canal de incidentes en producción.
+54 11 4751-9314Torre Catalinas Norte, Avenida Leandro N. Alem 855, piso 22, Ciudad Autónoma de Buenos Aires, Argentina. Es una dirección de contacto y correspondencia, no un punto de atención al público.
No hay cuentas de usuario, paneles de seguimiento, carga de archivos ni confirmación automática de recepción. El formulario de contacto solo deja constancia técnica del mensaje y no compromete un plazo de respuesta. Si la consulta apunta a entender el enfoque editorial antes de escribir, el recorrido por las preguntas frecuentes suele resolver la mayor parte de las dudas iniciales.
Integrar comparación biométrica con cifrado homomórfico no es reemplazar el motor de identificación que ya opera el banco. Es envolverlo. El recorrido que sigue un equipo de arquitectura o seguridad suele tener cinco tramos reconocibles, y cada uno deja una decisión cerrada antes de pasar al siguiente. Ninguno de estos pasos promete plazos ni resultados: describen qué se define, qué se prueba y qué queda documentado.
Antes de hablar de claves o de cómputo, hay que definir dónde vive la muestra biométrica. La opción habitual es que la captura y la generación de la plantilla ocurran en el dispositivo del cliente o dentro del perímetro del banco, y que el vector en claro nunca salga de ahí. Este paso también fija qué se descarta: la imagen original no se conserva, solo se transmite el criptograma derivado de la plantilla.
El equipo decide qué variante de esquema homomórfico se ajusta al tipo de comparación que necesita, quién genera el par de claves, dónde se custodia la clave privada y con qué política se rota. La clave pública cifra las plantillas; la privada descifra únicamente el resultado de la comparación. Conviene acordar por escrito qué ocurre si un nodo de cómputo se reinicia, si una clave se compromete o si un operador interno necesita auditar el servicio.
El servicio de comparación recibe criptogramas, opera sobre datos cifrados y devuelve un resultado cifrado que el banco descifra localmente. En este tramo se conectan las interfaces con el motor de identificación existente y se separa el registro de consentimiento del cálculo biométrico: son dos flujos distintos, con finalidades y responsables distintos, aunque ocurran en la misma operación.
Un criptograma pesa más que una plantilla en claro y cada operación cifrada consume más CPU que su equivalente sin cifrar. Por eso este paso obliga a medir latencia por operación, costo de cómputo por comparación y volumen de tráfico antes de comprometer un servicio en producción. Los números que salen de aquí son los que definen el dimensionamiento de hardware y el presupuesto de latencia aceptable.
El cierre del recorrido no es técnico, es probatorio. Queda registrado qué se cifra, dónde se descifra, qué no se retiene y cómo se ejerce la revocación del consentimiento. Esa documentación es la que un regulador o una auditoría interna va a pedir cuando pregunte por retención, finalidad y seguridad proporcional. Sin ella, la arquitectura funciona pero no se puede defender.
Cada tramo se apoya en el anterior. Si el perímetro de captura o la custodia de claves quedan ambiguos, los pasos siguientes arrastran esa ambigüedad hasta la auditoría. Vale la pena revisar primero el marco general del enfoque en las soluciones de verificación sin retención y, cuando el equipo ya tenga una arquitectura candidata, contrastarla con los planes de despliegue disponibles.
Puesta en producción
En una integración real, el motor de identificación del banco no se reemplaza: se envuelve. La captura y la plantilla permanecen dentro del perímetro de la entidad, y solo el criptograma sale hacia el servicio de comparación.
El banco conserva su captura de imagen o su plantilla en el dispositivo o en su propia infraestructura. Cifra esa plantilla con la clave pública del esquema y envía únicamente el criptograma al servicio de comparación. El motor existente sigue resolviendo la identificación; lo que cambia es por dónde circula el dato biométrico y qué ve cada componente del recorrido.
Antes de escribir una línea de integración hay que decidir dónde se generan las claves, quién custodia la privada y cómo se rota. La clave privada nunca debería salir del perímetro del banco, porque es la única pieza que permite descifrar el resultado. La rotación obliga a versionar el material criptográfico y a definir qué ocurre con las operaciones en vuelo cuando cambia la clave vigente.
El servicio de comparación opera sin ver la plantilla en claro y devuelve un resultado también cifrado, que el banco descifra localmente. Esto define una frontera clara: el proveedor del cómputo nunca accede al vector biométrico. La contrapartida es que cada operación pesa más que su equivalente en claro, tanto en CPU como en tráfico.
El criptograma es más pesado que una plantilla en claro, y eso se nota en tres métricas concretas: latencia por operación, costo de CPU por comparación y volumen de tráfico entre el banco y el servicio. Conviene medirlas antes de comprometer un nivel de servicio y reservar margen para los picos de verificación diaria.
Un nodo de cómputo que se reinicia no puede perder el estado de las comparaciones en curso. Hay que definir qué se reintenta, qué se descarta y cómo se reconstruye el contexto cifrado sin reintroducir la biometría en claro. Este punto suele quedar fuera del diseño inicial y aparece recién en las primeras pruebas de carga.
La trazabilidad del consentimiento se guarda como un evento separado del cálculo biométrico. El registro prueba cuándo, cómo y para qué se autorizó el tratamiento, pero no necesita conservar la muestra original para hacerlo. Mantener ambos flujos desacoplados simplifica la revocación y reduce la superficie de datos sensibles en el sistema.
Este sitio utiliza cookies para recordar tus preferencias y mejorar la navegación. Puedes aceptar o rechazar su uso. Más información en nuestra política de privacidad.