1. El principio de la autenticación con clave pública

En la autenticación con contraseña, el usuario y el servidor comparten un secreto, y cada vez que se usa existe la posibilidad de que se intercepte, se adivine o se filtre desde el servidor. La criptografía de clave pública elimina esa debilidad: el usuario posee un par de claves matemáticamente ligadas. La clave privada nunca sale de su poder; la clave pública se entrega al servidor, que puede publicarla sin riesgo.

La autenticación se realiza mediante un esquema de reto y respuesta:

  1. El servidor genera un reto aleatorio y de un solo uso, y lo envía al cliente.

  2. El cliente firma el reto con su clave privada y devuelve la firma.

  3. El servidor verifica la firma con la clave pública registrada. Si es válida, solo quien posee la clave privada ha podido producirla.

Esto aporta tres ventajas respecto a las contraseñas: el servidor no almacena ningún secreto que, de robarse, permita suplantar a los usuarios; el secreto no viaja por la red; y la firma solo vale para ese reto, de modo que interceptarla no sirve para reutilizarla.

La seguridad pasa a depender de la custodia de la clave privada

Quien obtenga la clave privada es el usuario a todos los efectos. Por eso las claves deben protegerse con una frase de paso y, siempre que sea posible, guardarse en un dispositivo que impida su exportación, como una tarjeta inteligente o una llave FIDO2.

Con los conceptos explicados hasta aquí, ya puede realizar el Ejercicio 1. Reto y respuesta con clave pública.

2. Claves SSH

SSH es el caso más extendido de autenticación con clave pública en administración de sistemas. El servidor guarda las claves públicas autorizadas de cada cuenta y el cliente demuestra que posee la privada.

Elemento Descripción Ejemplo Explicación técnica

Clave privada

Secreto del usuario

~/.ssh/id_ed25519

Debe tener permisos 600 y estar protegida con frase de paso.

Clave pública

Parte que se distribuye

~/.ssh/id_ed25519.pub

Se añade al servidor y puede compartirse sin riesgo.

Claves autorizadas

Lista del servidor

~/.ssh/authorized_keys

Una clave por línea, con opciones de restricción opcionales.

Claves de host

Identidad del servidor

~/.ssh/known_hosts

Permite al cliente detectar un servidor suplantado.

Directivas de sshd

Política del servidor

PasswordAuthentication no

Deshabilita la contraseña y deja solo la clave.

Las recomendaciones de bastionado son las siguientes:

  • Algoritmo: Ed25519 como opción preferente; RSA solo con 3072 bits o más.

  • Frase de paso en toda clave privada, de modo que un robo del archivo no equivalga a un acceso inmediato.

  • Restringir cada clave autorizada con opciones como from= para limitar el origen, command= para forzar una orden concreta y restrict para desactivar reenvíos y terminales.

  • Evitar el reenvío del agente hacia servidores no confiables, porque permite que su administrador use las claves cargadas.

  • Inventariar y rotar las claves, y eliminar las de personas que causan baja.

  • Considerar claves respaldadas por hardware, de tipo ed25519-sk, que exigen tocar la llave FIDO2 en cada autenticación.

Los dos riesgos más frecuentes se recogen en MITRE ATT&CK: el robo de claves privadas sin proteger, técnica T1552.004, y la persistencia mediante la inserción de una clave del atacante en authorized_keys, técnica T1098.004. Por eso conviene auditar ese archivo y vigilar sus modificaciones.

La configuración completa del servicio, el endurecimiento de sshd y el acceso mediante saltos se desarrollan en la guía de SSH y en la de ProxyJump.

Con los conceptos explicados en esta sección, ya puede realizar el Ejercicio 2. Claves SSH: generar, proteger y auditar.

3. Certificados X.509 y autenticación mutua

Un certificado X.509 liga una clave pública a una identidad y está firmado por una autoridad de certificación. En lugar de que cada servidor mantenga una lista de claves de usuarios, confía en la autoridad y acepta a quien presente un certificado emitido por ella.

Los campos que importan para la autenticación son:

  • Sujeto y emisor: a quién identifica el certificado y quién lo firmó.

  • Periodo de validez: fechas entre las que es utilizable.

  • Uso de la clave y uso extendido: para qué se puede usar, por ejemplo clientAuth para autenticar a un cliente o serverAuth para un servidor.

  • Nombres alternativos: los nombres de dominio o direcciones que cubre un certificado de servidor.

En TLS corriente solo se autentica el servidor, mediante su certificado, y el cliente se autentica luego con una contraseña. En la autenticación mutua, mutual TLS o mTLS, ambos presentan certificado durante el establecimiento de la conexión y cada lado valida el del otro. Es la base de muchas arquitecturas de confianza cero entre servicios, de las pasarelas de acceso y de los accesos con tarjeta inteligente.

