Criptografía asimétrica para intercambio de claves e identidad: cuándo usarla

Cuándo usar criptografía asimétrica (y cuándo no)

En sistemas reales, la criptografía asimétrica se usa principalmente para dos cosas: intercambiar/derivar claves (p. ej., ECDH con X25519 o P-256) y establecer identidad (p. ej., firmas digitales y certificados). En cambio, no es la herramienta adecuada para cifrar grandes volúmenes de datos directamente.

La regla práctica es: usa asimétrica para arrancar una sesión (acordar una clave de sesión y autenticar a la contraparte) y usa simétrica para transportar datos (cifrado y autenticación eficientes a gran escala).

Intercambio de claves: ECDH (X25519) como “motor” de sesiones

En un intercambio ECDH, dos partes generan pares de claves (privada/pública) y combinan su privada con la pública del otro para obtener un secreto compartido. Ese secreto no se usa “tal cual”: se pasa por un KDF (p. ej., HKDF) para producir una o varias claves de sesión (cifrado, autenticación, rekeying, etc.).

• X25519 (Curve25519) es una opción moderna y ampliamente recomendada por su seguridad y robustez de implementación.
• P-256 (secp256r1) es común por compatibilidad (ecosistema TLS/PKI empresarial), aunque la elección depende del entorno.

Por qué no “cifrar datos grandes con RSA”

RSA (y otros esquemas de cifrado asimétrico) tiene limitaciones prácticas y de seguridad para datos grandes:

• Límite de tamaño: con RSA-OAEP, el mensaje máximo es menor que el tamaño del módulo (p. ej., con 2048 bits, el máximo útil suele ser del orden de cientos de bytes, no megabytes).
• Coste computacional: cifrar/descifrar asimétrico es mucho más caro que simétrico; escalarlo a datos grandes es ineficiente.
• Riesgo de mal uso: usar RSA “a pelo” (sin OAEP), o reutilizar parámetros incorrectamente, abre vulnerabilidades. En producción, el patrón correcto es híbrido.

El diseño estándar es: asimétrica para encapsular/derivar una clave de sesión y simétrica para cifrar el payload.

Continúa en nuestra aplicación.

• Escuche el audio con la pantalla apagada.
• Obtenga un certificado al finalizar.
• ¡Más de 5000 cursos para que explores!

O continúa leyendo más abajo...

Descargar la aplicación

Cifrado híbrido: patrón recomendado

Modelo mental

Piensa en dos capas:

• Capa de establecimiento: ECDH (X25519) o KEM (si aplica) para acordar una clave de sesión; opcionalmente firmas/certificados para identidad.
• Capa de datos: cifrado simétrico autenticado (AEAD) con la clave de sesión para proteger los datos.

Flujo híbrido paso a paso (ECDH + HKDF + AEAD)

Ejemplo conceptual para un canal cliente-servidor (sin entrar en detalles ya cubiertos sobre AEAD/nonces):

1. Generación de claves efímeras: el cliente crea un par X25519 efímero (c_priv, c_pub).
2. Obtención de clave pública del servidor: el cliente obtiene s_pub (p. ej., de un certificado o un registro confiable).
3. ECDH: el cliente calcula shared = ECDH(c_priv, s_pub). El servidor, al recibir c_pub, calcula shared = ECDH(s_priv, c_pub).
4. Derivación con KDF: ambos derivan claves con HKDF: key_session = HKDF(shared, salt, info). El info debe incluir contexto (protocolo, versión, roles, IDs) para evitar confusiones de claves entre usos.
5. Cifrado de datos: el cliente cifra el payload con AEAD usando key_session y envía (c_pub, ciphertext, tag, nonce/iv según el esquema).
6. Descifrado: el servidor deriva key_session de la misma forma y descifra/verifica.

Este patrón es la base de muchos protocolos modernos: el intercambio asimétrico ocurre una vez por sesión (o por rekey), y el tráfico de datos usa simétrica.

Autenticación e identidad: evitar “ECDH anónimo”

ECDH por sí solo puede ser vulnerable a ataques de intermediario (MITM) si no autenticas la clave pública del otro lado. Para establecer identidad, necesitas al menos una de estas estrategias:

