PKI & certificados

La criptografía asimétrica y la PKI (Public Key Infrastructure) sostienen TLS, la firma de código, el correo cifrado y la autenticación con certificado. Esta ficha cubre cómo funciona la cadena de confianza y los ataques que aparecen cuando la validación se hace mal.

Asimétrica: cifrado y firma

PAR DE CLAVES: pública (se reparte) + privada (se guarda)
Cifrado:  cifrar con la PÚBLICA del destino -> solo su PRIVADA descifra (confidencialidad)
Firma:    firmar con la PRIVADA propia -> cualquiera verifica con la PÚBLICA (autenticidad)
RSA   basado en factorización; usar RSA-OAEP (cifrado) y RSA-PSS (firma), nunca PKCS#1v1.5 crudo
ECC   curvas elípticas; claves cortas, misma seguridad; Ed25519 (firma), X25519 (intercambio)

La cadena de confianza (PKI)

CA raíz (en el truststore del SO/navegador)
  └─ firma -> CA intermedia
        └─ firma -> certificado del servidor (CN/SAN = dominio, clave pública, validez)
Validar un cert = verificar la firma de cada eslabón hasta una CA de confianza
+ comprobar: vigencia, que el nombre (SAN) case con el host, y revocación (CRL/OCSP)

Ataques y fallos (lo explotable)

Validación de certificado rota (clientes/apps)

# el fallo más común en apps móviles/IoT/clientes a medida:
- no validar la cadena             -> acepta cert autofirmado -> MITM
- no comprobar el hostname (SAN)   -> cert válido de OTRO dominio sirve -> MITM
- aceptar certs caducados/revocados
# prueba: interceptar con Burp/mitmproxy y ver si el cliente acepta tu cert

Confusión de algoritmo en firmas (JWT)

# JWT alg=none    -> algunos verificadores aceptan token SIN firma
# JWT RS256->HS256 -> firmar con la clave PÚBLICA (conocida) como secreto HMAC
#   si el verificador no fija el algoritmo. (ver web-session / web-api)

Debilidades de clave

- RSA con clave pequeña (<2048) o primos mal generados (claves gemelas por RNG débil, ver crypto-rng)
- clave privada expuesta en repos/binarios/firmware -> impersonación total
- padding PKCS#1 v1.5 -> Bleichenbacher/ROBOT (padding oracle sobre RSA)

Herramientas

openssl (inspeccionar/forjar certs, CSR, verificar cadenas), mitmproxy/Burp (probar validación TLS en clientes).
jwt_tool (ataques a JWT), testssl.sh (ver TLS), crt.sh (transparencia de certificados para recon).

Defensa

Validar siempre cadena + hostname + vigencia + revocación; no deshabilitar la verificación “para que funcione”.
Certificate pinning en apps móviles de alto valor; usar RSA ≥ 2048 / ECC y OAEP/PSS.
Proteger la clave privada (HSM/KMS, permisos); Certificate Transparency y monitorización de emisiones.
JWT: fijar el algoritmo esperado en el servidor; rechazar none y el cambio RS→HS.

CVEs y casos reales

Bleichenbacher / ROBOT (2017): padding oracle de RSA PKCS#1v1.5 en grandes sitios.
goto fail (CVE-2014-1266, Apple): un goto saltaba la verificación de firma TLS.
DigiNotar (2011): CA comprometida emitió certificados falsos de Google → MITM a usuarios en Irán.
Numerosos CVEs de JWT alg=none y confusión RS256/HS256 en librerías populares.

Checklist de prueba

Cliente/app: ¿valida cadena y hostname? (MITM con Burp/mitmproxy)
¿Acepta certs autofirmados/caducados/revocados?
JWT: probar alg=none y confusión RS256→HS256
¿Tamaño/calidad de clave RSA? ¿claves repetidas (RNG)?
Buscar claves privadas filtradas (repos/firmware/binarios)
RSA: ¿padding PKCS#1v1.5 vulnerable a oracle?
Recon: enumerar subdominios vía crt.sh (Certificate Transparency)