En ciberseguridad existe una tentación muy común cuando se empieza:

“Solo voy a probar un poco, no voy a romper nada”.

Herramientas como curl, Postman, Burp o simples peticiones HTTP hacen que testear una web parezca trivial. Sin embargo, aquí aparece una de las lecciones más importantes de toda la profesión:

👉 Que algo sea técnicamente posible no significa que sea legal.

La regla de oro de la ciberseguridad

Nunca pruebes la seguridad de un sistema que no es tuyo sin autorización explícita.

No importa:

• que sea “solo por aprender”
• que no haya daño
• que no se roben datos
• que el fallo sea evidente
• que la petición sea un simple GET

📌 La legalidad no depende de la herramienta ni de la intención, depende del permiso.

¿Qué NO es legal hacer?

No es legal que un estudiante (ni un profesional) pruebe vulnerabilidades en:

• Páginas web “random” de Internet
• APIs públicas que no son suyas
• Paneles /admin, /api/users, /orders?id=2 de terceros
• Aplicaciones reales sin consentimiento del propietario

Aunque:

• solo se cambie un ID
• solo se mire la respuesta
• no se modifique nada
• no se guarde información

📌 Acceder a recursos que no te corresponden ya es un problema legal, aunque el servidor “te deje”.

El error mental más común

“Pero solo hice una petición HTTP…”

Un error muy habitual es pensar que:

• GET = legal
• POST / PUT / DELETE = ilegal

Esto es falso.

La ley no distingue métodos HTTP, distingue:

• quién es el dueño del sistema
• si tienes autorización
• si accedes a información o funciones fuera de tu rol

Un solo GET a un recurso privado puede ser ilegal.
Un DELETE en un entorno autorizado puede ser perfectamente legal.

¿Qué dice la ley?

En España y la Unión Europea, probar sistemas ajenos sin permiso puede encajar en:

• Acceso no autorizado a sistemas informáticos
• Interferencia en sistemas de información
• Tratamiento ilícito de datos personales (si hay datos reales)

Esto se aplica aunque no haya daño, porque el delito no es “romper”, es acceder sin derecho.

¿Cuándo SÍ es legal practicar?

Hay escenarios completamente válidos y profesionales:

✔️ Sistemas propios

• Servidores propios
• Máquinas virtuales
• Docker
• Laboratorios locales
• Infraestructura del centro educativo

✔️ Laboratorios diseñados para ser atacados

Plataformas educativas y entornos vulnerables creados expresamente para practicar.

Aquí hay algo clave:
consentimiento explícito.

✔️ Bug Bounty (con reglas muy claras)

Algunas empresas permiten pruebas, pero:

• solo ciertos dominios
• solo ciertos tipos de ataques
• con límites muy estrictos

No es recomendable como punto de partida para estudiantes.

✔️ Autorización escrita

Un correo, contrato o documento que indique:

• qué se puede probar
• hasta dónde
• en qué condiciones

Esto es lo que separa a un auditor profesional de un aficionado imprudente.

La ciberseguridad no va de ser más listo que el sistema, va de ser responsable con el conocimiento.

Un buen profesional no es quien encuentra más vulnerabilidades,
sino quien sabe cuándo tiene derecho a buscarlas.

La ética no es “relleno académico”:
es una competencia técnica tan importante como saber usar una herramienta.

En seguridad informática hay una idea peligrosa que aparece una y otra vez: “uso HTTPS, así que mis datos están seguros”. Esta frase, tan común como incorrecta, es la puerta de entrada perfecta al OWASP Top 10 – A02: Cryptographic Failures.

Este punto no habla de ataques sofisticados ni de hackers con sudaderas negras. Habla de algo mucho más cotidiano —y mucho más grave—: usar mal la criptografía o no usarla cuando es necesaria.

De “exposición de datos” a “fallos criptográficos”

En ediciones anteriores del OWASP Top 10, este riesgo se conocía como Sensitive Data Exposure. El cambio de nombre a Cryptographic Failures no es un simple ajuste semántico. Es una declaración de intenciones.

El problema real no es que los datos se expongan “por accidente”, sino que:

