Módulo 4
Módulo 4
Con un sistema de cifrado de clave privada (o sistema de clave secreta) existe una
única clave que deben compartir emisor y receptor. El emisor y el receptor del mensaje
utilizan la misma clave.
Cifrado de clave privada.
Con un sistema de cifrado de clave pública cada usuario crea un par de claves, una
privada y otra pública. Lo que se cifra en emisión con una clave, se descifra en
recepción con la clave inversa o complementaria. El sistema de clave pública es
asimétrico, frente al sistema simétrico de clave secreta. Si alguien desea enviar un
mensaje, buscará la clave pública de a quien desea enviárselo, y lo cifrará con dicha
clave. Esta clave, conocida por todos, no permite desencriptar el mensaje. La única
forma de desencriptarlo es utilizando la clave privada del receptor, la cual es conocida
únicamente por él. Para que estos sistemas sean seguros, ha de resultar muy difícil
calcular una clave a partir de la otra.
Cifrado de clave pública.
En general, los sistemas de clave pública son más lentos (por el tipo de algoritmo
matemático que emplean) pero tienen un fácil intercambio de clave y cuentan con firma
digital. Por el contrario, los sistemas de clave secreta son más sencillos y por lo tanto
más rápidos, pero el intercambio de clave se vuelve muy complejo y no facilitan la
firma. Por eso, para el cifrado de información se suelen utilizar sistemas de clave
privada, pero para el intercambio de la clave de sesión se suele utilizar cifrado de
clave pública.
DES
El algoritmo DES (Data Encryption Standard) es el algoritmo de clave privada más
extendido. Desarrollado originalmente por IBM, fue adoptado como estándar por el
Gobierno de los Estados Unidos para comunicaciones no clasificadas en 1976. DES es
un algoritmo que toma un texto de una longitud fija y lo transforma mediante una serie
de complicadas operaciones en otro texto cifrado de la misma longitud. Se trata de un
criptosistema de clave privada que trabaja con bloques de 64 bits y claves de longitud
efectiva de 56 bits. La máquina de crackeado de DES de la Electronic Frontier
Foundation contenía 1.536 chips y podía romper una clave DES por fuerza bruta en
días.
Se basa en dos operaciones básicas: sustitución y transposición, de las que se hacen 16
ciclos. La longitud de la clave, 56 bits, hizo que se considerara un algoritmo poco
seguro desde sus inicios:
2^56 = 7.2 * 10^16 claves diferentes (aprox.)
En el año 1981, el ANSI (American National Standars Institute, USA), adoptó DES con
el nombre de Data Encryption Algorithm (DEA). La vulnerabilidad de DES fue
demostrada en la práctica en 1988 cuando un grupo dedicado a los derechos civiles en el
ciberespacio, construyó una máquina a medida para romper DES, con un coste
aproximado de 250.000 dólares: “Hay mucha gente que no creerá una verdad hasta que
puedan verla con sus propios ojos. Mostrarles una máquina física que pueda romper
DES en unos pocos días es la única manera de convencer a algunas personas de que
realmente no pueden confiar su seguridad a DES.”
La máquina, que ensaya 92.160.000.000 claves por segundo, rompió una clave por
fuerza bruta, en una búsqueda que duró 2 días. A partir de 1998, se empleó el Triple-
DES como solución transitoria mientras se desarrollaba un nuevo estándar, el AES,
publicado en Noviembre de 2001.
De hecho, Doble DES (2DES) fue el primer intento de reforzar el algoritmo DES,
encriptando el texto primero con una clave y a continuación con otra diferente (es decir,
aplicando DES dos veces seguidas). Pero se comprobó que esto era equivalente a una
clave de 57 bits y que sólo doblaba el trabajo de un criptoanalista que trabajara con
fuerza bruta. Por ejemplo, en lugar de necesitar dos días para romper el algoritmo,
necesitaría cuatro días.
Triple-DES (3DES) sí que mejora la seguridad del algoritmo DES hasta el nivel
deseado y aunque se está sustituyendo progresivamente por AES, consigue longitudes
efectivas de clave de 80 y 112 bits en sus dos versiones: hay un Triple- DES con dos
claves y un Triple-DES con tres claves. En ambos casos se combinan cifrados y
descifrados, no se de trata simplemente de utilizar DES tres veces seguidas.
AES
Su desarrollo se llevó a cabo de forma pública y abierta y no de modo secreto como
en el caso del DES que fue generado a partir de una institución militar. Los criterios
considerados para la elección del algoritmo fueron:
Seguridad.
Eficiencia computacional.
Requisitos de memoria.
Adecuación hardware-software.
Simplicidad de diseño.
Flexibilidad.
Requisitos de licencia.
Al igual que el DES, AES es un sistema de cifrado por bloques, pero maneja
longitudes de clave y de bloque variables, ambas comprendidas entre los 128 y los
256 bits. Adoptado como estándar de cifrado por el Gobierno de los Estados Unidos en
el año 2001. Se basa en el algoritmo de Rijndael, que trabaja con bloques de 128 bits y
claves de 128, 192 y 256 bits. 10, 12 ó 14 rondas de operaciones matemáticas
sencillas (sustitución, transposición, OR exclusivo, desplazamiento).
Algoritmos de clave púá blica maá s útilizados
El más popular de entre los algoritmos de clave pública, por su sencillez es RSA. Debe
su nombre a sus tres inventores: Ronald Rivest, Adi Shamir y Leonard Adleman del
MIT (Instituto Tecnológico de Massachusetts).
Algoritmo asimétrico de cifrado por bloques, que utiliza una clave pública, conocida
por todos, y otra privada, la cual es guardada en secreto por su propietario. Para
conformar las claves el funcionamiento se basa en el producto de dos números primos
grandes elegidos al azar. Para romper este cifrado, dado un número grande hay que
responder a esta pregunta ¿cuáles son los dos primos que se han multiplicado para
obtenerlo? La seguridad de este criptosistema reside en que no hay maneras rápidas
conocidas de factorizar un número que es el producto de dos números primos (si son
suficientemente grandes).
En estas figuras se explica el funcionamiento básico del algoritmo y un ejemplo de
utilización del mismo.
Autenticación basada en clave pública: Alice sabe que el texto lo envía Bob.
Confidencialidad basada en criptografía de clave pública: Allice le envía un texto a Bob y sólo él lo puede
leer.
En este esquema se puede apreciar que existe un posible inconveniente de uso en el
acceso a las claves públicas: ¿y si alguien miente?. Hay cuatro posibilidades para
resolver esta desventaja:
1. Realizar un anuncio público.
2. Usar un directorio público o base de datos de certificados.
3. Confiar en un tercero de confianza que genere las claves y certifique que una clave
privada realmente está en posesión del individuo que se declara junto a la
correspondiente clave pública (esta declaración es el denominado certificado digital que
ya os introdujo Isaac en la unidad anterior).
4. Autogenerar los certificados digitales uno mismo.
Segmentación de redes
Ya hemos visto cómo hacer lo más seguras posibles nuestras "murallas" exteriores, pero
seamos realistas, si un atacante quiere entrar en nuestra red al final encontrará algún
modo de hacerlo. En este apartado veremos cómo entorpecer lo más posible un
ataque una vez tenemos al enemigo dentro de nuestra red, mediante la
segmentación de la misma. Es como ir poniendo distintos diques en nuestra ciudad
para protegernos de una posible inundación, de forma que si una zona queda inundada
podamos contener el agua y que no pase a otras zonas, y de esta forma prevenimos la
propagación de la amenaza.
Esto también aplica a las amenazas internas, para evitar que personas, que de por sí ya
tienen acceso a determinadas zonas de nuestra red, tengan acceso a zonas a las que no
están autorizadas. Recientemente se ha impuesto el modelo Zero-Trustpropuesto en
2010 por Forrester Research y que precisamente intenta evitar en lo posible estas
amenazas internas con una política de “no confíes nunca en nadie, verifica todo
siempre”. U
Las redes tradicionales tenían una arquitectura plana con una única muralla defensiva
exterior, como un “huevo” (ver siguiente figura), mientras que la segmentación nos
permite una defensa en profundidad, con diferentes capas (como una “cebolla”, cuantas
más capas mejor, siempre dentro del límite de lo manejable por el administrador de red)
que dificultan los accesos a la información sensible a aquellas aplicaciones, servidores y
personas que no la necesitan, pero garantizando el acceso a aquellas que sí están
autorizadas.
Ejemplo de segmentación de redes.
En una red plana todos los dispositivos se ven entre sí, por lo que un atacante tendría
acceso a todos los servidores una vez acceda a nuestra red. La segmentación mediante
redes de área local virtuales (VLANs) es la más sencilla y permite, entre otras cosas, la
segmentación del dominio (reduciendo el área de visibilidad de cada zona), la
separación de protocolos (limitando el tráfico en cada segmento) o la movilidad de los
usuarios (por ejemplo, si se le asigna una VLAN determinada a un usuario siempre se
conectará a ella independientemente de su localización).
Como has visto en el vídeo, para configurar las VLAN con un Q-Switch se puede hacer
siguiendo distintos criterios. Por ejemplo, en la figura de arriba ( Eje es la traducción de
Trunk, aunque no se suele traducir) podemos asignar los puertos 1, 3 y 5 a la VLAN1
(red del Departamento de recursos humanos de la organización), los puertos 2, 4 y 6 a la
VLAN2 (red del Departamento financiero), el puerto 7 para la VLAN3 (red comercial)
y el puerto 8 a la VLAN4 (acceso wifi). De esta forma los dispositivos conectados a la
VLAN1 se podrán comunicar entre ellos pero no con los del resto de VLANs. Esta es la
configuración de asignación de puertos, la más sencilla para segmentar una red por
VLANs, pero también de las menos flexibles. Las otras posibilidades son:
Pero ¿qué sucede cuando tenemos más de un switch? Habrá que extender las VLAN al
otro switch y habrá que etiquetar de alguna forma los paquetes para que se sepa a qué
VLAN pertenecen. Para conectar un switch a otro se configura un puerto como puerto
trunk y se conecta al puerto trunk del otro switch, de forma que podemos extender las
VLAN al resto de la red. Además el estándar IEEE802.1Q nos permite etiquetar los
paquetes para identificar a qué VLAN pertenecen, así cuando viajen por la red por
distintos switches no perderán esa información (aunque no todos los dispositivos son
compatibles con este estándar y esos sí que descartarán las etiquetas).
Para definir las zonas en las que vamos a segmentar nuestra red necesitamos conocer
muy bien los procesos de negocio y qué información se intercambian, de esta forma
podremos dar a los usuarios acceso a los datos que necesitan para trabajar y no a otros,
siguiendo siempre la regla de “mínimos privilegios” (otorgar siempre el mínimo
privilegio al usuario e ir dando acceso según vaya necesitando). Una segmentación
típica sería la propuesta en la figura siguiente, donde se dispone de una DMZ con los
servicios públicos básicos (principalmente la web), otra para los accesos remotos por
VPN, otra para el correo electrónico, otra para los servidores de aplicaciones, otra para
la red corporativa y otra para el centro de datos (donde cada servidor de datos tendrá su
propia zona, por ejemplo los datos de tarjetas de crédito en la zona PCI).
Ejemplo de segmentación de redes teniendo en cuenta los procesos de negocio.
Otra forma de segmentar redes en lugar de utilizar VLANs es directamente con
firewalls, separando cada zona del resto con un firewall. Esto podría incrementar
enormemente el número de dispositivos (lo que repercute no sólo en lo estrictamente
económico, sino también en espacio en el CPD, aumento de la temperatura, etc.) y
dificultar su administración, aunque al gestionar zonas más reducidas también se
simplifica algo su gestión. La alternativa es emplear la virtualización de firewalls, que
con un único equipo podemos implementar varios firewalls para varias zonas.
Por último, destacar las posibilidades que las SDN (Software-Defined Networks)están
abriendo en cuanto a “micro-segmentación” de redes, pudiendo analizar y filtrar el
tráfico extremo a extremo entre dos puntos cualquiera siguiendo una política
determinada. Esto permite no sólo segmentar la red de una organización en una sede,
sino extender esa segmentación a todas las sedes por toda la WAN de la organización,
algo imposible de llevar a cabo con VLANs.
Los Sistemas de Detección de Intrusos (IDS) son sistemas que se emplean para
detectar accesos no autorizados a un ordenador, un servidor o una red de ordenadores.
Las funciones de un IDS se pueden resumir de la siguiente forma:
Detección de ataques en el momento que están ocurriendo (o poco después).
Automatización de la búsqueda de nuevos patrones de ataque, gracias a herramientas
estadísticas de búsqueda, y al análisis de tráfico anómalo.
Monitorización y análisis de las actividades de los usuarios. De este modo se pueden
conocer los servicios que usan los usuarios, y estudiar el contenido del tráfico, en busca
de elementos anómalos.
Auditoría de configuraciones y vulnerabilidades de determinados sistemas.
Descubrimiento de sistemas con servicios habilitados que no deberían de estarlo
(recuerda el principio de mínima exposición), mediante el análisis del tráfico y de los logs.
Análisis de comportamiento anormal. Si se detecta una conexión fuera de hora,
reintentos de conexión fallidos y otros, existe la posibilidad de que se esté en presencia
de una intrusión. Un análisis detallado del tráfico y los logs puede revelar una máquina
comprometida o un usuario con su contraseña al descubierto.
Recogida de evidencias del ataque de forma que pueda ser empleada como prueba
legal en caso de actuar judicialmente contra los atacantes.
Automatización de tareas como la actualización de reglas, la obtención y análisis de
logs, la configuración de cortafuegos y otros.
Hay tres métodos que pueden emplear los IDS para detectar los ataques o las
intrusiones:
Detección de anomalías: Se basa en el aprendizaje por parte del sistema de las
actividades normales y legítimas que tienen lugar en nuestra red/equipo, de forma que se
entrena al IDS para detectar las actividades que se salen de este patrón de
comportamiento normal. La ventaja de este método es que se adapta y puede detectar
ataques no conocidos sin necesidad de estar continuamente actualizando sus firmas, pero
como contrapartida es muy propenso a generar falsas alarmas. Por ejemplo, si un usuario
suele enviar 30 correos electrónicos al día y se detecta un envío de 500 correos es muy
probable que se trate de un ataque (o que ese día ese usuario tenga que hacer la difusión
de un evento, en ese caso saltaría una falsa alarma).
Detección de usos incorrectos: Se basa en comparar las actividades que se
monitorizan en el equipo/red con una base de datos de firmas de ataques, generando
una alarma en caso de coincidencia. Este método es más preciso que el anterior pero
requiere de una actualización continua de la base de datos de firmas, y no detecta nuevas
intrusiones o variaciones sobre las existentes. Por ejemplo, un intento de telnet con el
usuario “root” sería detectado como uso incorrecto.
Híbrido: Sería el método ideal, mezclando la detección de anomalías con los usos
incorrectos, para tomar lo bueno de cada uno de ellos. Aún hay mucha investigación por
realizar en este campo.
Independientemente del método que empleen, los IDS se pueden clasificar según el
ámbito en el que actúen, a nivel de red o a nivel de equipo:
Network-Based Intrusion Detection Systems (NIDS): Formados por dispositivos que
capturan todo el tráfico de la red y lo analizan para buscar patrones de ataque. Intentan
complementar la labor de los firewall, tratando de detectar aquellos ataques que se les
han pasado a estos. Su principal ventaja es su bajo coste y fácil instalación, y que no
interfiere con la red, sin embargo le costará analizar grandes cantidades de datos en
tiempo real o si estos van cifrados. Habría que situar un sensor en cada segmento de red
para poder analizar el tráfico completo.
Host-Based Intrusion Detection Systems (HIDS): Monitorizan los ficheros y logs de
sistema, eventos y actividades que se llevan a cabo en un equipo concreto, buscando
cambios no autorizados o sospechosos en el sistema. La ventaja frente a los NIDS es que
actúan directamente sobre el equipo, por lo que pueden detectar ataques internos
realizados sobre el terminal (que no emplean la red), eso sí se tiene que instalar en cada
equipo. A menudo se apoyan en los System Integrity Verifiers (SVIs) y en los Log File
Monitors (LFMs) para detectar por ejemplo cuando un usuario consigue privilegios de
root.
El siguiente paso en los sistemas IDS es incorporar la respuesta al ataque una vez este se
ha detectado, es lo que se denominan Sistemas de Detección y Prevención de Intrusos
(IDPS). El IDPS intentará prevenir que el ataque tenga éxito mediante varias técnicas
como:
Detener el ataque: Por ejemplo, terminando la conexión de red o la sesión del usuario,
o cerrando toda conexión posible a la máquina atacada o incluso a todo ese segmento de
red.
Cambiar el entorno de seguridad: Cambiando la configuración de un firewall, switch o
router, o aplicando los parches de seguridad necesarios en el host atacado si lo que se ha
hecho es aprovechar una vulnerabilidad del mismo.
Cambiar alguna característica del ataque: Por ejemplo eliminando o reemplazando las
partes maliciosas del ataque, como sería eliminar un fichero infectado que va adjunto a
un correo electrónico.
Simular el comportamiento del sistema atacado: Para poder detectar estrategias de
evasión en las que el atacante “disfraza” el código malicioso para que pase inadvertido
por el IDPS pero sea ejecutado por el sistema objetivo. Si el IDPS visualizara el código de
la misma forma en la que lo va a hacer el sistema objetivo, podrá detectarlo y detenerlo a
tiempo.
Existen distintas estrategias para elegir la ubicación de los IDPS en la red según el
tráfico que queramos analizar (en el caso de IDPS de red, NIDPS). Por ejemplo, antes
del firewall para analizar todo el tráfico, o justo después para complementar su labor
reduciendo falsos positivos y ver qué se le está pasando al firewall. También se suelen
colocar sensores en todos los segmentos de red, así como tras el servidor de acceso
remoto, entre unidades de negocio, en la DMZ, o entre la red corporativa y las redes de
socios.
Los IDPS de host (HIDPS) se suelen instalar en aquellos servidores críticos o con
información sensible, en los servidores web, FTP, DNS, bases de datos y otros equipos
que tengan valor para la compañía. Además se pueden poner en equipos de forma
aleatoria para obtener medidas probabilísticas de equipos que se vean comprometidos.
Ubicación estratégica de los IDPS de host (HIDPS) dentro de la red.
Una opción interesante son los sistemas que integran los IDPS dentro de los firewall,
que algunos denominan Next-Generation Firewall (NGFW), y que ofrecen una
solución de seguridad muy completa con un alto rendimiento, de forma que la velocidad
de nuestra red se vea afectada lo menos posible por la inspección del tráfico que se
realiza.
Otros sistemas que se emplean de forma complementaria a los mecanismos de defensa
de nuestra red son los Honeypots. Un honeypot es un sistema “trampa” para observar el
comportamiento de un ciberataque y analizar la intrusión y el método utilizados.
Veamos este tipo de solución en detalle en el siguiente vídeo.
Protocolo IPSec
IPSec es un conjunto de protocolos desarrollado por la IETF que pretenden conseguir
confidencialidad, integridad y autenticación, así como prevenir ataques por
reproducción (anti-replay), en la comunicación por redes IP como Internet. Como
funciona en la capa de red (IP) lo hace independiente y por tanto transparente a las
capas superiores, por lo que no es necesario que las aplicaciones hagan nada para que
sus comunicaciones vayan cifradas "por debajo". IPSec está soportado de manera native
en IPv6, pero mientras sigamos empleando IPv4 tendremos que ser nosotros los que
añadamos IPSec al host o router que queramos comunicar de forma segura. Aunque la
arquitectura IPSec queda definida en el RFC2401, los protocolos, algoritmos y
procedimientos que se emplean se detallan en otros RFCs
Protocolo IPSec.
Modo transporte: Son directamente los extremos de la comunicación los que procesan
la información y no se modifica la cabecera IP del paquete, se le añade una cabecera
IPSec.
Modo túnel: Uno de los extremos (o los dos) no es el destinatario final (puede ser, por
ejemplo, un router), por lo que se crea un nuevo paquete con nuevas cabeceras que
envuelve el paquete original.
Esto nos deja cuatro posibles formas de configurar IPSec, como se observa en la
siguiente figura, siendo la más utilizada la del modo túnel con ESP.
AH y ESP en modo transporte y túnel: los datagramas.
VPN de acceso remoto: Por ejemplo, para personal de la empresa que necesita
acceder de forma segura a recursos de la red corporativa desde fuera de esta,
normalmente a través de Internet.
VPN intranet: Para conectar de forma segura, por ejemplo, distintas sedes de la
empresa, aprovechando Internet como red más económica.
VPN extranet: Para dar acceso de forma segura a terceros, como un proveedor o un
cliente, a nuestra red corporativa.
También se habla de VPN cerrada, cuando todo el tráfico entre los nodos implicados
debe pasar por el túnel VPN, o abierta, si puede haber tráfico entre los nodos que no
pase por el túnel VPN. El objetivo principal por tanto es garantizar la seguridad de la
comunicación (confidencialidad, autenticación e integridad) en un canal que no
controlamos y que es potencialmente inseguro. Para ello podemos emplear diversos
mecanismos de seguridad para crear túneles: SSL/TLS, IPSec, PPTP (Point-to-Point
Tunneling Protocol), L2TP (Layer 2 Tunneling Protocol), MPPE (Microsoft Point-to-
Point Encryption), SSTP (Microsoft Secure Socket Tunneling Protocol), SSH (Secure
Shell), etc. Uno de los más empleados al principio fue PPTP, que proporcionaba una
razonable seguridad mediante túneles GRE (ahora en desuso) y métodos de
autenticación simples como MS-CHAP.
Hoy en día se utiliza más las VPN basadas en SSL/TLS o IPSec, que son precisamente
los protocolos que acabamos de estudiar en las pantallas anteriores. Veamos ahora las
diferencias entre uno y otro a la hora de implementar un túnel VPN.
Como puedes ver en la figura de arriba, la principal diferencia es que SSL e IPSec
actúan a diferentes niveles: mientras que IPSec proporciona un canal seguro en la capa
de red para todo el tráfico de todas las aplicaciones de forma transparente al usuario,
SSL proporciona seguridad en la capa de aplicación, por lo que la mayoría de soluciones
SSL VPN pasan por ser ejecutadas desde un navegador web.
IPSec VPN:
Funciona en la capa de red.
Comunica de forma segura todos los datos entre los dos extremos, sin estar asociado a
una aplicación en concreto.
Una vez lograda la conexión, el equipo remoto tendrá acceso total a la red corporativa.
La negociación de los parámetros de seguridad y la configuración de los extremos es
compleja.
A menudo necesita de software especializado que debe instalarse en los equipos.
Los nodos intermedios deben permitir el paso de tráfico IPSec.
SSL VPN:
Funciona en la capa de aplicación.
Comunica de forma segura los datos enviados vía web.
Al emplear el navegador web como principal cliente es más flexible y puede utilizarse
desde más equipos ya que no requiere la instalación de un software específico.
Control de acceso más detallado que con IPSec, pudiendo especificar los recursos de la
red corporativa a los que se tiene acceso.
Más simple que IPSec, y su paso por nodos intermedios está generalmente aceptado
(el puerto 443 suele estar habilitado para https).
Con la proliferación de las SSL VPN se han ido implementando soluciones para que
aplicaciones que no son accesibles desde el navegador puedan utilizarse desde equipos
remotos. De esta forma han surgido tres modos de funcionamiento en SSL VPN:
Como hemos visto, tanto IPSec como SSL tienen sus ventajas e inconvenientes, por lo
que se trata de métodos complementarios que pueden implementarse de forma conjunta,
cada una sirviendo un propósito. Con IPSec tendremos una conexión permanente en la
que tendremos un control de acceso inicial, pero una vez accedan a nuestra red es como
si estuvieran físicamente en ella. Se emplea por tanto para dar acceso a entornos y
equipos controlados como una oficina o sede remota. Y con SSL deberíamos dar acceso
a los usuarios en movilidad, que se pueden conectar desde cualquier sitio o equipo que
no tenemos controlado y que, por tanto, deberemos controlar a qué aplicaciones y datos
se conecta y no dar acceso a toda nuestra red. Se emplea para dar servicio, por ejemplo,
a agentes comerciales, clientes o proveedores.
Ejemplos de Redes Privadas Virtuales con IPSec y SSL.
Criptografía:
“Técnicas criptográficas de protección de datos”. Amparo Fuster Sabater y otros. Ra-
Ma. 2004.
“Introduction to Cryptography”. J.A. Buchmann. Springer. 2004.
“La música de los números primos”. Marcus Du Sautoy. El Acantilado. 2007.
TedTalk: “Think your email's private? Think again” (Andy Yen, 2014)
- https://www.ted.com/talks/andy_yen_think_your_email_s_private_think_again
“Cryptography and the power of randomness” (James Lyne, 2012)
- https://www.youtube.com/watch?v=SAAflrIp__E
Máquina Enigma y simuladores - http://enigmaco.de/enigma/enigma.swf
Algoritmo DES - http://www.tero.co.uk/
Animación explicando el funcionamiento del algoritmo Rijndael
- http://www.formaestudio.com/rijndaelinspector/
Una herramienta educativa de código abierto para el aprendizaje de algoritmos de
cifrado y criptoanálisis - http://www.cryptool.org/
Tutorial básico de criptografía de la Fábrica Nacional de Moneda y Timbre
- https://www.cert.fnmt.es/curso-de-criptografia/
Centro Criptológico Nacional - https://www.ccn.cni.es/
Mecanismos de autenticación
“Kerberos: The Definitive Guide”. Jason Garman. O'Reilly Media. 2003.
Kerberos - http://web.mit.edu/kerberos/
Simulador de Kerberos
- http://williams.comp.ncat.edu/IA_visualization_labs/security_visual_tools/kerberos/ker
beros_demo.html
X.500 - http://www.x500standard.com/
RFC para X.509 (Internet X.509 Public Key Infrastructure Certificate and CRL Profile)
- https://www.ietf.org/rfc/rfc2459.txt
VALIdación de firma y certificados online y DEmostrador de servicios de @firma -
https://valide.redsara.es/valide/
CERES (CERtificación Española) - http://www.cert.fnmt.es/
Comunicaciones seguras
“SSL/TLS: What’s under the hood”. S. Vandeven. SANS Institute. 2013.
Has Tenido Tiempo Para Securizarlo: Te Lo Suplico, no Sigas Solo Leyéndolo "HTTPS:
TLS, no SSL" (Raúl Siles, 2016) - https://www.youtube.com/watch?v=87GNHBXKkfg
“Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS)
Implementations”. T. Polk, K. McKay and S. Chokhani. NIST Special Publication 800-52, rev
1. 2014.
“Network Security, Firewalls, and VPNs”. J. Michael Stewart. Jones & Bartlett Learning.
2010.