Certificados TLS de servidor
Tráfico web seguro a gran escala
Inventario de certificados
Descubrir y rastrear todos los certificados
Certificados DevOps
Automatizar para pipelines CI/CD
Cifrado de correo electrónico
S/MIME para correo electrónico empresarial
Cada certificado digital, cada apretón de manos TLS, cada firma digital depende de un par de claves vinculadas matemáticamente. Comprender cómo funcionan las claves públicas y privadas es esencial para entender cómo se construye la confianza en línea.
Imagina un buzón especial en tu porche delantero. Tiene una ranura en la que cualquiera en la calle puede dejar una carta. Esa ranura está siempre abierta, siempre visible, y todos saben dónde está. Pero el propio buzón está cerrado con llave, y solo tú tienes la llave para abrirlo y leer lo que hay dentro. No importa cuántas personas dejen cartas, solo tú puedes recuperarlas.
Esta es la idea básica detrás claves públicas y privadas. El buzón es tu clave pública, compartida libremente, disponible abiertamente, usada por cualquiera que quiera enviarte datos cifrados. La clave para abrir el buzón es tu clave privada, mantenida en secreto, nunca compartida, y lo único que puede descifrar lo que fue cifrado con la clave pública.
Este concepto, llamado criptografía asimétrica, fue propuesto públicamente en 1976 por Whitfield Diffie y Martin Hellman. Resolvió uno de los problemas más antiguos de la criptografía's, cómo intercambiar secretos de forma segura sin necesitar una clave precompartida, y sigue siendo la base de todo, desde HTTPS hasta el cifrado de correo electrónico hasta certificados digitales.
Un par de claves consta de dos claves relacionadas matemáticamente generadas juntas. Su relación está gobernada por una función matemática unidireccional: la clave pública se deriva de la clave privada, pero calcular la clave privada a partir de la clave pública es computacionalmente inviable.
Cuando alguien quiere enviarte datos confidenciales, los cifra con tu clave pública. El texto cifrado resultante solo puede ser descifrado por tu clave privada. Incluso el remitente no puede revertir el cifrado. Solo el poseedor de la clave privada puede
La relación funciona al revés para las firmas. Usted firma datos con su clave privada, y cualquiera con su clave pública puede verificar que la firma es auténtica. Esto demuestra tanto su identidad como que los datos no han sido manipulados.
En protocolos como TLS, los pares de claves se utilizan para negociar una clave de sesión compartida. Las claves asimétricas gestionan el intercambio inicial y seguro; luego un algoritmo simétrico más rápido se hace cargo del cifrado de los datos en bloque. Este enfoque híbrido le brinda lo mejor de ambos mundos.
La regla crucial es simple: la clave privada nunca debe compartirse. Todo el modelo de seguridad depende de esto. Si un atacante obtiene su clave privada, puede suplantarle, descifrar mensajes destinados a usted y falsificar sus firmas digitales. La clave pública, por el contrario, está diseñada para distribuirse lo más ampliamente posible. Está incrustada en certificados digitales y se comparte con cualquiera que necesite comunicarse con usted de forma segura.
La fuerza de un par de claves depende de cómo se genera y, críticamente, de su longitud de clave, el número de bits que componen la clave. Las claves más largas son más difíciles de romper, pero también requieren más cálculo.
Claves RSA de 2048 bits son el mínimo actual de la industria. Muchas organizaciones ahora usan por defecto 4096 bits para claves raíz e intermedias de CA, proporcionando un margen de seguridad mayor a medida que aumenta la potencia computacional.
Las claves de curva elíptica logran una seguridad equivalente con longitudes mucho más cortas. Un clave ECC de 256 bits (curva P-256) ofrece una seguridad comparable a una clave RSA de 3072 bits. Una clave ECC de 384 bits coincide aproximadamente con una RSA de 7680 bits.
La generación de claves requiere una fuente de aleatoriedad de alta calidad (entropía). La aleatoriedad deficiente (provista por hardware defectuoso, software con errores o semillas predecibles) puede generar claves que parecen fuertes pero que en realidad son adivinables. Esta es una de las vulnerabilidades silenciosas más comunes en los sistemas criptográficos.
Tanto RSA como ECC son vulnerables a futuros ordenadores cuánticos que ejecutan el algoritmo de Shor's. Algoritmos post-cuánticos utilizan diferentes estructuras matemáticas (rejillas, esquemas basados en hash) y requerirán tamaños de clave totalmente diferentes.
Cuando se genera un par de claves para un certificado, la clave privada se crea primero, y la clave pública se deriva matemáticamente de ella. La clave pública se incluye luego en una Solicitud de Firma de Certificado (CSR) y finalmente se incrusta en el certificado emitido. La clave privada permanece con el propietario del certificado y nunca debe salir de su almacenamiento seguro.
Las claves públicas y privadas no son conceptos abstractos. Son participantes activos en los mecanismos de seguridad en los que confías a diario. Aquí están los casos de uso más importantes:
Cuando su navegador se conecta a un sitio web a través de HTTPS, el servidor presenta su certificado que contiene su clave pública. El navegador usa esta clave pública para verificar la identidad del servidor's y para establecer una sesión cifrada. La clave privada del servidor's se usa en el lado del servidor para completar el apretón de manos. Esto ocurre miles de millones de veces al día en todo Internet.
Los desarrolladores de software firman el código con su clave privada para que los usuarios puedan verificar la autenticidad. Las CA firman los certificados con su clave privada para que los navegadores puedan verificar la confianza. Los remitentes de correo electrónico firman los mensajes con su clave privada para que los destinatarios puedan confirmar la identidad del remitente's. En cada caso, la clave pública correspondiente se utiliza para la verificación.
S/MIME usa la clave pública del destinatario's (de su certificado) para cifrar un correo electrónico. Sólo la clave privada del destinatario's puede descifrarlo. Esto garantiza que incluso si el correo electrónico es interceptado en tránsito o accedido en un servidor de correo comprometido, el contenido permanece confidencial.
En arquitecturas de confianza cero y entornos de malla de servicios, ambos el cliente y el servidor presentan certificados y demuestran la propiedad de sus claves privadas. Esto TLS mutuo garantiza que cada lado de la conexión esté autenticado, lo cual es crítico para la comunicación microservicio a microservicio.
Generar un par de claves fuerte es solo la mitad de la batalla. Si la clave privada no se almacena y protege adecuadamente, podría no existir. Aquí están las principales opciones de almacenamiento, desde lo básico hasta lo reforzado:
El enfoque más sencillo: la clave privada se almacena como un archivo en disco, a menudo en formato PEM o PKCS#12, opcionalmente protegida por una frase de contraseña. Esto es común en entornos de desarrollo, pero deja la clave expuesta a cualquiera que tenga acceso al sistema de archivos. No se recomienda para claves CA de producción o certificados de alto valor.
Los proveedores de la nube ofrecen servicios de gestión de claves (AWS KMS, Azure Key Vault, Google Cloud KMS) que almacenan claves en bóvedas respaldadas por software o hardware. El acceso se controla mediante políticas IAM y registros de auditoría. Esto representa un avance significativo respecto al almacenamiento basado en archivos, particularmente en entornos nativos de la nube.
Un HSM es un dispositivo de hardware dedicado y resistente a manipulaciones, diseñado para generar, almacenar y usar claves criptográficas. La clave privada nunca sale del HSM. Todas las operaciones criptográficas se realizan dentro de él. Los HSM son el estándar de oro para proteger las claves privadas de la CA, y son requeridos por la mayoría de los marcos de cumplimiento (eIDAS, WebTrust, ETSI) para emitir certificados de confianza pública.
La gestión de claves es una de las áreas donde los errores son más costosos y más comunes. Aquí están los obstáculos que las organizaciones encuentran repetidamente:
Si una clave privada es robada (a través de una violación del servidor, una copia de seguridad expuesta o un repositorio mal configurado), el atacante puede suplantar al propietario de la clave, descifrar el tráfico interceptado y falsificar firmas digitales. La única solución es revocar el certificado inmediatamente y generar un nuevo par de claves. Cada minuto de retraso es una ventana de exposición.
Las claves RSA más cortas de 2048 bits se consideran vulnerables con hardware moderno. Los sistemas heredados a veces aún usan claves RSA de 1024 bits, que han sido obsoletas durante más de una década. De manera similar, las claves generadas con poca aleatoriedad (como el error de Debian OpenSSL de 2008, que afectó a miles de servidores) pueden ser descifradas trivialmente sin importar su longitud nominal.
Las claves privadas almacenadas en texto plano en servidores web, comprometidas en repositorios Git o compartidas entre varios sistemas aumentan drásticamente el alcance de una vulnerabilidad. De manera similar, reutilizar el mismo par de claves en muchos certificados significa que la compromisión de una sola clave invalida todos ellos. La mejor práctica es generar un par de claves único para cada certificado y almacenar las claves privadas en el almacenamiento más seguro disponible para el caso de uso.
Estas trampas subrayan por qué la gestión de claves no es solo una preocupación técnica. Es una preocupación organizacional. Políticas claras sobre la generación, almacenamiento, rotación de claves y respuesta a incidentes son esenciales. Sin ellas, incluso los algoritmos criptográficos más fuertes no pueden protegerte.
Inventario de cada clave: Evertrust CLM descubre todos los certificados y mapea los algoritmos de clave asociados, longitudes y ubicaciones de almacenamiento. Obtienes una visión completa de tu postura criptográfica, incluidas las claves que están por debajo de tus estándares de seguridad.
Aplicar políticas de claves: Define longitudes mínimas de clave, algoritmos aprobados y uso obligatorio de HSM para tipos específicos de certificados. Evertrust PKI aplica estas políticas en el momento de la inscripción, evitando que se emitan claves débiles.
Automatizar la rotación de claves: Cuando los certificados se renuevan o se vuelven a generar, Evertrust automatiza la generación de nuevos pares de claves y el despliegue de certificados actualizados, reduciendo el riesgo de reutilización de claves y errores humanos.
Responder rápidamente a una vulneración: Si se sospecha que una clave está comprometida, Evertrust permite la revocación inmediata y la reemisión automatizada en todos los sistemas afectados, minimizando la ventana de exposición.