• Se almacenan sin protección
• Se cifran con algoritmos obsoletos
• Se gestionan claves de forma negligente
• Se confía en mecanismos que no ofrecen seguridad real

Cuando la criptografía falla, la aplicación puede funcionar perfectamente… mientras los datos quedan totalmente expuestos.

Qué es realmente un fallo criptográfico

Un fallo criptográfico no significa que el algoritmo sea débil. En la mayoría de los casos, los algoritmos funcionan exactamente como fueron diseñados. El problema está en cómo los usamos.

Algunos ejemplos habituales:

• Guardar contraseñas en texto plano
• Cifrar contraseñas en lugar de hashearlas
• Usar MD5 o SHA-1 porque “siempre se ha hecho así”
• Reutilizar claves en distintos sistemas
• Incluir secretos directamente en el código fuente
• Pensar que Base64 es cifrado

La criptografía no perdona errores conceptuales. Si se aplica mal, la seguridad es una ilusión.

Cifrado, hashing y codificación: la confusión clásica

Uno de los orígenes más comunes de A02 es no distinguir correctamente entre tres conceptos fundamentales:

Cifrado Es un proceso reversible. Sirve para proteger datos que más adelante deben recuperarse, como información personal o datos almacenados.

Hashing Es un proceso irreversible. Está pensado para verificar, no para recuperar. Por eso es la técnica correcta para almacenar contraseñas.

Codificación No es un mecanismo de seguridad. Base64, por ejemplo, solo transforma datos para facilitar su transporte. Cualquiera puede revertirlo.

Cuando una aplicación mezcla estos conceptos, el resultado suele ser desastroso.

Contraseñas: el punto más frágil del sistema

Las contraseñas merecen un capítulo propio dentro de A02. No porque sean un mecanismo perfecto, sino porque siguen siendo el más usado.

Errores críticos que todavía se ven en producción:

• Contraseñas almacenadas en texto plano
• Contraseñas cifradas con clave reversible
• Hashes rápidos sin salt

La práctica correcta implica:

• Algoritmos diseñados específicamente para contraseñas
• Uso de salt único por usuario
• Coste computacional suficiente para frenar ataques de fuerza bruta

Aquí no hay atajos. Si las contraseñas se gestionan mal, todo el sistema cae detrás.

HTTPS no lo soluciona todo

HTTPS protege los datos en tránsito, pero no garantiza que:

• Se usen versiones seguras de TLS
• Las cookies estén correctamente configuradas
• No haya contenido mixto
• Los datos se almacenen de forma segura en el servidor

Es posible tener un candado verde en el navegador y, aun así, estar filtrando información sensible sin darse cuenta.

HTTPS es una condición necesaria, pero nunca suficiente.

Tokens, sesiones y APIs modernas

Las aplicaciones actuales dependen cada vez más de APIs y tokens de autenticación. Y aquí aparecen nuevos fallos criptográficos:

• Tokens predecibles
• JWT sin firma o mal configurados
• Tokens expuestos en URLs
• Almacenamiento inseguro en el cliente

Muchos de estos errores no rompen la funcionalidad, pero sí la seguridad. El sistema “funciona”, hasta que alguien decide mirarlo con mentalidad de auditor.

Datos sensibles: no todo vale lo mismo

Uno de los errores de diseño más comunes es no clasificar los datos.

No toda la información requiere el mismo nivel de protección, pero hay datos que nunca deberían almacenarse sin medidas criptográficas adecuadas, como:

• Credenciales
• Identificadores personales
• Tokens de acceso
• Información financiera

A esto se suman los grandes olvidados: backups, logs y ficheros temporales, que a menudo contienen más información sensible que la propia base de datos principal.

Pensar como auditor: detectar A02

Detectar fallos criptográficos no siempre requiere herramientas avanzadas. Muchas veces basta con observar:

• Cómo se gestionan las contraseñas
• Qué información aparece en cookies y cabeceras
• Qué algoritmos se usan realmente
• Dónde se almacenan los secretos

La automatización ayuda, pero el criterio humano es insustituible. Un escáner puede avisar; un profesional entiende el impacto.

Buenas prácticas: menos magia, más criterio

La criptografía segura no consiste en usar lo último, sino en usar lo adecuado:

