AES-256 y la Criptografía de Clave Pública para Proteger Datos Sensibles
El cifrado AES-256 es considerado ampliamente el algoritmo de cifrado simétrico más robusto disponible. Pero hay un problema que no puede resolver por sí solo: ¿cómo comparten dos partes, de forma segura, la clave que desbloquea los datos en primer lugar? Enviar una clave AES-256 por un canal desprotegido anularía por completo el propósito de cifrar los datos.
Ahí es donde entra la criptografía de clave pública. Ambas trabajan en tándem: AES-256 se encarga del trabajo pesado de cifrar los datos en reposo y en tránsito, mientras que los pares de claves pública/privada gestionan el intercambio seguro de claves y la autenticación de identidad. Entender cómo funcionan juntas es fundamental para evaluar las afirmaciones de cifrado de cualquier plataforma, y es directamente relevante para los requisitos de cumplimiento bajo CMMC, FedRAMP y HIPAA.
Resumen ejecutivo
Idea principal: AES-256 (cifrado simétrico) y la criptografía de clave pública/privada (cifrado asimétrico) no son estándares que compitan entre sí, sino capas complementarias que, juntas, ofrecen tanto rendimiento como seguridad para el intercambio de datos sensibles.
Por qué debería importarte: Los marcos de cumplimiento, incluidos CMMC 2.0 y FedRAMP, no solo exigen cifrado: exigen cifrado validado por FIPS con una gestión sólida de claves. Una organización puede implementar AES-256 correctamente y aun así fallar una evaluación si la capa de gestión de claves es débil. Saber cómo trabajan juntos estos dos tipos de cifrado te ayuda a evaluar si la arquitectura de cifrado de una plataforma es genuinamente sólida o si simplemente cumple los requisitos de forma superficial.
Puntos clave
1. AES-256 es cifrado simétrico: la misma clave cifra y descifra los datos.
AES-256 utiliza una única clave de 256 bits tanto para cifrar como para descifrar. Su velocidad y eficiencia computacional lo convierten en la herramienta adecuada para cifrar grandes volúmenes de datos en reposo y en tránsito. El NIST eligió AES como estándar federal de cifrado, y sigue siendo el algoritmo exigido por FIPS 140-3, el referente actual para la validación de módulos criptográficos en el gobierno y las industrias reguladas.
2. La criptografía de clave pública resuelve el problema de distribución de claves que AES-256 no puede.
No se puede enviar una clave AES-256 por un canal sin cifrar. La criptografía de clave pública (también llamada cifrado asimétrico) resuelve esto: una de las partes cifra la clave de sesión AES usando la clave pública de la otra parte, y solo la clave privada correspondiente puede descifrarla. Así es como TLS establece una conexión segura antes de transmitir cualquier dato.
3. Los dos tipos de cifrado trabajan de forma secuencial, no de manera aislada.
En la práctica, la criptografía de clave pública gestiona el saludo inicial (handshake): autentica la identidad e intercambia la clave simétrica. Luego, AES-256 toma el relevo para la transferencia real de datos. Este enfoque híbrido combina las ventajas de seguridad del cifrado asimétrico con las ventajas de rendimiento del cifrado simétrico.
4. El cifrado es tan fuerte como su gestión de claves.
AES-256 con una gestión de claves deficiente no es un sistema seguro. Si las claves de cifrado se almacenan en el mismo servidor que los datos cifrados, una sola brecha expone ambos elementos. Los evaluadores de CMMC examinan la generación, el almacenamiento, la rotación y la destrucción de las claves, no solo si el cifrado está presente. Quién posee y controla las claves determina el verdadero límite de seguridad.
5. Las claves de cifrado propiedad del cliente son el diferenciador real, no el algoritmo en sí.
La mayoría de las plataformas empresariales ofrecen AES-256. Lo que las diferencia es quién controla las claves. Que las claves de cifrado sean propiedad del cliente significa que el proveedor es técnicamente incapaz de descifrar tus datos, incluso ante una solicitud legal. Esa distinción tiene un peso considerable bajo CMMC Nivel 3, FedRAMP High y los requisitos del RGPD posteriores a la sentencia Schrems II.
Qué hace AES-256 y qué no hace
AES-256 es un cifrado de bloque simétrico. Toma el texto plano, lo somete a 14 rondas de sustitución, transposición y operaciones de mezcla usando una clave de 256 bits, y produce un texto cifrado que resulta computacionalmente inviable de revertir sin esa clave. La misma clave descifra los datos.
Es rápido, está ampliamente probado y es el algoritmo que la NSA aprobó para proteger información clasificada. FIPS 140-3, el estándar federal vigente para módulos criptográficos, exige AES para los datos en reposo. Todos los marcos de cumplimiento serios apuntan a él.
Pero AES-256 tiene una limitación estructural: ambas partes necesitan la misma clave. Si cifras datos en tu propio servidor al que solo tú accedes, eso no es un problema. En el momento en que necesitas compartir datos cifrados con otra persona, te enfrentas al problema de la distribución de claves: ¿cómo haces llegar la clave a la otra parte sin exponerla en tránsito?
Ahí es donde entra la criptografía de clave pública.
Cómo funciona la criptografía de clave pública
La criptografía de clave pública utiliza un par de claves vinculadas matemáticamente. La clave pública se distribuye libremente; cualquiera puede tenerla. La clave privada la mantiene en secreto su propietario. Los datos cifrados con la clave pública solo pueden descifrarse con la clave privada correspondiente.
Esto resuelve el problema de distribución. Si quieres enviar una clave sensible a un socio comercial, la cifras usando su clave pública. Solo esa persona puede descifrarla, porque solo ella posee la clave privada correspondiente. La clave pública puede viajar por un canal desprotegido sin riesgo: interceptarla no le da a un atacante nada útil.
El algoritmo RSA es la implementación más extendida de la criptografía de clave pública. Se basa en la dificultad matemática de factorizar números muy grandes, un problema que sigue siendo computacionalmente inviable con la tecnología actual para los tamaños de clave que se usan hoy en día.
La criptografía de clave pública también permite las firmas digitales: el remitente cifra el hash de un mensaje usando su clave privada. Cualquier destinatario puede verificar la firma usando la clave pública del remitente, confirmando tanto la identidad del emisor como que el mensaje no ha sido alterado en tránsito. Esta es la base de la validación de certificados TLS, la firma de código y la autenticación de correo S/MIME.
Cómo funcionan juntas en la práctica
Cada vez que tu navegador se conecta a un sitio HTTPS, ejecuta una versión de esta secuencia:
- El servidor presenta su certificado digital, que contiene su clave pública y está firmado por una Autoridad de Certificación de confianza.
- El cliente verifica el certificado y usa la clave pública del servidor para negociar de forma segura una clave simétrica compartida.
- A partir de ese momento, todos los datos de la sesión se cifran con AES: rápido, eficiente y protegido por una clave que solo poseen las dos partes.
Este es el intercambio de claves Diffie-Hellman, y variantes de este mecanismo sustentan prácticamente todos los protocolos de comunicación segura utilizados hoy en día: TLS, IPsec, SSH y S/MIME siguen el mismo patrón. La criptografía de clave pública autentica e intercambia; AES-256 cifra los datos en sí.
La razón de este relevo es el rendimiento. El cifrado asimétrico es computacionalmente costoso; no resulta práctico para cifrar archivos grandes o flujos sostenidos de datos. AES-256 gestiona el cifrado masivo órdenes de magnitud más rápido. El modelo híbrido obtiene los beneficios de seguridad de ambos enfoques.
Dónde la gestión de claves se convierte en un problema de cumplimiento
Una vez que entiendes que el cifrado opera en dos capas (intercambio de claves y cifrado de datos), queda claro por qué los marcos de cumplimiento no se limitan a preguntar «¿usas AES-256?». Preguntan quién controla las claves, cómo se almacenan, cómo se rotan y qué ocurre cuando se destruyen.
Bajo CMMC 2.0, los controles SC.L2-3.13.8 y SC.L2-3.13.16 exigen protección criptográfica de la CUI en tránsito y en reposo usando módulos validados por FIPS. Los evaluadores de CMMC examinan la documentación de gestión de claves en el Plan de Seguridad del Sistema, no solo el algoritmo utilizado. Un sistema que cifra CUI con AES-256 pero almacena las claves de cifrado en un archivo de configuración en el mismo servidor no es un sistema seguro, y no superará el escrutinio.
La misma lógica se aplica bajo FedRAMP y HIPAA. El puerto seguro (safe harbor) de notificación de brechas de HIPAA solo aplica cuando la PHI estaba cifrada y las claves de cifrado permanecieron seguras. Si un proveedor de nube posee tus claves de cifrado, su compromiso —o una orden legal dirigida a él— podría exponer tus datos aunque AES-256 estuviera implementado.
Por eso las claves de cifrado propiedad del cliente no son una característica premium. Para las organizaciones en industrias reguladas, son un requisito previo para el cumplimiento.
Qué hace que una arquitectura de cifrado sea genuinamente sólida
Evaluar las afirmaciones de cifrado de una plataforma implica ir más allá de «AES-256 en reposo, TLS en tránsito». Las preguntas realmente relevantes son:
¿Quién posee las claves? Las claves gestionadas por el proveedor significan que el proveedor puede descifrar tus datos. Las claves propiedad del cliente significan que no puede hacerlo, y esto es así técnicamente, no solo contractualmente. Si se presenta una citación gubernamental al proveedor, las claves propiedad del cliente lo dejan sin nada que entregar.
¿Qué validación de módulo criptográfico tiene la plataforma? FIPS 140-2 ha sido reemplazado por FIPS 140-3. Una plataforma que aún cita únicamente la validación 140-2 podría no cumplir los requisitos federales actuales para sistemas que manejan CUI o PHI en niveles de sensibilidad más altos.
¿Está protegida la capa de intercambio de claves? TLS 1.0 y 1.1 contienen vulnerabilidades conocidas. La guía actual del NIST exige TLS 1.2 como mínimo, con preferencia por TLS 1.3. Las plataformas que no exigen versiones mínimas de TLS exponen la capa de intercambio de claves, incluso cuando AES-256 protege los datos en sí.
¿Se aplica el cifrado de manera consistente en todos los canales? Una plataforma que cifra el intercambio de archivos pero envía correos en texto claro, o que aplica cifrado a las cargas de archivos pero no al tráfico de API, tiene brechas que generan una exposición real, sin importar el algoritmo utilizado en los canales protegidos.
Cómo aborda Kiteworks el cifrado en toda su infraestructura
Kiteworks implementa cifrado AES-256 para los datos en reposo y TLS 1.2 (con capacidad de exigir TLS 1.3) para los datos en tránsito en todos los canales: correo electrónico seguro, intercambio seguro de archivos, transferencia gestionada de archivos, SFTP y formularios de datos seguros. El módulo criptográfico de la plataforma cuenta con la validación FIPS 140-3 Nivel 1, el estándar vigente, no el 140-2 ya reemplazado.
Kiteworks aplica un doble cifrado: los datos se cifran tanto a nivel de archivo como de disco. Los correos electrónicos se cifran y descifran automáticamente mediante el Email Protection Gateway; los destinatarios usan sus clientes de correo habituales, sin necesidad de software adicional ni capacitación. Todas las transferencias de archivos incluyen una verificación de integridad mediante una huella digital hash MD5.
Sobre la propiedad de las claves: los clientes de Kiteworks son dueños de sus propias claves de cifrado. Kiteworks nunca posee las claves y no puede ser obligado a entregar los datos del cliente, porque es técnicamente incapaz de descifrarlos. Esta arquitectura aborda directamente los escenarios de cumplimiento en los que el control de las claves determina si el cifrado es realmente significativo: CMMC Nivel 3, FedRAMP High y los requisitos de soberanía de datos del RGPD posteriores a Schrems II.
Para las organizaciones que requieren protección adicional de claves, Kiteworks se integra con Módulos de Seguridad de Hardware (HSM) de Thales y AWS Key Management Service: hardware resistente a manipulaciones que impide la extracción de claves incluso desde un servidor totalmente comprometido.
El resultado es una plataforma donde la arquitectura de cifrado —no solo el algoritmo— está diseñada para las industrias reguladas. Kiteworks cubre casi el 90% de los requisitos de CMMC Nivel 2 de forma nativa y cuenta con autorización FedRAMP Moderate con estado High Ready.
Para ver cómo Kiteworks gestiona el cifrado según tus requisitos específicos de cumplimiento, solicita una demostración personalizada.
Preguntas Frecuentes
AES-256 es un cifrado simétrico: la misma clave se utiliza para cifrar y descifrar los datos. Es rápido y eficiente para grandes volúmenes de información, por lo que se ha convertido en el estándar para cifrar archivos y bases de datos. El cifrado de clave pública (o asimétrico) utiliza un par de claves matemáticamente vinculadas: una clave pública para cifrar y una clave privada para descifrar. Se emplea principalmente para el intercambio de claves y las firmas digitales, no para el cifrado masivo de datos. En la práctica, ambos trabajan de la mano: la criptografía de clave pública protege el intercambio de una clave de sesión AES, que luego se encarga de cifrar los datos reales.
AES-256 requiere que ambas partes compartan la misma clave, pero distribuir esa clave de forma segura a través de una red no confiable es un problema que el cifrado simétrico no puede resolver por sí solo. Enviar la clave AES en texto plano la expondría a ser interceptada. La criptografía de clave pública resuelve este problema al permitir que una parte cifre la clave AES usando la clave pública del destinatario; solo la clave privada de este puede descifrarla. TLS utiliza este modelo híbrido para establecer sesiones seguras antes de transmitir cualquier dato.
FIPS 140-3 es el estándar federal para la validación de módulos criptográficos. Establece los requisitos para las implementaciones de hardware y software de algoritmos criptográficos, incluido AES. Contar con la validación FIPS 140-3 no significa simplemente utilizar AES-256; implica que todo el módulo criptográfico —generación, almacenamiento y gestión de claves— ha sido probado y certificado de forma independiente para cumplir con los estándares federales. CMMC Nivel 2 y FedRAMP exigen módulos criptográficos validados por FIPS, no solo algoritmos aprobados por FIPS. FIPS 140-3 sustituye a FIPS 140-2 como el estándar vigente actual.
Cuando el proveedor gestiona las claves, el proveedor de la nube conserva la capacidad técnica de descifrar tus datos, y puede verse obligado a hacerlo por vía legal, incluida la Ley CLOUD de Estados Unidos. Cuando las claves de cifrado son propiedad del cliente, esa capacidad desaparece por completo: el proveedor nunca posee las claves y no puede descifrar los datos sin importar qué requerimiento legal reciba. Para las organizaciones sujetas a CMMC Nivel 3, FedRAMP High o los requisitos de soberanía de datos del RGPD, la diferencia entre gestionar claves y ser propietario de ellas es la diferencia entre un control real de los datos y una garantía contractual que una orden judicial puede anular.
Kiteworks utiliza TLS (que se apoya en la criptografía de clave pública para el intercambio de claves y la autenticación) para proteger todos los datos en tránsito. Para el correo electrónico seguro, Kiteworks es compatible con S/MIME, que emplea infraestructura de clave pública para autenticar a los remitentes y cifrar el contenido de los mensajes de extremo a extremo. La puerta de enlace de protección de correo electrónico de la plataforma automatiza el cifrado y descifrado, de modo que los destinatarios reciben los mensajes en sus clientes de correo habituales sin necesidad de software adicional. Todas las operaciones criptográficas subyacentes se realizan dentro de un módulo validado por FIPS 140-3, y las claves de cifrado permanecen exclusivamente bajo el control del cliente.