En el mercado español hay decenas de soluciones que se anuncian como firma electrónica avanzada. Algunas lo son. Bastantes se quedan a las puertas sin saberlo. Y la diferencia no está en la robustez del sistema ni en la cantidad de evidencias que recoge, sino en un detalle que casi nunca aparece en la documentación comercial: quién es el dueño de la llave con la que se firma.
Este artículo explica ese punto sin criptografía, y explica también cómo lo verificamos en nuestras auditorías de firma remota avanzada para prestadores de servicios de confianza.
Dos formas de guardar un secreto
Imagine una contraseña, un PIN o un código de un solo uso enviado por SMS. Son una llave de la que existen dos copias: la del usuario y la de la plataforma. La plataforma necesita su copia para poder comprobar que la del usuario es correcta. Y precisamente porque la tiene, también puede abrir la puerta ella sola.
Ahora imagine otro esquema. El firmante se queda con una llave y entrega a la plataforma un candado abierto. La plataforma puede cerrar el candado y comprobar si una llave lo abre, pero con el candado en la mano no puede fabricar la llave. Verificar no la habilita para generar.
Esa es toda la diferencia. Y de ella depende que un sistema sea o no firma electrónica avanzada.
Qué exige realmente el artículo 26
El Reglamento eIDAS pide cuatro cosas a una firma avanzada: que esté vinculada al firmante de manera única, que permita identificarlo, que se cree con datos de creación de firma que el firmante utilice bajo su control exclusivo, y que permita detectar alteraciones posteriores.
El primer, segundo y cuarto requisito los resuelve bien cualquier plataforma seria: un procedimiento documentado de verificación de identidad en el alta, y un sellado con sello de tiempo cualificado sobre el documento.
El tercero es donde se cae la mayoría. Y es un requisito de arquitectura, no de procedimiento: por robusto que sea el proceso de autenticación, si la firma que queda incorporada al documento la produce una clave de la plataforma, los datos de creación de firma no están bajo control del firmante. Están bajo control de quien opera el servicio.
Conviene decirlo con precisión porque suele malinterpretarse: no es que la firma avanzada sea débil en esos casos. Es que, en sentido estricto, no hay firma del firmante. Hay un sello de la plataforma sobre un expediente de evidencias que la propia plataforma ha escrito.
Por qué esto importa en la práctica
Frente a un atacante externo, un sistema con verificación de identidad y doble factor es difícil de burlar, y la mayoría de plataformas del mercado lo son. El problema aparece en el escenario que de verdad se plantea en un juicio: el firmante niega la autoría y hay que acreditar que nadie más pudo haber generado ese documento, incluida la propia plataforma.
Con clave de la plataforma, la respuesta es «nuestros controles internos lo impedían». Se prueba con política, auditoría y testimonio. Es una garantía organizativa.
Con clave del firmante, la respuesta es «técnicamente no pudimos». La plataforma queda fuera del conjunto de posibles autores por construcción. Es una garantía estructural.
En contradicción pericial, esa distinción decide el asunto.
Las passkeys: la llave que la plataforma nunca tiene
Aquí es donde entra una tecnología que ya está en el bolsillo de casi todo el mundo. Las passkeys, definidas en el estándar WebAuthn, permiten que el dispositivo del firmante genere y guarde una llave en su chip de seguridad, sin que esa llave salga nunca de ahí ni pueda exportarse como fichero.
Cómo funciona, desde el punto de vista del firmante:
- En el alta, tras la verificación de identidad, su móvil le pide la huella. Se crea el par llave-candado. La plataforma se queda solo con el candado.
- Al firmar, el móvil le vuelve a pedir la huella o el reconocimiento facial. La firma se produce dentro del chip.
Son dos gestos biométricos. Menos trabajo que teclear un código de seis dígitos. No instala aplicaciones, no gestiona certificados, no necesita saber que existe una llave.
Y desde el punto de vista de la plataforma: sin certificados, sin infraestructura de clave pública propia, sin coste por firma y sin cuotas de terceros. Es un estándar abierto, con librerías maduras, que funciona en el navegador.
Si el firmante trabaja desde ordenador, el propio estándar contempla un flujo entre dispositivos: el PC muestra un código QR, el firmante lo escanea con el móvil y la firma se produce en el teléfono. La llave no se copia a ninguna parte.
El modelo que recomendamos: dos capas que hacen cosas distintas
Aquí está el punto que más se malinterpreta en los proyectos que revisamos, y merece detenerse.
La passkey no sustituye al sellado centralizado del prestador. Las dos capas conviven y responden a preguntas diferentes:
La firma del firmante, en su dispositivo, responde a quién consintió. Es la que aporta el control exclusivo y la que sostiene la autoría frente a una impugnación.
El sello del prestador, centralizado, responde a qué recogió el sistema y que no se ha alterado. Autentica el origen y la integridad del expediente completo: la traza de identificación, los metadatos de sesión, el documento, la propia firma del usuario. Es la capa que da consistencia probatoria al conjunto y la que permite conservarlo a largo plazo.
El sello de tiempo cualificado fija el momento y aporta la presunción de exactitud temporal e integridad del artículo 41.2 de eIDAS.
El error habitual es pensar que hay que elegir. No hay que elegir: el sellado centralizado es una fortaleza de la arquitectura y debe mantenerse. Lo que hay que añadir es la pieza del firmante, que es la que hoy suele faltar. El cambio es de un solo elemento y no obliga a rediseñar nada de lo ya construido.
Cómo lo auditamos
Nuestra lista de controles para firma remota avanzada se organiza en cinco bloques. No es una revisión documental: verificamos comportamiento real del sistema, con pruebas sobre el flujo de firma y análisis de los artefactos que produce.
1. Identificación del firmante en el alta. Que exista verificación real contra fuente auténtica y no autodeclaración en un formulario. Contrastamos el procedimiento con las exigencias de nivel sustancial del Reglamento de Ejecución (UE) 2015/1502 y con la especificación técnica de identity proofing aplicable, y comprobamos que la vinculación entre la identidad verificada y la credencial queda registrada y conservada.
2. Control exclusivo de los datos de creación de firma. El bloque decisivo. Dónde se genera la llave, si puede salir del dispositivo, quién puede activarla, y si el operador del servicio conserva alguna capacidad de firmar por el usuario. Cuando la custodia es remota, verificamos el mecanismo de activación contra CEN EN 419 241 y el nivel de garantía declarado. Cuando la llave está en el dispositivo, comprobamos qué tipo de autenticador la produjo y si esa información queda registrada en cada firma.
3. Vinculación entre la firma y el documento. Aquí aparecen la mayoría de hallazgos serios. Que lo que el firmante autoriza sea efectivamente el documento que se le muestra, y no un reto de autenticación genérico. Que exista trazabilidad entre lo visualizado y lo firmado. Es el punto donde una implementación descuidada convierte una buena arquitectura en una evidencia atacable.
4. Integridad, sellado y anclaje temporal. El sello del prestador, el sello de tiempo cualificado, el encadenamiento de registros, la separación de funciones entre quien administra la aplicación y quien puede invocar el módulo de sellado, y la conservación en soporte inalterable en un tercero. Verificamos que el anclaje temporal externo se produzca próximo al evento y no solo al cerrar el expediente.
5. Conservación y verificabilidad futura. El control que casi nadie tiene resuelto. Un expediente impugnado a los cinco años debe poder verificarse entonces, y eso exige haber conservado todo lo necesario para reconstruir la verificación. Contrastamos el diseño con la validación conforme a ETSI EN 319 102-1 y con las especificaciones de conservación con evidencias.
A ello se añade el marco general del prestador: los requisitos de ETSI EN 319 401, las obligaciones de la Ley 6/2020 para el prestador no cualificado, incluida la comunicación de inicio de actividad al órgano de supervisión, y el análisis de si alguna funcionalidad del producto constituye por sí misma un servicio de confianza que su titular no había identificado como tal.
Qué entregamos
Un informe con los hallazgos clasificados por severidad y, para cada uno, la corrección concreta y su coste estimado. La calificación técnica precisa de la firma que produce el sistema, con el razonamiento que la sostiene. Y, cuando el resultado no alcanza la firma avanzada, la especificación del camino más corto para llegar, que en la mayoría de casos es más barato de lo que el cliente esperaba.
Trabajamos también la fase previa: revisión de arquitectura antes de construir, que es siempre más económica que corregir sobre un sistema en producción y con contratos ya firmados.
Y trabajamos el otro extremo: el peritaje cuando la firma ya ha sido impugnada. Es la razón de fondo de que nuestra lista de controles tenga la forma que tiene. Está construida desde la pregunta que se hace en sala, no desde el índice de una norma.
Por qué este punto pesa más ahora
Durante años la interpretación laxa del control exclusivo no ha tenido consecuencias. No existe supervisión previa de la etiqueta «firma avanzada» y el riesgo solo se materializaba en litigio.
Eso está cambiando. La reforma de eIDAS ha ampliado el catálogo de servicios de confianza y ha elevado el nivel de exigencia técnica sobre la firma remota, con desarrollo reglamentario todavía en curso. El Cyber Resilience Act somete a las plataformas a obligaciones de ciberseguridad y notificación con plazos ya vencidos para la parte de notificación. Y el despliegue de la cartera europea de identidad digital pondrá la firma cualificada al alcance de cualquier ciudadano sin coste: cuando eso ocurra, seguir comercializando como avanzada una firma construida sobre credenciales quedará visiblemente por detrás de lo que el usuario tendrá de serie.
La ventana para hacer el ajuste con calma es ahora, mientras es una decisión de diseño y no una corrección forzada.
Una nota de honestidad profesional
Dos cosas que decimos siempre a nuestros clientes y que conviene decir también aquí.
La primera: la interpretación del control exclusivo en esquemas de firma remota no es unánime. Parte del sector sostiene una lectura más extensiva, según la cual las credenciales del firmante constituirían sus datos de creación de firma. No la compartimos, y explicamos por qué en cada informe, pero no es una posición marginal y no consta resolución española que la haya rechazado expresamente. Un asesor que le presente esto como cuestión cerrada le está dando una imagen incompleta.
La segunda: el uso de WebAuthn como mecanismo de firma, y no solo de autenticación, es un terreno donde la doctrina no está consolidada, en particular respecto de cómo se acredita el vínculo entre lo que el firmante ve y lo que su dispositivo firma. Es sensiblemente más defendible que una firma construida sobre credenciales, pero exige implementarlo y documentarlo con cuidado. Ese cuidado es, precisamente, buena parte de nuestro trabajo.