• Certificados y PKI: el servidor presenta un certificado; el cliente valida cadena y nombre/identidad.
• Claves públicas fijadas (pinning): el cliente conoce de antemano la clave pública del servidor (útil en IoT o entornos cerrados).
• Firmas del transcript: cada parte firma datos del handshake (claves efímeras, parámetros, IDs) con una clave de firma de largo plazo.

En la práctica, muchos despliegues usan TLS para resolver esto. Si diseñas un protocolo propio, documenta explícitamente cómo se autentican claves públicas y cómo se previene MITM.

Criterios para elegir curvas y tamaños de clave

Elección rápida (regla práctica)

• Para ECDH: X25519 suele ser la primera opción si está disponible.
• Para firmas: Ed25519 es una opción moderna y eficiente; ECDSA P-256 es común por compatibilidad.
• Si necesitas RSA (por compatibilidad con PKI existente): usa al menos 2048 bits (a menudo 3072 en políticas más estrictas) y OAEP para cifrado, PSS para firmas.

Compatibilidad y entorno

La “mejor” curva no sirve si tu plataforma no la soporta de forma consistente. Evalúa:

• Clientes antiguos: algunos stacks heredados no soportan X25519/Ed25519.
• HSM/TPM: puede que soporten mejor P-256/RSA que Curve25519.
• FIPS/Compliance: ciertas organizaciones requieren curvas NIST (p. ej., P-256) y restringen Ed25519/X25519.

Seguridad operativa

• Preferir efímero: ECDHE (claves efímeras) para confidencialidad futura (forward secrecy).
• Separación de claves: no reutilices la misma clave para ECDH y firma; usa claves distintas por propósito.
• Context binding: el KDF debe “atar” la clave al contexto (roles, IDs, versión, algoritmo) para evitar ataques de confusión.

Cómo evaluar bibliotecas criptográficas (checklist práctico)

En producción, el riesgo suele estar en la integración. Lista de verificación:

• Primitivas de alto nivel: busca APIs que ofrezcan “cifrado híbrido” o “sealed boxes” en lugar de piezas sueltas.
• Soporte de X25519/Ed25519: y que esté habilitado por defecto o documentado claramente.
• Implementación constante en tiempo: especialmente para operaciones con claves privadas.
• Manejo seguro de claves: soporte para tipos de clave no serializables, integración con HSM/TPM, y borrado/zeroization cuando aplique.
• Auditorías y mantenimiento: historial de releases, respuesta a CVEs, y pruebas (fuzzing, test vectors).
• Interoperabilidad: formatos estándar (X.509, JWK, PEM), y compatibilidad con TLS si vas a apoyarte en él.

Evita bibliotecas que te obliguen a diseñar padding, serialización de estructuras críticas o “protocolos” ad hoc sin guías claras.

Escenario 1: Onboarding de dispositivos (IoT/edge) con identidad y sesión

Objetivo

Dar de alta un dispositivo nuevo de forma que: (1) el servidor verifique que el dispositivo es legítimo, y (2) se establezca una clave de sesión para configurar secretos iniciales.

Flujo recomendado (paso a paso)

1. Identidad del dispositivo: el dispositivo trae una clave de firma de fábrica (p. ej., en un secure element) y un certificado o clave pública registrada.
2. Handshake con ECDHE: el dispositivo genera una clave efímera X25519 y envía su pública efímera.
3. Prueba de posesión: el dispositivo firma el transcript del handshake (incluyendo su clave efímera y un nonce del servidor) con su clave de firma de largo plazo.
4. Validación: el servidor valida la firma usando la identidad registrada/certificado del dispositivo.
5. Derivación de claves: ambos hacen ECDH efímero y derivan key_session con HKDF (incluyendo IDs de dispositivo/servidor en info).
6. Provisioning: el servidor envía configuración/secreto inicial cifrado con key_session (p. ej., token de acceso, credenciales de red, endpoints).

Puntos de diseño: usa claves efímeras para la sesión (no la clave de fábrica), y limita el alcance temporal de key_session (rotación/rekey).