• Algoritmos actuales y bien mantenidos
• Gestión centralizada de secretos
• Separación de responsabilidades
• Decisiones documentadas

La seguridad madura no se basa en trucos, sino en disciplina técnica.

Conclusión

OWASP A02 no trata de romper sistemas. Trata de recordar algo esencial: los datos tienen valor, y protegerlos es una responsabilidad técnica y ética.

La mayoría de los fallos criptográficos no ocurren por falta de herramientas, sino por falta de comprensión. Por eso este punto es clave en cualquier formación técnica: obliga a pensar, a cuestionar y a asumir que la seguridad no es un añadido, sino parte del diseño.

Cuando la criptografía falla, no hay parche que lo arregle después. Solo queda aprender… y hacerlo mejor la próxima vez.

Qué es el Cifrado Simétrico

El cifrado simétrico utiliza una única clave secreta para dos operaciones:

• Cifrar (convertir texto legible en ilegible)
• Descifrar (recuperar el texto original)

Si dos personas comparten la misma clave, ambas pueden leer el mensaje.
Si un atacante consigue la clave, el cifrado deja de proteger.

Conceptos esenciales:

• Texto plano: información legible.
• Texto cifrado: datos transformados matemáticamente.
• Clave: secreto que controla la transformación.
• Algoritmo: función matemática que aplica el cifrado.

El cifrado simétrico es muy rápido, por eso se usa en:

• HTTPS / TLS (Internet)
• Discos cifrados (BitLocker, LUKS)
• VPN
• Bases de datos
• WiFi WPA2/WPA3

El problema central no es el algoritmo.
El problema siempre es: cómo compartes la clave sin que te la roben.

Resultado esperado

El alumno puede explicar:

• Qué es una clave simétrica
• Qué ocurre si se pierde
• Por qué el cifrado depende del secreto

────────────────────────────────

Tipos de Cifrado Simétrico

1. Cifradores de Bloque

Trabajan sobre bloques fijos de datos (por ejemplo 128 bits).

Ejemplos:

• AES (estándar actual)
• DES (obsoleto)
• 3DES (en retirada)
• Blowfish
• Twofish

2. Cifradores de Flujo

Cifran byte a byte como un flujo continuo.

Ejemplos:

• RC4 (inseguro, obsoleto)
• ChaCha20 (moderno, muy rápido)

3. Modos de Operación (muy importante)

Un cifrador de bloque necesita un modo:

• ECB → inseguro (filtra patrones)
• CBC → clásico, seguro si se usa bien
• CFB / OFB → variantes de flujo
• CTR → moderno
• GCM → autenticado (integridad + cifrado)

AES + GCM es el estándar moderno (TLS 1.3).

────────────────────────────────

Preparación del Entorno

Requisitos:

• Linux / macOS / WSL
• OpenSSL
• Terminal

Acción

openssl version

Si aparece una versión → listo.

────────────────────────────────

Crear un Archivo en Texto Plano

echo"Las credenciales del sistema son supersecretas." > secreto.txtcat secreto.txt

Explicación

Este archivo representa:

• contraseñas
• tokens
• datos personales
• secretos de API

Ahora mismo es completamente vulnerable.

────────────────────────────────

La Clave Simétrica

Explicación ampliada

Una clave débil rompe todo el sistema.
Ejemplo de malas claves:

• 123456
• password
• admin2026

Buenas claves:

• largas
• aleatorias
• no reutilizadas

Generar clave fuerte

openssl rand -base6432

Esto genera una clave criptográficamente segura.

────────────────────────────────

Cifrado con AES-256-CBC

openssl enc -aes-256-cbc-salt-in secreto.txt -out secreto.enc

El sistema pedirá contraseña.

Qué significa cada parámetro

• aes-256 → clave de 256 bits
• cbc → modo de bloque
• salt → evita ataques de diccionario
• in → archivo original
• out → archivo cifrado

Resultado

cat secreto.enc

Contenido ilegible → cifrado correcto.

────────────────────────────────

Qué ocurre sin la clave correcta

openssl enc -aes-256-cbc-d-in secreto.enc

Resultado:

• error
• texto corrupto

Explicación

El cifrado moderno no puede romperse sin la clave.
No existe “probar hasta acertar” en tiempo humano si la clave es fuerte.