El servidor de mTLS rechaza al cliente en tres situaciones que se observan en el Ejercicio 3: no presenta certificado, lo presenta de una autoridad desconocida, o el certificado está caducado o revocado.

Los puntos débiles de esta técnica están en el ciclo de vida:

  • Revocación: difundir que un certificado ya no es válido, mediante listas CRL o el protocolo OCSP, es más difícil de lo que parece, y muchos servicios no la comprueban.

  • Caducidad: certificados olvidados que expiran causan caídas de servicio, y certificados de vida muy larga prolongan el daño de un robo. La tendencia es emitir certificados de vida corta y automatizar la renovación.

  • Custodia de las claves privadas de los clientes y compromiso de la propia autoridad, que invalidaría la confianza en todo lo que emitió.

La emisión, la jerarquía de autoridades y la revocación se practican en la guía de infraestructura de clave pública.

Con los conceptos explicados en esta sección, ya puede realizar el Ejercicio 3. Autenticación mutua con certificados.

4. FIDO2, WebAuthn y passkeys

FIDO2 es el conjunto de estándares de la FIDO Alliance y del W3C que lleva la autenticación con clave pública a la web y a las aplicaciones. Se compone de dos partes:

  • WebAuthn: la interfaz de programación que ofrece el navegador a las aplicaciones web.

  • CTAP: el protocolo con el que el navegador o el sistema operativo se comunica con el autenticador, ya sea una llave USB o NFC, el procesador seguro del teléfono o el módulo del equipo.

4.1. Funcionamiento

Autenticación con FIDO2 y WebAuthn
Figura 1. Autenticación con FIDO2 y WebAuthn

  • Registro: el autenticador crea un par de claves nuevo para ese sitio. La clave pública y un identificador de credencial se envían al servidor; la privada queda en el dispositivo.

  • Autenticación: el servidor envía un reto y el identificador del sitio, el rpId. El autenticador, previa verificación local del usuario mediante PIN o biometría, firma el reto junto con el origen y devuelve la firma.

Dos propiedades resuelven los problemas más graves de las contraseñas:

  • Resistencia al phishing. La firma incluye el origen verificado por el navegador y está ligada al rpId de la credencial. En una web falsa con otro dominio, el autenticador no tiene ninguna credencial para ese origen y no firma nada. No hay código que el usuario pueda teclear ni retransmitir.

  • Claves distintas por sitio. Ningún secreto se comparte entre servicios y no puede correlacionarse al usuario entre ellos.

La verificación local del usuario, el PIN o la huella, nunca sale del dispositivo: solo desbloquea la clave. Es la forma de usar biometría respetando la privacidad que se explicó en el capítulo de biometría.

4.2. Passkeys

Una passkey es una credencial FIDO descubrible, es decir, que el autenticador puede localizar sin que el usuario escriba antes su nombre, y pensada para sustituir a la contraseña. Existen dos variantes con compromisos distintos:

Variante Dónde está la clave Ventajas Inconvenientes

Ligada al dispositivo

En una llave de seguridad o en un único dispositivo

Clave no exportable, máxima garantía

Si se pierde, exige tener un respaldo registrado

Sincronizada

En un gestor en la nube del proveedor del sistema o de un gestor de contraseñas

Recuperación sencilla y uso en varios dispositivos

La seguridad depende de la cuenta del proveedor y de su recuperación

La norma NIST SP 800-63B-4 exige para su nivel más alto, AAL3, una clave privada no exportable, por lo que las passkeys sincronizadas quedan fuera de ese nivel y las llaves o dispositivos ligados son la opción adecuada para administradores y accesos críticos.

La sincronización resuelve el problema de la pérdida del dispositivo, pero traslada el riesgo a otro sitio. La cuenta del proveedor que sincroniza las credenciales se convierte en la llave maestra de todas ellas, de modo que quien la comprometa entra en todos los servicios que dependan de esas passkeys. Esa cuenta debe quedar protegida mejor que ninguna otra, con un autenticador ligado al dispositivo, y conviene revisar periódicamente qué dispositivos tiene asociados y por qué vías se recupera.

4.3. Despliegue

  • Registrar al menos dos autenticadores por usuario, para evitar bloqueos.

  • Mantener un proceso de recuperación tan robusto como la autenticación, ya que es el camino que atacará un adversario.

  • Mantener la contraseña como alternativa solo mientras dure la migración, y retirarla después.

  • Exigir verificación del usuario, no solo presencia, en accesos sensibles.

5. Comparativa de técnicas criptográficas

Técnica Secreto en el servidor Resistente al phishing Custodia de la clave Uso típico

Contraseña

Sí, en forma de hash

No

Memoria del usuario

Referencia de comparación