Escenario 2: Cifrar un secreto para múltiples destinatarios

Problema

Quieres cifrar un mismo secreto (p. ej., una clave API o un archivo pequeño) para N destinatarios distintos, cada uno con su clave pública.

Patrón práctico: “una clave de datos, N envolturas”

1. Genera una clave de datos aleatoria (DEK) para cifrar el secreto una sola vez con simétrica.
2. Cifra el secreto con la DEK (produces ciphertext_data).
3. Para cada destinatario i: encapsula/deriva una clave de envoltura usando su clave pública (p. ej., ECDH con una clave efímera del emisor + HKDF) y cifra la DEK para ese destinatario (produces wrapped_DEK_i).
4. Empaqueta: almacena ciphertext_data + lista de wrapped_DEK_i + metadatos (algoritmos, IDs de destinatario, clave pública efímera del emisor si aplica).

Ventajas: el secreto grande se cifra una vez; el coste asimétrico crece con N pero solo para envolver una clave pequeña (DEK). Esto es el patrón típico en sistemas de “envelope encryption”.

Detalles a cuidar

• Identificadores de destinatario: incluye un ID estable para que el receptor encuentre su envoltura sin probar todas.
• Binding de contexto: el KDF debe incluir ID del destinatario y del emisor para evitar sustituciones.
• Rotación: si cambian destinatarios, puedes re-envolver la DEK sin re-cifrar el dato (si mantienes la DEK), o regenerar DEK si tu política lo exige.

Escenario 3: Comunicación servicio-a-servicio (microservicios)

Cuándo usar asimétrica aquí

En entornos de microservicios, lo común es usar TLS (mTLS) para autenticación mutua y establecimiento de sesión. Aun así, entender el patrón ayuda a decidir:

• mTLS: asimétrica para autenticar (certificados) y negociar claves de sesión; simétrica para el tráfico.
• Tokens firmados: asimétrica para identidad/autorización (firmas), sin cifrar necesariamente el canal (aunque suele coexistir con TLS).

Guía práctica de diseño (sin reinventar TLS)

1. Define identidad: cada servicio tiene un certificado/clave de firma emitido por una CA interna.
2. Establece canal: usa mTLS con ECDHE (idealmente X25519 o P-256 según compatibilidad).
3. Autoriza: usa identidad del certificado (SAN/URI) para políticas; evita basarte solo en IPs.
4. Rotación automática: certificados de corta vida y renovación automatizada (sidecar/agent).
5. Observabilidad segura: registra metadatos (IDs, huellas) sin volcar secretos o material de claves.

Si por restricciones debes crear un protocolo propio (p. ej., UDP o entornos muy específicos), replica explícitamente: autenticación de claves públicas, ECDHE, KDF con binding de contexto, y protección de replay con nonces/contadores a nivel de protocolo.

Compatibilidad, formatos y empaquetado de mensajes

Qué debe incluir un “paquete” híbrido

Para interoperabilidad y mantenimiento, un mensaje cifrado híbrido suele incluir:

• Versión del formato.
• Algoritmos (identificadores: X25519, HKDF-SHA256, etc.).
• Clave pública efímera del emisor (si usas ECDH efímero).
• Salt/info del KDF (o cómo derivarlos determinísticamente).
• Ciphertext y autenticación (tag) del AEAD.
• Metadatos autenticados (AAD): IDs, timestamps, contexto de aplicación.

Recomendación operativa: define un esquema de serialización estable (p. ej., CBOR/Protobuf) y asegúrate de que los campos críticos estén autenticados (AAD) para evitar ataques de sustitución.

Errores comunes y cómo evitarlos

• Usar ECDH sin autenticar: añade certificados, pinning o firmas del transcript.
• Reutilizar claves: separa claves por propósito (firma vs intercambio).
• Derivar claves sin contexto: usa HKDF con info rico (protocolo, versión, roles, IDs).
• Inventar padding/formatos: usa estándares y bibliotecas de alto nivel.
• Compatibilidad ignorada: valida soporte real en tus clientes/servidores antes de elegir curva/algoritmo.