────────────────────────────────

Descifrado correcto

openssl enc -aes-256-cbc -d -in secreto.enc -out secreto_descifrado.txt
diff secreto.txt secreto_descifrado.txt

Sin diferencias → integridad correcta.

────────────────────────────────

AES-GCM (Cifrado Autenticado)

CBC cifra, pero no protege contra manipulación.
GCM cifra y detecta modificaciones.

openssl enc -aes-256-gcm-salt-in secreto.txt -out secreto_gcm.enc

Si alguien modifica el archivo → el descifrado falla.

Este es el modo usado en:

• TLS 1.3
• HTTPS moderno
• VPN modernas

────────────────────────────────

TEMA 10 — Comparación de Algoritmos

Mensaje clave: AES y ChaCha20 dominan el mundo real.

────────────────────────────────

El Problema del Intercambio de Claves

Para descifrar necesitas:

1. Archivo cifrado
2. Clave secreta

Si envías ambos por el mismo canal → seguridad = 0

Por eso el mundo real usa:

• Criptografía asimétrica
• Intercambio Diffie-Hellman
• TLS

El cifrado simétrico siempre vive acompañado del asimétrico.

────────────────────────────────

OWASP A02: Fallos Criptográficos

Errores comunes reales:

• Guardar datos sin cifrar
• Usar ECB
• Claves en el código
• Claves débiles
• Reutilizar claves
• No usar cifrado autenticado
• No cifrar en tránsito

El cifrado no falla por matemáticas.
Falla por humanos.

────────────────────────────────

Para probar:

Ver algoritmos disponibles

openssl enc -ciphers

Ver cabecera binaria

xxd secreto.enc | head

Academia de la Flota Estelar — División de Seguridad Informática
Nivel: Cadete Técnico
Sistema: USS Horizon
Estado de la misión: ACTIVA

Año estelar 78241.7

La USS Horizon ha detectado interceptaciones de comunicaciones por parte de una facción hostil. El Comando de Seguridad ordena activar cifrado simétrico de grado Federación para proteger:

• Credenciales del sistema
• Comunicaciones internas
• Datos de navegación
• Protocolos de defensa

Tu misión como oficial técnico es implementar cifrado AES-256 y validar la seguridad del sistema.

OBJETIVOS DE LA MISIÓN

El cadete será capaz de:

• Comprender el cifrado simétrico
• Generar claves seguras
• Cifrar información sensible
• Verificar resistencia ante ataques
• Usar AES correctamente
• Entender el problema del intercambio de claves
• Aplicar cifrado autenticado moderno (GCM)

FASE 1 — COMPRENDER LA AMENAZA

Informe del Comando

Las transmisiones sin cifrar pueden ser interceptadas mediante sondas de escucha.
Cualquier mensaje en texto plano es vulnerable.

Conceptos clave

• Texto plano → mensaje legible
• Texto cifrado → mensaje ilegible
• Clave → secreto que controla el cifrado
• Algoritmo → transformación matemática

El cifrado simétrico usa una única clave compartida.

Si el enemigo obtiene la clave → seguridad comprometida.

FASE 2 — PREPARAR EL SISTEMA

Verificar módulo criptográfico OpenSSL.

openssl version

Si responde con versión → módulo activo.

FASE 3 — CREAR MENSAJE SENSIBLE

Simular credenciales del sistema de la nave.

echo "Credenciales núcleo warp: acceso nivel comandante." > mensaje.txt
cat mensaje.txt

Observación: mensaje totalmente legible → inseguro.

FASE 4 — GENERAR CLAVE SEGURA

Las claves débiles destruyen la seguridad.
La Flota exige entropía alta.

Generar clave criptográfica:

openssl rand -base64 32

Guardar la clave en gestor seguro (NO en el archivo).

FASE 5 — CIFRADO AES-256-CBC

Activar cifrado simétrico estándar de la Federación.

openssl enc -aes-256-cbc -salt -in mensaje.txt -out mensaje.enc

Introducir clave cuando se solicite.

Verificar resultado:

cat mensaje.enc

Resultado esperado: datos ilegibles → cifrado activo.

FASE 6 — INTERCEPCIÓN ENEMIGA