Clave SSH

No, solo la pública

Sí frente al robo de credencial

Archivo, agente o llave

Administración de sistemas

Certificado y tarjeta inteligente

No

Sí, con validación mutua

Chip no exportable

Entornos corporativos y administración pública

FIDO2 y passkeys

No

Sí, por verificación del origen

Autenticador o gestor

Servicios web y aplicaciones

mTLS entre servicios

No

Sí

Almacén de claves del servicio

Comunicaciones entre servicios

6. Amenazas y buenas prácticas

  1. Proteger las claves privadas con frase de paso o con hardware, y no guardarlas en repositorios, copias de seguridad sin cifrar ni directorios compartidos.

  2. Auditar authorized_keys y las claves registradas de forma periódica, buscando entradas desconocidas.

  3. Validar siempre la cadena, el uso y la revocación de los certificados, y no desactivar la comprobación para evitar errores.

  4. Emitir certificados de vida corta y automatizar su renovación.

  5. Controlar la autoridad de certificación: custodiarla fuera de línea o en un módulo de seguridad y registrar cada emisión.

  6. Preferir autenticadores resistentes al phishing para cuentas privilegiadas y accesos remotos.

  7. Planificar la recuperación antes de retirar las contraseñas, no después.

7. Ejercicios prácticos

Los ejercicios están diseñados para realizarse en orden sobre una máquina virtual Ubuntu o Debian de pruebas. Todos los archivos se crean en ~/lab_cripto. El último ejercicio elimina todo lo creado.

Nº Ejercicio Competencia que desarrolla

1

Reto y respuesta con clave pública

Comprender el mecanismo básico de la autenticación criptográfica

2

Claves SSH: generar, proteger y auditar

Gestionar y auditar claves de acceso

3

Autenticación mutua con certificados

Configurar y comprobar un servidor mTLS

4

Limpieza del entorno

Revertir los cambios realizados

7.1. Ejercicio 1. Reto y respuesta con clave pública

Realice los siguientes pasos:

  1. Cree el directorio de trabajo y genere un par de claves Ed25519 con openssl:

    mkdir -p ~/lab_cripto && cd ~/lab_cripto
openssl genpkey -algorithm ED25519 -out usuario.key
openssl pkey -in usuario.key -pubout -out usuario.pub

  2. Simule al servidor: genere un reto aleatorio. Simule al cliente: fírmelo con la clave privada. Verifique la firma con la clave pública.

  3. Compruebe que la firma no es válida para un reto distinto, y razone por qué un atacante que interceptara la firma no podría reutilizarla.

  4. Indique qué archivo debe mantenerse secreto, cuál puede publicarse y qué información tendría que obtener el atacante para suplantar al usuario.

7.2. Ejercicio 2. Claves SSH: generar, proteger y auditar

Realice los siguientes pasos:

  1. Genere dos claves Ed25519 en el directorio de trabajo: una con frase de paso y otra sin ella.

  2. Obtenga la huella de cada clave pública y compruebe los permisos de los archivos privados.

  3. Audite qué claves privadas carecen de frase de paso. La orden ssh-keygen -y -P '' solo consigue derivar la clave pública si la privada no tiene frase de paso.

  4. Escriba la línea de authorized_keys que autorizaría la clave clave_protegida.pub pero solo desde la red 192.0.2.0/24, sin terminal ni reenvíos y ejecutando únicamente /usr/bin/uptime. Explique la ventaja de esta restricción si la clave se robara.

7.3. Ejercicio 3. Autenticación mutua con certificados

Realice los siguientes pasos:

  1. Cree una autoridad de certificación de pruebas, un certificado de servidor para localhost y un certificado de cliente para alumno.

  2. Inicie un servidor que exija certificado de cliente y conéctese con el certificado de alumno. Compruebe que la verificación es correcta y que se negocia TLS 1.3.

  3. Intente conectarse sin certificado de cliente y, después, con uno emitido por una autoridad distinta que cree usted. Anote el error de cada caso.

  4. Detenga el servidor y razone qué comprobaciones adicionales haría un servidor real: revocación, caducidad y uso extendido de la clave.

7.4. Ejercicio 4. Limpieza del entorno

  1. Compruebe que no queda ningún servidor de prueba en ejecución y elimine el directorio de trabajo, que contiene las claves y los certificados.

8. Referencias

9. Licencia

Licencia CC BY-NC-ND 4.0

Esta página forma parte del curso Bastionado de Redes y Sistemas © 2026 de José Juan Sánchez Hernández y su contenido se distribuye bajo una licencia Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International.

Esta licencia exige que quienes reutilicen el material otorguen el debido crédito al autor. Permite copiar y redistribuir el material en cualquier medio o formato, únicamente en su forma original, y solo para fines no comerciales.