Criptografía aplicada
Objetivo de aprendizaje: Comprender los mecanismos criptográficos fundamentales que protegen la confidencialidad, integridad y autenticidad de los datos, y saber aplicarlos concretamente en el diseño de un sistema.
Imagina que envías tu contraseña a un servidor por internet. Sin protección, cualquier dispositivo entre tú y el servidor puede leerla: tu router, el router del proveedor de internet, el del centro de datos. La criptografía es la herramienta que hace que esa información sea ilegible para quien no tiene la clave correcta, y también la que te permite saber quién escribió un mensaje y si alguien lo cambió en el camino.
Para un ingeniero de ciberseguridad, la criptografía funciona como una caja de herramientas más que como una rama de las matemáticas. Lo que necesitas saber de cada herramienta es qué hace, cuándo usarla y qué pasa si la usas mal. En la clase 02 ya usaste dos de ellas con tus manos, el hash y el cifrado con AES; hoy llegan las que responden una pregunta distinta, que es con quién estás hablando.
Apertura: la primera clave
En el laboratorio de la clase 02 cifraste un mensaje con AES y comprobaste que, si cambias un solo carácter de la clave, lo que sale es basura. Esa es la idea del cifrado simétrico: la misma clave cierra y abre, y quien no la tiene no puede leer. En la clase 04 escribiste «cifrar» y «firmar» como controles en tu tabla de riesgos sin saber todavía cómo funcionan por dentro; hoy les llega el mecanismo.
El cifrado simétrico deja un problema sin resolver. Supón que estás en la Wi-Fi gratuita de un centro comercial y quieres mandarle a tu banco un mensaje cifrado con AES. El banco necesita la misma clave que tú para leerlo, y hasta ahora nunca se han comunicado. En la clase 03 viste que una red inalámbrica abierta puede haberla montado alguien con un nombre creíble, de modo que todo lo que envíes pasa primero por su equipo. Si le mandas la clave al banco por esa red, el dueño de la red también la tiene. Si no se la mandas, el banco no puede leer nada.
(Situación hipotética, construida para plantear el problema; no describe ningún banco ni centro comercial concreto.)
Este es el problema de la distribución de claves. La explicación que sigue presenta la idea que lo resuelve, y el resto de la clase es comprobar con tus manos qué garantiza esa idea y qué deja sin garantizar.
Explicación: par de claves, firma, certificado y TLS
Lo que ya sabes: cifrar con una clave compartida
En la clase 02 trabajaste con dos herramientas que hoy se dan por conocidas. El hash convierte cualquier texto en una huella de tamaño fijo, y un cambio mínimo en el texto produce una huella completamente distinta (el efecto avalancha que viste en CyberChef). El cifrado simétrico, con AES como estándar actual, usa la misma clave para cifrar y para descifrar.
Los algoritmos que usaste son públicos, y es así a propósito: cualquiera puede leer cómo funciona AES. En 1883 Auguste Kerckhoffs escribió que un sistema de cifrado debe seguir siendo seguro aunque el enemigo conozca el aparato, de modo que todo el secreto quede en la clave (fuente). Un algoritmo secreto que se filtra deja de servir para siempre, mientras que una clave filtrada se cambia. La seguridad, entonces, depende de que la clave sea secreta y suficientemente larga. Una clave de 128 bits admite 2¹²⁸ valores, unos 3,4 × 10³⁸; un computador hipotético que probara un trillón (10¹⁸) de claves por segundo tardaría del orden de 10¹³ años en recorrerlas todas, unas 780 veces la edad estimada del universo (unos 13 800 millones de años). Es una cuenta que puedes rehacer tú mismo.
El par de claves
La salida al problema de la apertura es usar dos claves distintas que se fabrican juntas, un par de claves. La clave pública se le puede entregar a cualquiera, incluso publicarse en una página web. La clave privada nunca sale de su dueño. Las dos están relacionadas de tal forma que lo que se cifra con la clave pública solo puede descifrarse con la clave privada correspondiente, y conocer la pública no permite deducir la privada.
Vuelve a la Wi-Fi del centro comercial. Si el banco te entrega su clave pública, tú puedes cifrar con ella una clave simétrica nueva y mandarla por la red abierta. El dueño de la red ve pasar el mensaje, pero no puede abrirlo, porque para eso haría falta la clave privada del banco, que nunca viajó. Esto es el cifrado asimétrico, y resuelve la distribución de claves sin necesitar un canal seguro previo.
Tiene un costo. Las operaciones con el par de claves son muchísimo más lentas que las del cifrado simétrico, así que no se usan para cifrar grandes volúmenes de datos. Por eso, en la práctica, el par de claves se usa para ponerse de acuerdo en una clave simétrica, y esa clave simétrica cifra todo lo demás.
La firma digital
El mismo par de claves sirve para algo más que ocultar. Si el dueño de la clave privada la usa para calcular un valor sobre el hash de un documento, cualquiera que tenga su clave pública puede comprobar dos cosas: que ese valor solo pudo producirlo quien tiene la clave privada, y que el documento no cambió después, porque cualquier cambio altera el hash y la comprobación falla. Ese valor es la firma digital. Quien firma usa su clave privada; quien verifica usa la pública.
La firma sostiene tres de los principios que viste en la clase 02: la integridad del documento, la autenticación de quien lo firmó y el no repudio, porque el firmante no puede negar después un valor que solo su clave privada podía producir. Lo que la firma no hace es ocultar nada: un documento firmado se sigue pudiendo leer.
La firma digital no es una curiosidad de laboratorio. En Colombia la define la Ley 527 de 1999 como un valor que se adhiere a un mensaje de datos y que permite determinar que se obtuvo exclusivamente con la clave del iniciador y que el mensaje no se modificó después, que es casi palabra por palabra la integridad y la autenticación que viste en la clase 02. Y cada factura electrónica que emite un negocio colombiano lleva la firma digital del facturador, porque así lo exige la DIAN (Resolución 000165 de 2023). Si alguna vez recibiste una factura electrónica por correo, tuviste en las manos un documento firmado digitalmente.
Una firma digital no oculta nada: el documento firmado se sigue pudiendo leer. ¿Qué gana entonces la DIAN exigiendo que cada factura electrónica vaya firmada, si la factura viaja legible?
Certificados y autoridades de certificación
El par de claves resuelve cómo hablar en privado con alguien a quien nunca le has hablado, pero abre una pregunta nueva, que es de quién es la clave pública que acabas de recibir. En la Wi-Fi del centro comercial, cuando tu navegador le pide al banco su clave pública, quien responde primero es el equipo del dueño de la red. Si ese equipo te entrega su propia clave pública diciendo que es la del banco, vas a cifrar todo con cuidado, con un algoritmo impecable, hacia la persona equivocada. Él lo descifra, lo lee, lo vuelve a cifrar con la clave verdadera del banco y lo reenvía, y ninguna de las dos puntas nota nada. Ese es el ataque de intermediario que la clase 03 dejó nombrado, y es la razón por la que cifrar la conexión no alcanza si no sabes con quién la cifraste.
Un certificado digital es la respuesta a esa pregunta. Es un documento que dice «esta clave pública pertenece a este dominio», firmado por una autoridad de certificación (CA, por sus siglas en inglés), una organización cuyo trabajo es comprobar esa pertenencia antes de firmar. Tu navegador y tu sistema operativo traen de fábrica una lista corta de autoridades raíz en las que confían, y casi nunca son ellas las que firman directamente el certificado de un sitio: una raíz firma a una autoridad intermedia y la intermedia firma al sitio. A ese conjunto de autoridades, certificados y reglas se le llama infraestructura de clave pública (PKI).
Cuando visitas una página por HTTPS, el navegador recorre esa cadena hacia arriba hasta llegar a una raíz de su lista, comprueba que el certificado no esté vencido y comprueba que el dominio que aparece en él sea el mismo que escribiste. Si cualquiera de las tres comprobaciones falla, te muestra una advertencia en vez de la página.
Si el navegador comprueba tres cosas del certificado (cadena, vigencia y dominio), ¿cuál de las tres crees que falla con más frecuencia en sitios reales, y cuál sería la más peligrosa de ignorar?
TLS y HTTPS: todo junto, y lo que dice el candado
HTTPS es la web de siempre (HTTP) protegida por un protocolo llamado TLS. Cuando tu navegador abre un sitio por HTTPS, las piezas de hoy entran juntas, y vistas de forma simplificada se ordenan así. El servidor presenta su certificado; el navegador hace las tres comprobaciones; si pasan, cliente y servidor usan criptografía asimétrica para acordar (negociar) una clave de sesión temporal sin que nadie más pueda conocerla, y a partir de ahí todo el tráfico se cifra con esa clave simétrica, que es rápida. El proveedor de internet, o el dueño de la Wi-Fi del centro comercial, solo ve datos cifrados.
El candado de la barra de direcciones dice dos cosas: que la conexión está cifrada y que el certificado fue emitido para ese dominio por una cadena en la que tu navegador confía. No dice nada sobre las intenciones de quien está al otro lado. Un sitio de phishing puede sacar un certificado válido para su propio dominio con la misma facilidad que un banco, y según el equipo de seguridad de Chrome casi todos los sitios de phishing usan HTTPS. En un estudio de 2021, ese mismo equipo encontró que solo el 11 % de los participantes entendía qué significa exactamente el candado, y por eso desde Chrome 117, en septiembre de 2023, la barra de direcciones muestra un ícono neutro de ajustes en su lugar (fuente).
TLS también tiene versiones, y las viejas envejecen igual que los algoritmos. Así como MD5 y SHA-1 ya no se consideran seguros para proteger nada, las versiones 1.0 y 1.1 de TLS fueron declaradas obsoletas en 2021 (RFC 8996), aunque muchos servidores todavía las acepten y la conexión «funcione».
La profundidad de todo esto está escrita para cuando la quieras leer. La lectura disponible «Cómo funcionan las herramientas: simétrico, asimétrico, hash y firma» desarrolla el catálogo de algoritmos, el contexto de Kerckhoffs y el caso de la primera colisión de SHA-1, publicada en 2017 (fuente). La lectura disponible «Certificados, TLS y el ataque de intermediario» desarrolla la cadena de confianza completa, quién decide qué autoridades raíz entran en la lista de tu navegador, por qué revocar un certificado no es una garantía perfecta y cómo se acuerda la clave de sesión.
Laboratorio: una firma que se rompe y cinco conexiones que fallan
Cada grupo hace dos cosas con herramientas del navegador. Primero comprueba una firma digital preparada de antemano y la ve fallar cuando cambia una sola cifra del mensaje o cuando la verifica con la clave de otro firmante. Después abre una página de badssl.com, un sitio público que existe precisamente para mostrar conexiones defectuosas a quien está aprendiendo, y averigua cuál de las comprobaciones del navegador falló. Las variantes de badssl.com son inofensivas y puedes pasar sus advertencias; ese permiso vale solo para ese sitio y para este ejercicio. En cualquier otro sitio, una advertencia de certificado es una señal para detenerte.
La firma se comprueba en CyberChef, la misma herramienta de la clase 02, que trae operaciones para generar pares de claves RSA, firmar y verificar. El mensaje firmado es una nota de la «Oficina de Registro» sobre la estudiante «Ana Gómez». (Caso ficticio: la oficina y la estudiante no existen y fueron creadas para el ejercicio.)
Puesta en común
Cada uno de los cinco grupos abrió una variante distinta, así que la clase arma entre todos una tabla con una columna por variante de badssl.com (vencido, dominio equivocado, autofirmado, raíz no confiable y sin HTTPS) y cuatro filas: el código de error que mostró el navegador, la comprobación que falló, si la conexión quedó cifrada y qué podría hacer un intermediario con ese mismo defecto. Leída de corrido, esa tabla muestra que casi todas las advertencias aparecen sobre conexiones que sí están cifradas, y que dos defectos distintos pueden producir el mismo mensaje. Esas diferencias entre columnas son el material del debrief.
Debrief y cierre: qué herramienta para qué problema
Qué da cada mecanismo, y qué no da
En el laboratorio de la clase 02 empezaste una tabla que relaciona cada mecanismo con los principios de CIAAN, con tres filas: hash, salt con hash lento y cifrado simétrico. Hoy se completa con los mecanismos nuevos y con una columna que casi nunca se escribe y que evita los errores más caros, la de lo que cada mecanismo no da.
| Mecanismo | Principio que sostiene | Lo que no da |
|---|---|---|
| Cifrado simétrico (AES) | Confidencialidad | Por sí solo no garantiza que el mensaje no se haya alterado, ni dice quién lo envió |
| Hash (SHA-256) | Integridad, si el hash de referencia llega por un canal confiable | No autentica a nadie: cualquiera puede recalcular el hash de un documento que alteró |
| Cifrado asimétrico | Confidencialidad sin canal previo | Es lento, y no dice de quién es la clave pública que usaste |
| Firma digital | Integridad, autenticación del firmante y no repudio | No oculta nada: el documento firmado se sigue leyendo |
| Certificado digital | Autenticación de la clave pública de un dominio | No dice nada sobre las intenciones del dueño del dominio |
| TLS (HTTPS) | Confidencialidad e integridad de la conexión, y autenticación del servidor | No protege lo que el sitio haga con tus datos una vez los recibe |
Vuelve a las propuestas de la apertura. Todas intentaban mandar la clave simétrica por otro camino, y todas necesitaban un canal que el dueño de la red no controlara. El par de claves resuelve ese problema, y el certificado resuelve el problema que el par de claves deja abierto. El límite de todo el sistema aparece cuando la autoridad que firma el certificado es la que falla: en ese caso el navegador no muestra ninguna advertencia, porque la cadena es válida. Eso pasó en 2011 con DigiNotar, una autoridad de certificación neerlandesa (fuente), y el caso está desarrollado en la lectura disponible sobre certificados.
Cuándo usar cada herramienta y los errores más comunes
La regla de decisión cabe en pocas líneas si se parte del problema y no de la herramienta. Para los datos que viajan por una red, la respuesta es TLS. Para los datos guardados en un disco o en una base de datos, es cifrado simétrico, con la clave guardada lejos de los datos que protege. Para las contraseñas, un hash lento con salt, como bcrypt o Argon2: lo viste en la clase 02 y en la lectura de la clase 05, y conviene recordar que el salt y la lentitud resuelven problemas distintos, porque el salt frustra las tablas precomputadas (rainbow tables) y la lentitud frena la fuerza bruta. Para demostrar quién produjo un documento y que no cambió, firma digital. Para saber de quién es una clave pública, un certificado.
Los errores comunes de la lista que sigue salen de romper esa regla. Inventar un algoritmo propio contradice a Kerckhoffs: la seguridad de un algoritmo público viene de décadas de gente intentando romperlo, y un algoritmo casero no tiene ese respaldo. Seguir usando algoritmos o protocolos obsoletos, como MD5, SHA-1 o TLS 1.0 y 1.1, deja abierta una puerta que el resto del mundo ya cerró. Guardar contraseñas con un hash rápido, aunque lleve salt, deja que un atacante con la base de datos pruebe contraseñas a enorme velocidad. Acostumbrar a los usuarios a pulsar «Continuar» ante una advertencia de certificado, o desactivar la verificación de certificados en un sistema porque en pruebas estorbaba, desarma justo la comprobación que detiene al intermediario, como viste en el laboratorio. Y guardar la clave privada o la clave simétrica junto a los datos que protege equivale a dejar la llave pegada a la puerta.
Cada herramienta criptográfica responde una pregunta distinta, y los errores más caros vienen de usar una para responder la pregunta de otra. El cifrado responde quién puede leer, la firma responde quién produjo esto y si cambió, y el certificado responde de quién es esta clave. TLS las combina para que una conexión web tenga las tres respuestas a la vez, y el candado resume solo dos de ellas, que la conexión está cifrada y que el certificado corresponde al dominio. Si fue buena idea escribir tus datos en esa página es una pregunta que ningún mecanismo de hoy contesta por ti.
La lectura disponible «Decidir qué proteger, errores frecuentes y glosario» convierte esta regla en un procedimiento: parte del dato, pregunta qué le puede pasar y qué principio de CIAAN está en juego, y solo entonces elige el mecanismo. Las otras dos lecturas, «Cómo funcionan las herramientas: simétrico, asimétrico, hash y firma» y «Certificados, TLS y el ataque de intermediario», desarrollan con calma cómo funcionan las herramientas y cómo se sostiene la cadena de confianza de los certificados, incluido el caso de DigiNotar. Ninguna de las tres se pide para la próxima sesión.
Preguntas de reflexión
-
Antes de abrir badssl.com, tu grupo escribió si una conexión con advertencia de certificado está cifrada o no. Di qué predijeron. Luego nombra la variante que le tocó a tu grupo, copia literal el código de error que mostró el navegador e indica cuál navegador usaste. Explica, con lo que viste en la dirección después de pasar la advertencia, por qué el navegador advierte sobre una conexión que en cuatro de las cinco variantes sí estaba cifrada. Si tu grupo era el de
http.badssl.com, explica en cambio por qué tu variante no tenía ninguna de las tres comprobaciones que hacer. -
Toma un documento físico que tengas en tu poder y cuya validez dependa de que alguien responda por él: tu diploma o acta de grado de bachiller, un certificado de notas de tu colegio, un documento autenticado en notaría. Nombra el tipo de documento (sin datos personales) y copia de él lo que solo se ve teniéndolo: qué cargos o entidades lo firman o sellan, si trae un código o sello de verificación de otra entidad y en qué fecha se expidió. Con esos datos, traza su cadena de confianza como si fuera la de un certificado: ¿qué firma o sello de tu documento hace el papel del sitio, cuál el de la autoridad intermedia y quién sería la raíz? Para ese documento concreto, ¿qué equivaldría a un certificado vencido y qué a un dominio equivocado? Describe cómo sería un caso equivalente a DigiNotar en la cadena de tu documento y quién saldría perjudicado.
-
Un atacante registra un dominio que imita el de tu banco cambiando una sola letra y obtiene para él un certificado perfectamente válido. Tu navegador no muestra ninguna advertencia. Explica cuáles de las tres comprobaciones que hace el navegador pasaron y por qué ninguna podía detectar el engaño. Luego toma posición: ¿deberían las autoridades de certificación negarse a emitir certificados para dominios que se parecen a los de entidades financieras? Defiende tu posición y escribe el contraargumento más fuerte que te podrían hacer.
-
Busca un documento que tú o tu familia hayan recibido con firma digital: una factura electrónica, un certificado académico descargado, un extracto bancario en PDF. Nombra el tipo de documento y la entidad que lo emitió (sin ningún dato personal). Copia literal el nombre del archivo que recibiste y la frase, el campo o la leyenda del documento o del correo que menciona la firma; si no encuentras ninguna mención, dilo y describe dónde buscaste. Con la tabla de CIAAN que completamos en el debrief, explica qué principio le garantiza esa firma a quien recibe el documento y cuál no le garantiza, y di qué pasaría si el emisor se negara después a reconocer ese documento.
-
En la Tarea A, cambiar el
3.2por un4.5rompió la verificación. Imagina ahora que el atacante no toca solo el mensaje: también reemplaza, en el aula virtual, la clave pública que la Oficina de Registro publicó por una clave suya, y firma el mensaje alterado con su propia clave privada. Explica si la verificación en CyberChef pasaría, qué paso de la Tarea A reproduce justamente este engaño, y qué mecanismo de los que vimos hoy tendría que existir para que tú pudieras detectarlo. ¿Qué suposición tendrías que aceptar para confiar en ese mecanismo?
Laboratorio práctico: PKI y TLS en la práctica
Tiempo estimado: 60 minutos (trabajo individual fuera de la sesión) Requisitos: Navegador web (Chrome o Firefox) Herramientas: El propio navegador, SSL Labs y CyberChef
En el laboratorio de la clase 02 trabajaste hash y AES; en la sesión de hoy verificaste una firma y viste fallar certificados en badssl.com. Este laboratorio lleva lo mismo a sitios reales que usas y te pide firmar algo tuyo. Todo lo que pide tuvo su primera aparición en la sesión; la fecha de entrega la publica el profesor en el aula virtual, y ninguna parte de este laboratorio es insumo de la clase 09.
Objetivo
Inspeccionar certificados digitales reales, relacionar cada campo con las comprobaciones que hace el navegador, evaluar la calidad de la configuración TLS de dos sitios y producir y verificar tu propia firma digital.
Parte 1: Anatomía de un certificado
Escoge dos sitios HTTPS: uno que uses a diario y uno colombiano, de una entidad pública (dominio .gov.co) o de una entidad financiera colombiana. Trabajas con los mismos dos sitios en la Parte 2.
Ejercicio 1.1: Campos del certificado
Haz clic en el ícono que aparece a la izquierda de la dirección y abre la vista completa del certificado:
- Chrome: «La conexión es segura» → «El certificado es válido» → pestaña «Detalles»
- Firefox: «Conexión segura» → «Más información» → «Ver certificado»
Toma una captura de pantalla de cada certificado en la que se vea la fecha de tu computador, y completa esta tabla para cada sitio:
| Campo | Valor que encontraste | ¿Qué comprobación del navegador usa este campo? (cadena, vigencia, dominio o ninguna) |
|---|---|---|
| Emitido para (Subject CN) | ||
| Emitido por (Issuer) | ||
| Válido desde | ||
| Válido hasta | ||
| Algoritmo de firma | ||
| Tamaño de clave pública | ||
| Subject Alternative Names (SANs) |
Para el campo Subject Alternative Names: ¿aparece en la lista el dominio exacto que escribiste en la barra de direcciones? Copia otros dos dominios que cubra el certificado.
Ejercicio 1.2: La cadena de certificados
En la misma vista, busca la cadena de certificados («Jerarquía de certificados» o «Certification Path»). Verás algo como:
Raíz (Root CA) → CA Intermedia → Certificado del sitio
- ¿Cuántos eslabones tiene la cadena de cada uno de tus dos sitios? ¿Coinciden las raíces?
- Copia el nombre de la CA raíz y el de la intermedia de cada sitio.
- ¿Qué significa que tu navegador «confíe» en esa CA raíz? ¿Quién tomó esa decisión por ti?
Parte 2: Calidad TLS con SSL Labs
SSL Labs es una herramienta gratuita de Qualys que analiza la configuración TLS pública de un sitio web y le asigna una calificación (A+, A, B, C, F). Consultarla es pasivo y legítimo: SSL Labs solo se conecta al sitio como lo haría cualquier navegador. Aun así, marca la casilla «Do not show the results on the boards» antes de iniciar la prueba, y recuerda que tu informe es un ejercicio de clase, no una denuncia, y no se publica.
Ejercicio 2.1: Analiza tus dos sitios
Ingresa cada dominio en SSL Labs y espera el resultado (puede tomar uno o dos minutos por sitio). Toma una captura del resumen de cada uno.
| Aspecto | Sitio 1: _______ | Sitio 2: _______ |
|---|---|---|
| Fecha y hora de la prueba | ||
| Calificación general | ||
| Versiones de TLS soportadas | ||
| ¿Soporta TLS 1.0 o 1.1 (obsoletos)? | ||
| ¿Soporta TLS 1.3? | ||
| Emisor del certificado según SSL Labs (¿coincide con lo que viste en la Parte 1?) |
Ejercicio 2.2: Interpretación
- ¿Qué diferencias observas entre los dos sitios? Señala la fila de la tabla que más pesa en la diferencia de calificación.
- SSL Labs penaliza el soporte de TLS 1.0 y 1.1 aunque «funcionen». Con lo que viste en clase sobre MD5 y SHA-1, explica por qué un protocolo que funciona puede ser un problema de seguridad.
- Si pudieras pedirle a uno de los dos sitios un solo cambio de configuración, ¿cuál sería y por qué? Justifica la elección con un dato de tu tabla.
Parte 3: Tu propia firma
En la sesión verificaste una firma que alguien más había producido. Ahora la produces tú, en CyberChef:
- Con la operación
Generate RSA Key Pair, genera un par de claves. Copia la clave pública y la privada en dos notas aparte. - En una receta nueva, escribe como entrada un mensaje con tu nombre completo y la fecha en que haces el laboratorio. Aplica
RSA Signcon tu clave privada y luegoTo Hex. Copia la firma en hexadecimal. - En otra receta, pon la firma como entrada y aplica
From Hex→RSA Verify, con tu clave pública y tu mensaje. Toma una captura del resultado. - Cambia un solo carácter del mensaje en
RSA Verifyy verifica de nuevo. Toma otra captura.
Explica en dos o tres oraciones qué parte de lo que entregas podría publicar cualquiera sin riesgo y qué parte no debe salir nunca de tu computador, y por qué.
Entregable
Entrega un documento (PDF) que incluya:
- Parte 1: Las capturas de los dos certificados, la tabla de campos de cada sitio con la comprobación que usa cada campo, los dominios de los SAN y el análisis de las dos cadenas.
- Parte 2: Las capturas del resumen de SSL Labs, la tabla comparativa con fecha y hora de la prueba y las respuestas de interpretación, incluida tu recomendación de un cambio.
- Parte 3: Tu clave pública, tu mensaje, la firma en hexadecimal, las dos capturas de verificación y la explicación de qué es público y qué es privado. No incluyas tu clave privada.
Criterios de evaluación
| Criterio | Puntos |
|---|---|
| Parte 1: inspección de los dos certificados, con capturas fechadas, valores copiados de los certificados reales y cada campo relacionado correctamente con la comprobación del navegador que lo usa | 35 |
| Parte 2: SSL Labs, con capturas, fecha y hora de la prueba, comparación apoyada en datos de la tabla y una recomendación de cambio justificada | 40 |
| Parte 3: firma propia, con clave pública, mensaje, firma y las dos verificaciones (la correcta y la que falla), y la distinción correcta entre lo público y lo privado | 25 |
Lectura disponible — Cómo funcionan las herramientas: simétrico, asimétrico, hash y firma
El principio de Kerckhoffs y por qué no se inventan algoritmos
En 1883, el lingüista y criptógrafo Auguste Kerckhoffs publicó en el Journal des sciences militaires un par de artículos titulados «La cryptographie militaire» (fuente). Escribía para ejércitos cuyos aparatos de cifrado podían caer en manos enemigas en cualquier batalla, y de ahí sacó una exigencia que hoy guía toda la criptografía: el sistema tiene que seguir siendo seguro aunque el enemigo conozca el aparato, de modo que el único secreto sea la clave.
El argumento de fondo es práctico. Un algoritmo secreto se filtra una sola vez (un aparato capturado, un empleado que se va, un programa que alguien desarma) y a partir de ese momento deja de servir para siempre, y con él todos los mensajes que protegió. Una clave filtrada, en cambio, se cambia por otra. Además, un algoritmo público puede ser atacado por miles de investigadores durante años antes de que alguien le confíe algo importante, y los que sobreviven a ese escrutinio son los que se usan. De ahí sale directamente uno de los errores frecuentes de la clase: quien inventa un algoritmo propio renuncia a ese escrutinio y apuesta a que nadie lo descubra, que es justo lo que Kerckhoffs desaconsejó.
La consecuencia es que la fuerza de un sistema moderno está en la longitud de la clave. Una clave de 128 bits admite 2¹²⁸ valores, unos 3,4 × 10³⁸. Si un computador hipotético probara un trillón (10¹⁸) de claves por segundo, tardaría unos 3,4 × 10²⁰ segundos en recorrerlas todas, es decir, del orden de 10¹³ años, unas 780 veces la edad estimada del universo, que ronda los 13 800 millones de años. Por eso se dice que romper una clave así por fuerza bruta es computacionalmente inviable: no es imposible en principio, pero no hay tiempo en el universo para hacerlo.
Cifrado simétrico y el problema de la clave
El cifrado simétrico usa la misma clave para cifrar y descifrar. Su estándar actual es AES (Advanced Encryption Standard), en sus variantes de 128 y 256 bits, y la alternativa más común es ChaCha20, muy usada en teléfonos porque funciona bien en procesadores que no tienen instrucciones especiales para AES. Ya lo viste funcionar en el laboratorio de la clase 02: con la clave correcta el mensaje vuelve, y con un solo carácter distinto en la clave sale basura. Es rápido, y por eso es el que cifra los datos guardados en un disco, en una base de datos o en una copia de seguridad, y el que cifra el tráfico de una conexión una vez establecida.
Su debilidad no está en el algoritmo sino en la logística. Las dos partes necesitan la misma clave antes de comunicarse, y hacérsela llegar por el mismo canal que se quiere proteger equivale a entregársela a quien esté escuchando. En el ejemplo de la Wi-Fi del centro comercial, cualquier forma de mandarle la clave al banco por esa red se la entrega también al dueño de la red, y cualquier otro canal (una llamada, una carta) es lento, caro o igual de interceptable. Con dos personas el problema se resuelve reuniéndose en persona; con miles de millones de navegadores y millones de sitios web no tiene solución sin otra idea.
Cifrado asimétrico
La otra idea es el par de claves: una pública, que se reparte, y una privada, que nunca sale de su dueño. Lo que se cifra con la pública solo lo abre la privada, y conocer la pública no permite calcular la privada. Así, cualquiera puede mandarle un mensaje secreto al dueño del par sin haber compartido nada antes.
No todos los algoritmos de clave pública hacen lo mismo, y conviene no mezclarlos. RSA, el más conocido, sirve para cifrar y para firmar; hoy se usan claves de 2048 bits o más. Ed25519 y ECDSA son algoritmos que solo firman: se usan muchísimo, por ejemplo en certificados, pero no cifran mensajes. Cuando en un certificado veas uno de esos nombres, lo que te dice es con qué algoritmo se produjo la firma.
El precio del asimétrico es la velocidad. Sus operaciones son muchísimo más lentas que las del simétrico, lo bastante como para que cifrar un video entero con RSA fuera impráctico. Por eso los sistemas reales combinan los dos: el asimétrico resuelve el problema de ponerse de acuerdo en una clave, y el simétrico cifra todo lo demás con esa clave. Es el modelo híbrido que usa TLS, y la otra lectura disponible de esta clase lo desarrolla.
Funciones hash
Una función hash toma datos de cualquier tamaño y produce una salida de tamaño fijo, llamada hash, resumen o huella. Estos son los hashes SHA-256 reales de dos textos que difieren en un punto, y puedes comprobarlos en CyberChef como hiciste en la clase 02:
"Hola" → e633f4fc79badea1dc5db970cf397c8248bac47cc3acf9915ba60b5d76b0e88f
"Hola." → ee6494f54a3e6a4605ff8fd710ff6980f656385595777597db72bc71335e659f
Cuatro propiedades hacen útil un hash, y cada una tiene una consecuencia. Es determinista: el mismo texto produce siempre el mismo hash, y por eso puedes comparar el hash de un archivo descargado con el que publicó su autor. Es de un solo sentido: a partir del hash no se puede reconstruir el texto, y por eso un sistema puede guardar el hash de una contraseña en vez de la contraseña. Tiene efecto avalancha: un cambio mínimo en la entrada cambia por completo la salida, como muestran los dos ejemplos de arriba, y por eso una alteración pequeña en un documento no pasa desapercibida. Y debe ser resistente a colisiones: tiene que ser inviable encontrar dos entradas distintas con el mismo hash, porque si alguien puede fabricarlas, puede presentar un documento en lugar del otro.
Hoy los hashes recomendados son SHA-256 (de la familia SHA-2) y SHA-3. MD5 y SHA-1 se consideran obsoletos, y que estén «comprometidos» significa que alguien logró fabricar dos documentos distintos que producen el mismo hash, algo diferente de devolver un hash a su texto original y, para una firma digital, igual de grave. En febrero de 2017, investigadores de Google y del instituto CWI de Ámsterdam publicaron dos archivos PDF con contenido diferente y exactamente el mismo SHA-1, después de unos nueve trillones de cálculos (fuente). Piensa en lo que eso le hace a una firma. Como lo que se firma es el hash del documento y no el documento entero, quien consiga que firmes el primer PDF tiene también, sin tu permiso, una firma válida para el segundo.
Contraseñas: dos problemas distintos
En la Parte 2 del laboratorio de la clase 02 viste que un hash MD5 de una contraseña común aparece en segundos en un buscador de hashes, y en la lectura de la clase 05 viste por qué las contraseñas se guardan como hash y no tal cual. Lo que falta es separar los dos problemas que un buen almacenamiento de contraseñas tiene que resolver, porque se resuelven con piezas distintas.
El primer problema es que un hash sin más es igual para todos los que eligieron la misma contraseña. Si dos usuarios usan password123, sus hashes son idénticos, y un atacante puede preparar de antemano tablas enormes con los hashes de millones de contraseñas probables (las rainbow tables o tablas precomputadas) y buscar ahí cada hash robado. La solución es el salt, un valor aleatorio distinto para cada usuario que se agrega a la contraseña antes de calcular el hash. Con salt, dos contraseñas iguales producen hashes distintos y las tablas preparadas de antemano dejan de servir, porque tendrían que calcularse otra vez para cada salt.
El segundo problema es la velocidad. SHA-256 está diseñado para ser rápido, y eso es una virtud para verificar archivos pero un defecto para contraseñas: un atacante que se robó la base de datos, con salt incluido, puede probar contraseñas candidatas una por una contra cada hash, y con tarjetas gráficas modernas lo hace a una velocidad enorme. El salt no frena eso. Lo que lo frena es un algoritmo deliberadamente lento y costoso, diseñado para contraseñas, como bcrypt, scrypt o Argon2, que además incluyen el salt de forma automática. Por eso SHA-256 con salt sigue sin ser suficiente para contraseñas, y la regla práctica es un hash lento con salt.
La firma digital, con precisión
La firma digital se calcula con la clave privada del firmante sobre el hash del documento, y se verifica con su clave pública: el verificador recalcula el hash del documento que recibió y usa la clave pública para comprobar que la firma corresponde a ese hash. Si el documento cambió, el hash cambia y la comprobación falla; si la firma se hizo con otra clave privada, la comprobación también falla. Eso es lo que viste en la Tarea A del laboratorio.
En muchos textos vas a encontrar una descripción más corta: «firmar es cifrar el hash con la clave privada, y verificar es descifrarlo con la pública». Esa imagen se parece a lo que hace RSA, y por eso se repite tanto, pero no describe a otros algoritmos de firma como Ed25519 o ECDSA, que no cifran nada. Lo que tienen en común todos es lo esencial: solo la clave privada produce la firma y cualquiera con la pública la comprueba.
En Colombia, la firma digital tiene valor jurídico desde la Ley 527 de 1999, que en su artículo 2 la define como un valor que se adhiere a un mensaje de datos y que permite determinar que se obtuvo exclusivamente con la clave del iniciador y que el mensaje no se modificó después de la transformación. El caso más cotidiano es la factura electrónica: la DIAN exige que cada una lleve la firma digital del facturador electrónico (Resolución 000165 de 2023). Esa firma es la que le da a un archivo que nadie firmó a mano la integridad y la autoría que antes daba la firma en papel.
Lectura disponible — Certificados, TLS y el ataque de intermediario
El ataque de intermediario, paso a paso
En la clase 03 conociste el ataque de intermediario como la situación en la que dos partes creen hablar directamente mientras un tercero retransmite, y puede alterar, todo lo que se dicen. La criptografía de esta clase permite ver con precisión dónde se cuela ese tercero y qué lo detiene.
Sigue el ejemplo de la Wi-Fi del centro comercial. El atacante montó la red y todo tu tráfico pasa por su equipo. Tu navegador le pide al banco su clave pública para acordar una clave de sesión, y el equipo del atacante intercepta esa petición. Le responde a tu navegador con su propia clave pública, haciéndose pasar por el banco, y al mismo tiempo abre su propia conexión con el banco verdadero. Desde ese momento hay dos conexiones cifradas, una entre tú y el atacante y otra entre el atacante y el banco, y el atacante descifra en el medio todo lo que pasa: tu usuario, tu contraseña, el valor de la transferencia que puede cambiar antes de reenviarla. El cifrado funciona perfectamente en las dos conexiones; el problema es que tú cifraste hacia la persona equivocada.
Lo único que puede detener ese ataque es que tu navegador tenga una forma de comprobar que la clave pública que recibió es de verdad la del banco. Esa forma es el certificado.
La cadena de confianza
Un certificado es un documento electrónico que asocia una clave pública con un nombre de dominio, firmado por una autoridad de certificación que comprobó esa asociación. El atacante de la Wi-Fi puede fabricar un certificado que diga «esta clave es de mibanco.com», pero no puede conseguir que lo firme una autoridad en la que tu navegador confíe, porque esa autoridad le pediría demostrar que controla el dominio del banco.
Las autoridades se organizan en una cadena. En la punta están las autoridades raíz, cuyos certificados vienen instalados en tu navegador o en tu sistema operativo, en lo que se llama el almacén de confianza. Las raíces casi nunca firman directamente el certificado de un sitio: firman los certificados de autoridades intermedias, y son las intermedias las que firman a los sitios. La razón es de prudencia. La clave privada de una raíz es tan valiosa que se guarda fuera de línea, en equipos especiales, y se usa muy pocas veces; si una intermedia se ve comprometida, se puede anular sin tocar la raíz ni cambiar los almacenes de confianza de millones de equipos.
Quién decide qué raíces entran al almacén es una pregunta con respuesta concreta: quien fabrica el navegador o el sistema operativo, con reglas públicas de admisión que las autoridades tienen que cumplir y auditar. Un ejemplo que puedes leer completo es la política del almacén de raíces de Mozilla, que usa Firefox (fuente). Cuando tu navegador «confía» en una raíz, en realidad está confiando en que esa empresa aplicó bien sus reglas.
Con la cadena, el navegador hace tres comprobaciones, y cada una corresponde a una de las variantes de badssl.com del laboratorio. La primera es que la cadena llegue hasta una raíz del almacén de confianza: falla con self-signed.badssl.com, cuyo certificado se firmó a sí mismo, y con untrusted-root.badssl.com, firmado por una raíz que tu navegador no tiene. La segunda es la vigencia, que el certificado no esté vencido ni sea todavía futuro: falla con expired.badssl.com. La tercera es que el dominio del certificado coincida con el que escribiste: falla con wrong.host.badssl.com. Y http.badssl.com no pasa ninguna porque ni siquiera presenta certificado: la conexión no está cifrada.
Cuando la cadena miente: DigiNotar
En el verano de 2011, usuarios en Irán que abrían Gmail veían la página de siempre, con su dirección correcta y su candado, y ninguna advertencia. Lo que no sabían es que el certificado que recibía su navegador no lo había pedido Google. Lo había emitido DigiNotar, una autoridad de certificación neerlandesa a la que alguien había logrado entrar, y como DigiNotar estaba en la lista de autoridades confiables, la cadena era válida de principio a fin (fuente). Ese es el límite de todo lo que viste en el laboratorio: el navegador comprueba con rigor que el certificado esté bien firmado, vigente y emitido para el dominio, pero no puede comprobar que la autoridad que lo firmó haya hecho bien su trabajo.
En esa misma publicación, Google anunció que Chrome dejaría de confiar en DigiNotar. Retirar una autoridad del almacén de confianza tiene un costo alto, porque todos los certificados que había firmado dejan de valer, los legítimos incluidos. Es la variación que quedó abierta en la pausa del laboratorio: frente a un certificado válido emitido por una autoridad comprometida, no hay advertencia que ver.
Revocación, y por qué no es una garantía perfecta
Un certificado trae una fecha de vencimiento, pero a veces hay que anularlo antes: la clave privada del sitio se filtró, el certificado se emitió por error, la empresa dejó de existir. Para eso existe la revocación, que es la forma en que una autoridad declara que un certificado que firmó ya no debe aceptarse aunque no haya vencido.
El problema es que el navegador tiene que enterarse. Comprobar en cada conexión si el certificado fue revocado exige consultar a la autoridad, lo que cuesta tiempo y depende de que el servidor de la autoridad responda. Si esa consulta falla o tarda, el navegador tiene que decidir entre bloquear la página, con el riesgo de dejar a la gente sin acceso a un sitio legítimo, o dejarla pasar, con el riesgo de aceptar un certificado anulado. Esa tensión es la razón por la que la revocación existe y sirve, pero no se puede tratar como una garantía perfecta. También explica por qué la vigencia importa tanto: si un certificado vence pronto, el daño de uno robado y no revocado a tiempo queda acotado a esas semanas o meses.
El modelo híbrido y el acuerdo de claves
Una conexión TLS combina las dos familias de cifrado por una razón de costo. Las operaciones del par de claves son tan lentas en comparación con AES que cifrar con ellas cada página, cada imagen y cada video volvería la web inutilizable. Por eso el par de claves se usa solo al principio, para dos cosas: comprobar la identidad del servidor con su certificado y ponerse de acuerdo en una clave de sesión. Todo lo demás viaja cifrado con esa clave simétrica, que es rápida, y que se descarta al cerrar la conexión. Si alguien la roba más tarde, solo le sirve para esa sesión.
En las primeras versiones de TLS era común que el navegador inventara la clave de sesión, la cifrara con la clave pública del servidor y se la mandara. En las versiones actuales se hace de otra manera, con un mecanismo llamado acuerdo de claves: cada lado aporta una parte generada al azar para esa conexión, las intercambian en público y cada uno calcula por su cuenta la misma clave, sin que la clave completa viaje nunca por la red. Quien escucha todo el intercambio ve las dos partes públicas y aun así no puede calcular la clave. La ventaja es que ni siquiera robarle al servidor su clave privada, años después, permite descifrar las conversaciones grabadas del pasado.
El candado y su historia
Durante años, los navegadores mostraron un candado (en algunas versiones, verde) en las conexiones HTTPS, y mucha gente aprendió a leerlo como «sitio seguro». Lo que el candado decía era más estrecho: que la conexión estaba cifrada y que el certificado correspondía al dominio. En 2023 el equipo de Chrome explicó que casi todos los sitios de phishing usan HTTPS, que en un estudio de 2021 solo el 11 % de los participantes entendía qué significaba exactamente el candado, y que por eso a partir de Chrome 117 lo reemplazaba por un ícono neutro de ajustes (fuente). La idea que conviene quedarte es la misma con cualquier ícono: la criptografía te dice con quién estás hablando y que nadie más escucha, pero no si hablar con esa persona es buena idea.
Versiones del protocolo
TLS ha tenido varias versiones, y cada una corrigió debilidades de la anterior. Las versiones 1.0 (de 1999) y 1.1 (de 2006) dependen de construcciones que hoy se consideran débiles, entre ellas el uso de MD5 y SHA-1, y fueron declaradas obsoletas formalmente en 2021 (RFC 8996). La versión actual es TLS 1.3. El que un servidor todavía acepte TLS 1.0 no significa que cada conexión use esa versión, pero sí que un atacante en posición de intermediario puede intentar forzar la conversación hacia la versión más débil que ambos lados aceptan. Por eso herramientas como SSL Labs, la que usas en el laboratorio de tarea, bajan la calificación de un sitio que las sigue aceptando, aunque «funcione».
Lectura disponible — Decidir qué proteger, errores frecuentes y glosario
Un procedimiento en vez de una tabla de respuestas
Una tabla que dice «contraseñas: bcrypt» es cierta para cualquier sistema del mundo, y por eso mismo no te sirve para pensar el tuyo. Lo que conviene llevarte es la pregunta que produjo esa fila. Una contraseña es un dato que el sistema nunca necesita volver a leer, solo comparar; si la base de datos se filtra, el daño no se queda en tu sistema, porque mucha gente usa la misma contraseña en otros servicios. Lo que está en juego es la confidencialidad de algo que ni siquiera es tuyo, y el mecanismo que la protege tiene que seguir funcionando cuando el atacante ya tiene la base de datos en su computador. Descartas el cifrado porque su clave suele vivir en el mismo servidor que la base filtrada, y descartas un hash rápido porque se puede probar a ciegas a enorme velocidad; lo que queda en pie es un hash lento con salt.
Ese razonamiento se puede repetir con cualquier dato siguiendo cuatro preguntas en orden. Primero, qué dato es y dónde está: viajando por una red, guardado en un disco, en una copia de seguridad. Segundo, qué le puede pasar, con el vocabulario de impacto de la clase 04: que alguien lo lea, que alguien lo cambie, que alguien se haga pasar por quien lo envió. Tercero, qué principio de CIAAN está en juego en cada caso. Y cuarto, solo entonces, qué mecanismo sostiene ese principio, usando la tabla de lo que cada mecanismo da y no da.
La tabla que sigue es el resultado de aplicar esas preguntas a los datos más comunes de una aplicación web. Léela como ejemplos resueltos, no como una lista para copiar.
| Qué proteger | Por qué | Cómo |
|---|---|---|
| Comunicaciones cliente-servidor | Todo lo que viaja pasa por equipos que no controlas, desde la Wi-Fi hasta el proveedor de internet, y cualquiera de ellos puede leer o alterar lo que no va protegido. Hace falta confidencialidad, integridad y saber que el servidor es quien dice ser. | TLS (HTTPS obligatorio) |
| Contraseñas de usuarios | El sistema solo necesita compararlas, nunca leerlas, y si la base se filtra el daño alcanza otros servicios donde la persona repitió la contraseña. | Hash lento con salt: bcrypt o Argon2 (nunca texto plano ni un hash rápido) |
| Datos sensibles en base de datos | Una base robada o una copia mal guardada expone todo lo que tenga en claro; el cifrado hace que el robo de los datos no baste sin la clave. | Cifrado simétrico (AES-256), con la clave guardada fuera de la base |
| Sesiones de usuario | Si alguien puede modificar la información de su propia sesión, puede hacerse pasar por otro usuario; lo que importa es detectar cualquier cambio. | La sesión la firma el servidor, para detectar si alguien la modificó |
| Copias de seguridad | Suelen guardarse en lugares menos vigilados que el sistema principal, y contienen lo mismo. | Cifrado simétrico (AES-256), con la clave guardada aparte de la copia |
Qué no cifrar
El cifrado tiene costos que no se ven en la tabla. Cada clave hay que custodiarla, rotarla y tenerla disponible cuando se necesita, y un dato cifrado ya no se puede buscar ni ordenar con facilidad. Por eso no todo dato merece cifrado propio, y el criterio para decidirlo no es una intuición de «qué tan sensible parece», sino el impacto que la clase 04 te enseñó a estimar: qué pasa si ese dato se lee o se cambia. Un identificador interno de usuario, que no dice nada por sí solo, tiene un impacto bajo si se expone. Un número de cédula o de tarjeta de crédito, que permite suplantar a alguien o cobrarle, tiene un impacto alto. Un nombre queda en el medio y depende de con qué otros datos aparezca. Nada de esto exime al sistema de proteger la conexión con TLS: la pregunta de qué no cifrar se refiere al cifrado adicional de datos guardados, no al tráfico.
Errores frecuentes, con su consecuencia
Inventar un algoritmo propio. Es la violación directa del principio de Kerckhoffs. Un algoritmo casero no ha pasado por el escrutinio de nadie, y su seguridad depende de que el atacante no lo estudie; en cuanto alguien lo analiza, suele caer, y con él todo lo que protegía. Los algoritmos estándar como AES o RSA llevan décadas resistiendo ataques públicos, y esa resistencia es la única garantía disponible.
Seguir usando algoritmos o protocolos obsoletos. MD5 y SHA-1 ya tienen colisiones prácticas, como mostró en 2017 la primera colisión publicada de SHA-1 (fuente), que la primera lectura de esta clase cuenta en detalle, y TLS 1.0 y 1.1 están declarados obsoletos. Usarlos en un sistema nuevo, o dejarlos habilitados en uno viejo, abre una puerta que otros ya sabían cómo cruzar.
Guardar contraseñas en texto plano o con un hash rápido. En texto plano, una filtración de la base entrega las contraseñas tal cual. Con un hash rápido, aunque lleve salt, el atacante las recupera probando candidatas a gran velocidad. La consecuencia alcanza cuentas en otros servicios, porque la gente repite contraseñas.
Desactivar la verificación de certificados, o enseñarle a la gente a ignorar las advertencias. Pasa cuando alguien apaga la comprobación del certificado en un sistema porque en las pruebas estorbaba y el ajuste se queda así en producción, o cuando los usuarios se acostumbran a pulsar «Continuar». En los dos casos la conexión sigue cifrada, como viste en la Tarea B del laboratorio, pero cifrada con cualquiera: es exactamente la puerta que necesita el intermediario.
Guardar las claves junto a lo que protegen. Una base de datos cifrada cuya clave está en un archivo del mismo servidor queda expuesta en el mismo robo que la base. Lo mismo pasa con una clave privada guardada sin protección junto al certificado que la acompaña. La clave tiene que vivir en otro lugar, con otros permisos, idealmente en un sistema pensado para custodiar claves.
Glosario de términos clave
Varias de estas entradas tienen una versión más amplia en el glosario del sitio: cifrado, hash, PKI, integridad, autenticación y no repudio.
| Término | Definición |
|---|---|
| Cifrado simétrico | Cifrado donde la misma clave cifra y descifra |
| Cifrado asimétrico | Cifrado con un par de claves: lo que se cifra con la pública solo lo descifra la privada |
| Clave pública / clave privada | Las dos mitades de un par de claves; la pública se reparte, la privada nunca sale de su dueño |
| Hash / Digest | Huella de tamaño fijo de cualquier dato, de un solo sentido y sensible a cualquier cambio |
| Colisión | Dos entradas distintas que producen el mismo hash; si se pueden fabricar, el hash deja de servir para seguridad |
| Salt | Valor aleatorio distinto para cada usuario que se agrega a la contraseña antes de calcular su hash, para inutilizar las tablas precomputadas |
| Firma digital | Valor que se calcula con la clave privada del firmante sobre el hash de un documento y que cualquiera verifica con la clave pública; garantiza integridad, autenticación del firmante y no repudio |
| Certificado digital | Documento que vincula una clave pública a una identidad (un dominio), firmado por una CA |
| CA (Autoridad de Certificación) | Entidad de confianza que comprueba identidades y emite y firma certificados digitales |
| Autoridad raíz | CA cuyo certificado viene instalado en el almacén de confianza del navegador o del sistema operativo |
| Cadena de confianza | Secuencia de firmas que va del certificado de un sitio, pasando por una o más CA intermedias, hasta una autoridad raíz |
| Ataque de intermediario | Ataque en el que un tercero se interpone entre dos partes que creen hablar directamente, y puede leer y alterar lo que se dicen |
| TLS | Protocolo criptográfico que protege las comunicaciones en red: autentica al servidor, acuerda una clave de sesión y cifra el tráfico |
| HTTPS | HTTP protegido con TLS |
| AES | Algoritmo de cifrado simétrico estándar actual |
| RSA | Algoritmo de clave pública ampliamente usado, que sirve para cifrar y para firmar |
| bcrypt / Argon2 | Algoritmos lentos, con salt incluido, diseñados específicamente para guardar contraseñas |
Navegación: ← Anterior | Inicio | Siguiente: Evaluación →