Simular intento de descifrado sin clave correcta.

openssl enc -aes-256-cbc -d -in mensaje.enc

Resultado:

• Error de descifrado
• Texto corrupto

Conclusión: sin clave → imposible recuperar datos.

FASE 7 — DESCIFRADO AUTORIZADO

Recuperar mensaje con clave correcta.

openssl enc -aes-256-cbc -d -in mensaje.enc -out mensaje_recuperado.txt
diff mensaje.txt mensaje_recuperado.txt

Resultado: archivos idénticos → integridad confirmada.

FASE 8 — CIFRADO MODERNO (AES-GCM)

El modo CBC cifra pero no detecta manipulación.
El Comando exige cifrado autenticado.

openssl enc -aes-256-gcm -salt -in mensaje.txt -out mensaje_gcm.enc

Si el archivo es alterado → el descifrado fallará.

Este modo protege:

• Confidencialidad
• Integridad
• Autenticidad

FASE 9 — ANÁLISIS TÉCNICO

Tipos de cifrado simétrico

Cifradores de bloque

• AES (estándar Federación)
• DES (obsoleto)
• 3DES (retirada progresiva)

Cifradores de flujo

• ChaCha20 (uso en comunicaciones rápidas)
• RC4 (inseguro, prohibido)

Modos de operación

• ECB → inseguro (filtra patrones)
• CBC → clásico
• CTR → moderno
• GCM → cifrado autenticado (recomendado)

FASE 10 — EL TALÓN DE AQUILES

Para descifrar se necesitan:

1. Archivo cifrado
2. Clave secreta

Problema crítico: ¿cómo compartir la clave sin ser interceptada?

La Flota resuelve esto con:

• Criptografía asimétrica
• Intercambio Diffie-Hellman
• Protocolos TLS

El cifrado simétrico nunca viaja solo.

FASE 11 — ERRORES CRÍTICOS (INFORME OWASP)

Fallos detectados en sistemas comprometidos:

• Datos sin cifrar
• Uso de ECB
• Claves en código fuente
• Claves débiles
• Reutilización de claves
• No usar cifrado autenticado
• Envío de claves por canales inseguros

La criptografía no falla por matemáticas.
Falla por mala ingeniería.

FASE 12 — EXPERIMENTOS OPCIONALES

Ver algoritmos disponibles:

openssl enc -ciphers

Inspeccionar binario cifrado:

xxd mensaje.enc | head

INFORME FINAL DE MISIÓN

El cadete ha:

• Aplicado cifrado simétrico real
• Usado AES correctamente
• Comprobado resistencia sin clave
• Entendido intercambio de claves
• Diferenciado CBC vs GCM
• Identificado errores criptográficos reales

La frontera entre matemática y seguridad… apenas comienza.

La criptografía asimétrica es uno de esos inventos humanos que parecen ciencia ficción pero sostienen la realidad cotidiana. Cada vez que abres una web HTTPS, envías un mensaje seguro, firmas un documento digital o te conectas por SSH, estás usando matemáticas diseñadas para resolver un problema aparentemente imposible: compartir secretos sin compartir el secreto.

En el cifrado simétrico ya viste que dos partes pueden proteger información usando una misma clave. Rápido, eficaz… pero con un punto débil crítico: ¿cómo intercambias esa clave sin que alguien la intercepte? Aquí entra la criptografía de clave pública, una idea brillante basada en funciones matemáticas fáciles de calcular pero extremadamente difíciles de invertir. Gracias a ello, cada entidad puede tener dos claves: una pública que puede compartir con el mundo y una privada que jamás debe revelar. Lo que una cifra, solo la otra puede descifrar; lo que una firma, la otra puede verificar.

Este modelo no solo permite cifrar mensajes. Permite algo mucho más profundo: crear confianza en sistemas donde las partes no se conocen previamente. De aquí nacen las firmas digitales, los certificados, las autoridades de certificación y, en última instancia, el funcionamiento seguro de Internet mediante TLS. Sin criptografía asimétrica no existirían el comercio electrónico, la identidad digital, ni la mayoría de servicios que hoy consideramos normales.

