Cómo protegemos los certificados de tus clientes

gestiOne guarda en la nube los certificados digitales de los clientes de una gestoría de forma que solo la propia gestoría puede abrirlos. Ni nosotros, ni el proveedor del servidor, ni quien robara una copia de la base de datos puede ver una clave privada. Aquí está cómo, con los algoritmos y también con lo que el modelo no cubre.

En resumen

• El certificado se sube desde el equipo del empleado y se cifra antes de salir hacia Internet.
• La llave de la caja fuerte es el DNIe o el certificado FNMT de cada empleado. No hay contraseñas nuevas que recordar ni que robar.
• La gestoría decide quién tiene acceso y a qué clientes, y puede retirarlo en cualquier momento.
• Cada acceso queda en un registro de auditoría encadenado, que delata cualquier cambio.
• Las notificaciones de DEHú se cifran en la oficina de la gestoría, con una clave distinta de la de la caja fuerte, antes de subirlas.
• No existe ninguna clave maestra del operador: no hay puerta trasera.

Conocimiento cero, en una imagen

Imagina una caja fuerte acorazada. La única llave que la abre se fabrica en el ordenador de tu empleado, a partir de su DNIe o su certificado FNMT, cada vez que la necesita, y se destruye al terminar. Nosotros guardamos la caja, pero nunca vemos la llave ni el contenido: si alguien nos robara el almacén entero, se llevaría cajas cerradas que no puede abrir.

«Conocimiento cero» (zero-knowledge) significa eso: la plataforma funciona sin conocer nunca los secretos que custodia. No es una promesa de buen comportamiento, sino una consecuencia de cómo se cifran los datos.

Qué guarda la nube y quién puede abrirlo

Lo que la API no recibe nunca: la contraseña del .pfx, ninguna clave privada en claro, ninguna DEK en claro, la clave de la caja fuerte ni la firma de la que se saca la llave de cada empleado.

El operador de la plataforma no tiene ningún permiso dentro de una gestoría: no ve sus clientes, empleados, certificados ni su auditoría. Sus propias acciones quedan en una auditoría de plataforma aparte.

Qué pasa al subir un certificado

Cuando un empleado sube el .pfx o .p12 de un cliente, todo pasa en su equipo antes de que nada salga hacia Internet:

1. Se abre el fichero con su contraseña, que no se envía ni se guarda, y se comprueba que la clave privada corresponde al certificado.
2. Se descarga el manifiesto de la caja fuerte de la gestoría y se verifica su firma: lo firmó un administrador con su DNIe o FNMT, y su cadena tiene que llegar a las autoridades de certificación oficiales. Se enseña la huella de la caja fuerte, para poder compararla.
3. Se genera una clave de datos (DEK) aleatoria de 256 bits, solo para ese certificado.
4. Se cifra la clave privada con la DEK, con AES-256-GCM, atada a la gestoría y al certificado: copiada a otra gestoría u otro certificado, no se descifra.
5. Se sella la DEK para la clave pública de la caja fuerte con HPKE (RFC 9180).
6. Se borran de la memoria la DEK y la clave privada, y a la API solo le llegan el cifrado, la DEK sellada y el certificado público con su cadena.

La llave es el certificado del empleado, no una contraseña

gestiOne no saca ninguna clave de una contraseña. La clave que abre el acceso de cada empleado se obtiene de su certificado cualificado (DNIe o FNMT), que solo él puede usar, con su tarjeta y su PIN o con su almacén de certificados:

• Certificados RSA (el DNIe y los FNMT actuales): su equipo firma un reto fijo con RSA PKCS#1 v1.5 y SHA-256. Esa firma es siempre la misma para el mismo mensaje y la misma clave; antes de usarla se verifica con la clave pública del certificado, y de ella sale la clave con HKDF-SHA256.
• Certificados de curva elíptica (la nueva jerarquía de la FNMT): un acuerdo ECDH entre la clave del certificado y una clave efímera del alta, y HKDF-SHA256 sobre el secreto común.
• Una sal aleatoria de 256 bits por clave impide calcular el reto con datos públicos.
• La firma (o el secreto ECDH) es el secreto: no se guarda, no se envía ni se registra, y se borra de la memoria en cuanto se usa.

No hay nada que adivinar ni ataques de diccionario posibles, y el acceso queda atado a algo que la persona ya custodia por ley.

Algoritmos

Todos son estándares públicos, sin negociación ni variantes: la combinación está fija en el código y versionada, con vectores de prueba compartidos por todos sus componentes.

Aunque el servidor mintiera