En este tema no solo aprenderás comandos. Comprenderás cómo se construye un canal seguro desde cero: cómo se generan identidades criptográficas, cómo se cifra para un destinatario concreto, cómo se garantiza que un mensaje no ha sido alterado, y cómo una infraestructura de certificados permite confiar en claves públicas desconocidas. Es el paso donde la seguridad deja de ser “ocultar datos” y se convierte en demostrar identidad, integridad y autenticidad en un entorno hostil.

Limitación del cifrado simétrico:

• Necesita compartir clave secreta
• Si se intercepta → seguridad rota

Problema fundamental:

¿Cómo compartir un secreto sin compartirlo?

Solución matemática:
Criptografía de clave pública

Cada usuario posee:

• Clave pública → se puede compartir
• Clave privada → nunca se revela

Lo cifrado con una solo puede descifrarse con la otra.

Resultado esperado:
El alumno comprende la diferencia simétrico vs asimétrico.

Conceptos Fundamentales

Conceptos clave:

• Par de claves (Key Pair)
• Clave pública
• Clave privada
• Cifrado
• Descifrado
• Firma digital
• Verificación
• No repudio
• Confianza
• Certificados

Idea central:
La clave pública cifra o verifica
La clave privada descifra o firma

Fundamento Matemático (Nivel Conceptual)

La criptografía asimétrica usa funciones:

• Fáciles de calcular
• Extremadamente difíciles de invertir

Ejemplo conceptual:

Multiplicar primos grandes → fácil
Factorizar resultado → extremadamente difícil

Este principio sostiene:

• RSA
• Diffie-Hellman
• ECC

Algoritmos Asimétricos Principales

RSA

Basado en factorización de números grandes.
Usado para:

• Cifrado
• Firma digital
• TLS clásico

Diffie-Hellman

Permite generar una clave compartida sin enviarla.
Base del intercambio seguro.

ECC (Elliptic Curve Cryptography)

Versión moderna y eficiente.
Usada en:

• TLS moderno
• Blockchain
• SSH moderno
• Certificados

Resultado esperado:
El alumno distingue funciones de cada algoritmo.

Generación de Claves (Práctica)

Objetivo: crear identidad criptográfica.

Ejemplo:

openssl genrsa -out privada.pem 2048
openssl rsa -in privada.pem -pubout -out publica.pem

Conceptos enseñados:

• Tamaño de clave
• Seguridad vs rendimiento
• Protección de clave privada

Cifrado con Clave Pública

Escenario:

Alice quiere enviar mensaje seguro a Bob.

Proceso:

1. Bob genera claves
2. Bob comparte clave pública
3. Alice cifra con clave pública de Bob
4. Solo Bob puede descifrar

Concepto:
Cualquiera puede cifrar, solo el dueño puede leer

Firma Digital

Proceso:

1. Emisor firma con su clave privada
2. Receptor verifica con clave pública

Garantiza:

• Autoría
• Integridad
• No repudio

Uso real:

• Software firmado
• Certificados
• Emails seguros
• Blockchain
• Documentos legales

Intercambio de Claves Seguro (Diffie-Hellman)

El mayor avance criptográfico.

Permite:

• Generar clave simétrica
• Sin transmitirla
• Incluso con atacante escuchando

Esto es lo que hace TLS.

Concepto clave:
El asimétrico no cifra grandes datos, crea la clave simétrica.

Criptografía Híbrida (Cómo funciona TLS)

En el mundo real:

1. Asimétrico → intercambia clave
2. Simétrico → cifra datos (rápido)

Esto es:

• HTTPS
• VPN
• SSH
• TLS
• Internet seguro

Certificados Digitales

Problema:

¿Cómo sé que una clave pública es auténtica?

Solución:

Autoridades de Certificación (CA)

Un certificado vincula:

• Identidad
• Clave pública
• Firma de una CA

Conceptos:

• X.509
• Cadena de confianza
• Root CA
• Certificado autofirmado
• Validación

Ataques contra Criptografía Asimétrica

• Robo de clave privada
• MITM
• Certificados falsos
• Claves débiles
• Mala implementación
• RNG débil
• Padding attacks (conceptual)

Mensaje:
La criptografía no falla por matemáticas → falla por humanos.

OWASP y Criptografía

Relación directa con:

OWASP A02 — Cryptographic Failures

Errores reales:

• Claves expuestas
• Sin validación de certificados
• Uso de RSA débil
• Sin forward secrecy
• Mala generación de claves

Recomendaciones

• Generar par de claves
• Cifrar mensaje con clave pública
• Firmar archivo
• Verificar firma
• Crear certificado autofirmado
• Simular TLS
• MITM conceptual
• Ver handshake TLS con Wireshark

Conexión con el Mundo Real

Esto protege:

• HTTPS
• SSH
• VPN
• Git firmado
• Docker firmado
• Identidad digital
• Blockchain
• Infraestructura crítica

Sin criptografía asimétrica → Internet no existiría.

Comparativa — Clave Simétrica vs Clave Asimétrica

TLS = combinación de ambas (criptografía híbrida)

Simétrica = rapidez para proteger datos

Asimétrica = confianza e identidad

MISIÓN DE LA FLOTA ESTELAR

CANAL SEGURO — CRIPTOGRAFÍA ASIMÉTRICA + FIRMA + CERTIFICADOS (OpenSSL)

Unidad: USS Horizon — División de Comunicaciones Seguras
Nivel: Cadete Técnico
Objetivo general: establecer un canal de comunicación confiable usando clave pública/privada, firma digital, y certificado.

PARTE 1 — “IDENTIDAD CRIPTOGRÁFICA” (Par de claves)

FASE 1 — Crear carpeta de misión

mkdir-p mision_canal_seguro && cd mision_canal_seguro

FASE 2 — Generar clave privada del oficial Bob (2048 bits)

Narrativa: Bob es el oficial de comunicaciones. Su clave privada es el “código genético” de su identidad.

openssl genrsa -out bob_privada.pem 2048

Comprobación rápida (sin mostrarla entera):

openssl rsa -in bob_privada.pem -check-noout

FASE 3 — Obtener la clave pública de Bob

Narrativa: esta es la clave que Bob puede compartir con toda la Flota.

openssl rsa -in bob_privada.pem -pubout-out bob_publica.pem

Verla en modo humano:

openssl rsa -pubin-in bob_publica.pem -text-noout

✅ Resultado esperado: los alumnos ven que la pública se puede inspeccionar sin revelar la privada.

PARTE 2 — “CIFRADO CON CLAVE PÚBLICA” (Confidencialidad)

FASE 4 — Crear mensaje secreto de Alice

echo "Coordenadas del punto de encuentro: Sector 7G. Acceso nivel Alfa." > mensaje_alice.txt
cat mensaje_alice.txt

FASE 5 — Cifrar para Bob usando su clave pública

IMPORTANTE (realidad): RSA no se usa para cifrar grandes datos. Aquí lo usamos con un mensaje pequeño para entender el concepto.

openssl pkeyutl -encrypt -pubin -inkey bob_publica.pem -in mensaje_alice.txt -out mensaje_para_bob.bin

Ver que es ilegible:

xxd mensaje_para_bob.bin | head

✅ Resultado: datos binarios “ruido”.

FASE 6 — Descifrar con la clave privada de Bob

openssl pkeyutl -decrypt -inkey bob_privada.pem -in mensaje_para_bob.bin -out mensaje_descifrado.txt
cat mensaje_descifrado.txt

✅ Resultado esperado: el texto original vuelve intacto.

Aprendizaje clave:

• Cualquiera con la pública puede cifrar para Bob
• Solo Bob con la privada puede leerlo

PARTE 3 — “FIRMA DIGITAL” (Integridad + Autoría)

Ahora el enemigo puede intentar modificar mensajes. La Flota exige que cada mensaje vaya firmado.

FASE 7 — Alice firma un mensaje

Primero Alice genera sus claves (identidad propia):

openssl genrsa -out alice_privada.pem 2048
openssl rsa -in alice_privada.pem -pubout -out alice_publica.pem

Mensaje oficial:

openssl dgst -sha256 -sign alice_privada.pem -out orden.firma orden.txt

FASE 8 — Crear el hash y firmarlo (firma con clave privada)

openssl dgst -sha256-sign alice_privada.pem -out orden.firma orden.txt