• Firmas con propósito. Los equipos de los empleados nunca firman lo que les mande el servidor tal cual: cada firma va sobre un mensaje que se construye en local y empieza por una etiqueta fija de lo que es. Un servidor comprometido no puede hacer que un empleado firme el reto de su llave.
• Sin vuelta atrás. Cada equipo recuerda la última versión del manifiesto que verificó, y rechaza una anterior o la misma con otra huella.
• Nadie se cuela. Para que alguien abra la caja fuerte, un administrador tiene que aprobarlo en su app de escritorio, verificando la firma y la cadena de su certificado. La nube no puede añadir una clave propia.
• Sin puerta trasera. La clave de la caja fuerte se genera en la app del primer administrador. El kit de recuperación en papel lo guarda la gestoría y, para usarlo, hay que demostrar además que se ha abierto la caja. Si se perdieran a la vez los certificados de todos los administradores y el kit, nadie, tampoco nosotros, podría recuperar la caja: por eso recomendamos tener siempre dos administradores.

La conexión

TLS 1.2 sigue admitido porque en TLS 1.3 el navegador firma con RSA-PSS, y el DNIe no lo hace: exigir solo 1.3 dejaría fuera a quien entra con DNIe. Las suites de 1.2 admitidas tienen todas secreto perfecto hacia adelante y cifrado autenticado.

Quién accede a qué

No hay usuarios ni contraseñas: se entra con DNIe o FNMT. Nadie se da de alta solo: un administrador crea a cada empleado, y para usar la caja fuerte ese empleado genera en su equipo su clave de usuario, la firma con su certificado y un administrador la aprueba.

Los clientes se organizan en grupos, y cada empleado solo ve los de sus grupos. Precisión: la caja fuerte tiene una clave por gestoría, y el reparto por grupos lo aplica la API, que solo entrega los cifrados que el empleado puede ver. Es control de acceso, no criptografía: protege frente a un empleado, no frente a un servidor comprometido que además tuviera el acceso de un empleado. Cada lectura de un secreto queda en la auditoría.

Cuando alguien deja el despacho

1. Un administrador le da de baja: sus certificados dejan de servir para entrar y sus claves de usuario quedan revocadas. Como cada petición vuelve a comprobar el certificado, no hay sesiones que caduquen más tarde: la siguiente se rechaza.
2. Después se renueva la caja fuerte desde la app de escritorio: clave nueva, todas las DEK selladas de nuevo y los accesos antiguos borrados. Ninguna clave que esa persona hubiera guardado abre ya nada de lo que guarda la nube.

La baja corta el acceso futuro. Lo que alguien hubiera copiado fuera del sistema mientras tenía permiso no se puede borrar a distancia: en ese caso, lo definitivo es revocar el certificado del cliente ante su emisor y subir uno nuevo. La auditoría dice qué leyó y cuándo.

Registro de cada uso

Cada operación queda en un registro encadenado por gestoría: fecha y hora, quién (con la huella del certificado con el que entró), qué, sobre qué y desde qué IP. Se registran las altas, bajas y cambios; cada subida, cambio y retirada de certificados; cada lectura del secreto de un certificado; y cada acceso pedido, aprobado o retirado, cada renovación y cada recuperación de la caja fuerte.

Cada entrada lleva el hash SHA-256 de la anterior: cambiar, borrar o reordenar una rompe la cadena, y la verificación dice dónde. La API solo puede añadir y leer en la auditoría, cada copia de seguridad comprueba la cadena contra la anterior y hay un verificador independiente para el auditor.

El agente de tu oficina

El agente de gestiOne es un programa que trabaja solo, día y noche, en un ordenador de tu oficina: consulta DEHú por tus clientes, descarga lo que se acepta, lo cifra antes de subirlo y avisa por correo de lo que vence.

• Un ordenador encendido las 24 horas. Mejor uno dedicado, como un pequeño servidor o un equipo que solo haga esto, que el puesto de trabajo de alguien: así nadie lo usa para navegar ni abrir correos, y no se apaga al final del día. En Windows o Linux.
• Con su propia llave. Al instalarlo, el agente crea su llave en el chip de seguridad (TPM) de ese ordenador, de donde no se puede copiar ni sacar. Si el equipo no tiene TPM, la llave queda protegida por el sistema y la consola lo marca como «sin protección de hardware».
• Lo aprueba tu gestoría. Un administrador lo da de alta desde su app comparando su huella y lo aprueba con su firma, igual que a un empleado. Se puede retirar al momento, y a partir de ahí no sirve para nada.
• Lo justo. Para trabajar sin nadie delante, el agente puede abrir la caja fuerte, pero la nube solo le entrega el certificado con el que tu gestoría se identifica ante DEHú. Cada cosa que hace queda en la auditoría.