✅ “orden.firma” es la firma digital.

FASE 9 — Verificar la firma con la clave pública

openssl dgst -sha256-verify alice_publica.pem -signature orden.firma orden.txt

✅ Resultado esperado: Verified OK

FASE 10 — Simular sabotaje (modificación del mensaje)

echo "Orden de misión: desactivar escudos y abrir bahía de carga." > orden.txt
openssl dgst -sha256 -verify alice_publica.pem -signature orden.firma orden.txt

✅ Resultado esperado: Verification failure

Aprendizaje clave:

• La firma no cifra (no oculta).
• La firma garantiza que el mensaje no fue modificado y que viene de quien dice venir.

PARTE 4 — “CERTIFICADOS” (Confianza en la clave pública)

Aquí está la pregunta mortal:
¿cómo sabe Bob que la clave pública de Alice es realmente de Alice y no del enemigo?

Respuesta: certificados.

Vamos a simular una mini-PKI de la Flota (una CA).

FASE 11 — Crear la CA de la Flota Estelar

CA = Autoridad de Certificación (el “notario” criptográfico).

Clave privada de la CA:

openssl genrsa -out starfleet_ca_privada.pem 4096

Certificado autofirmado de la CA (válido 365 días):

openssl req -x509 -new -key starfleet_ca_privada.pem -sha256 -days 365 -out starfleet_ca.crt \
-subj "/C=ES/O=Starfleet Academy/OU=Security Division/CN=Starfleet Root CA"

Ver certificado:

openssl x509 -in starfleet_ca.crt -text-noout | head -n40

FASE 12 — Alice solicita un certificado (CSR)

CSR = Certificate Signing Request (petición de certificado).

openssl req -x509 -new -key starfleet_ca_privada.pem -sha256 -days 365 -out starfleet_ca.crt \
-subj "/C=ES/O=Starfleet Academy/OU=Security Division/CN=Starfleet Root CA"

FASE 13 — La CA firma el certificado de Alice

openssl x509 -req -in alice.csr -CA starfleet_ca.crt -CAkey starfleet_ca_privada.pem \
-CAcreateserial -out alice_cert.crt -days 365 -sha256

Ver contenido:

openssl x509 -in alice_cert.crt -text-noout | head -n60

FASE 14 — Verificar que el certificado de Alice “cuelga” de la CA

openssl verify -CAfile starfleet_ca.crt alice_cert.crt

✅ Resultado esperado: alice_cert.crt: OK

Aprendizaje clave:

• Ahora Bob no confía “porque sí” en la clave pública de Alice.
• Confía porque la CA de la Flota la certifica.

PARTE 5 — “HÍBRIDO” (Cómo funciona Internet de verdad)

Verdad del universo:
El asimétrico es lento para datos grandes.
Se usa para intercambiar/validar una clave simétrica, y luego se cifra todo con AES/ChaCha20.

Mini-demostración conceptual (sin meternos aún en DH real)

1. Alice y Bob se validan con certificados (asimétrico)
2. Se acuerda una clave de sesión (simétrica)
3. Todo el tráfico va con AES-GCM / ChaCha20-Poly1305

Eso es TLS.

INFORME FINAL (lo que tienes que entregar)

1. Capturas o salida de:

• creación de claves
• cifrado/descifrado RSA
• firma y verificación (OK)
• verificación fallida tras manipulación
• creación de CA
• emisión del certificado de Alice
• verificación openssl verify

2. Explicación breve:

• diferencia cifrado vs firma
• por qué se necesitan certificados
• por qué TLS es híbrido

OPCIONALES (Modo “Cadete con rango”)

A) Ver handshake TLS real con Wireshark (si tienes tiempo)

• abrir un sitio HTTPS
• filtrar tls y ver certificados, cipher suite, etc.

B) Pasar a ECC

• generar claves con curvas elípticas y comparar tamaños

C) Forward secrecy (conceptual)

• por qué DH/ECDHE evita que roben sesiones antiguas si se filtra una clave

Registro del Capitán:

“Cadete, hoy no solo has cifrado un mensaje. Has creado confianza en un universo hostil.
La seguridad no es ocultar información: es demostrar identidad, detectar manipulación y sobrevivir a la interceptación.”