Su seguridad depende de quién tenga acceso a ese ordenador. La llave en el TPM impide copiarla a otro equipo o usarla desde una copia del disco, pero no que alguien use el propio ordenador: quien lo controle, con permisos de administrador o llevándoselo entero, podría llegar a lo que el agente abre. Por eso recomendamos:

• tenerlo en un sitio cerrado, al que solo pueda acceder quien deba;
• cifrar su disco (BitLocker en Windows). Con un PIN de arranque protege también si se llevan la máquina entera, a cambio de que, tras un reinicio, alguien tenga que escribirlo;
• desactivar la hibernación;
• usarlo solo para esto, con pocas cuentas de administrador;
• tener un antivirus y el sistema al día;
• si desaparece o hay sospechas, retirarlo desde la app y renovar la caja fuerte.

Notificaciones de DEHú

• Por defecto, cada notificación espera a que alguien de tu equipo pulse «Aceptar», porque al aceptar empiezan a contar los plazos. Solo se aceptan solas para los clientes que tú elijas.
• Antes de subir nada, el agente cifra cada documento, anexo y acuse, y también su ficha (titular, organismo, concepto y fechas), con una DEK propia sellada con HPKE para la clave de notificaciones de la gestoría. Es distinta de la de la caja fuerte, y el agente no tiene su parte privada: cifra, pero no puede leer lo ya subido.
• La nube solo guarda identificadores, estados y los cifrados. La clave de notificaciones la reparten los administradores, a cada compañero y a cada equipo que aprueben comparando su huella; en ese equipo queda como una clave que no se puede exportar, y es allí donde se descifra y se ve el PDF.

La app para tus clientes

• Cada cliente ve solo las notificaciones de las empresas que tú le asignas. Entra con un enlace a su correo, sin contraseña, y su móvil crea su propia llave, guardada en el teléfono y protegida con su huella, su cara o su código.
• Hasta que tu gestoría lo aprueba, ese móvil no recibe nada. Para aprobarlo, comparáis un código de seis cifras por teléfono o un QR en persona.
• Solo quien ya puede abrir las notificaciones puede autorizar un móvil: la autorización va firmada con esa llave y el servidor de tu gestoría la comprueba. Nosotros no podemos añadir ningún móvil lector, y tu servidor te avisa por correo de cada móvil autorizado o retirado.
• Cada notificación se sella también para cada móvil autorizado de ese cliente, y solo ese móvil la abre. El aviso que llega al teléfono es un texto fijo: no dice ni el cliente ni el organismo.
• Si pierde el móvil, lo retiras desde el portal: deja de recibir al instante y se borra lo que estaba sellado para él.

La tarjeta virtual en cada puesto

• El empleado abre la app de escritorio con su DNIe o FNMT, y la app pone en el almacén de certificados del sistema solo la parte pública de los certificados de los clientes que él lleva. El .pfx no se importa nunca, y nadie maneja su contraseña.
• En la sede electrónica, el navegador de siempre (Chrome, Edge o Firefox) enseña su selector y el empleado elige el certificado del cliente.
• Para firmar, el navegador se lo pide a una pieza del sistema que no tiene claves (un KSP en Windows, PKCS#11 en Linux) y que se lo pasa a la app por un canal privado del usuario. La app firma: la clave privada se descifra en su memoria, no se escribe en el disco y no se puede exportar.
• Cada firma queda registrada: con qué certificado, desde qué programa y a qué hora.
• Al bloquear el ordenador, pasadas ocho horas o si se le retira el acceso, los certificados salen del almacén y la memoria se pone a cero.

Lo que el modelo no cubre

Contarlo es parte de la garantía:

• El uso, en memoria. Para usar un certificado, su clave privada se descifra en la memoria del equipo. Un equipo infectado con privilegios podría leerla mientras está ahí. Se borra de la memoria al terminar y cada uso queda auditado. Por eso recomendamos tener en cada equipo un antivirus y el sistema y las aplicaciones al día.
• Los datos que sí vemos. Para avisar de caducidades y aplicar permisos, la nube ve los datos públicos de los certificados (titular, NIF, emisor y caducidad), los clientes, los empleados y la auditoría. Las claves privadas y el contenido de las notificaciones, nunca.

¿Necesitas más detalle?

Si tu responsable de protección de datos o tu auditor quiere el documento técnico completo o revisar algo en concreto, escríbenos a hola@gestione.pro. También puedes ver cómo funciona gestiOne en vídeo.