4. Seguridad y Privacidad en Aplicaciones Telemáticas

Primera Parte: Herramientas de Seguridad y Comunicación Segura

1. Red Team y Blue Team

El modelo Red Team / Blue Team es una metodología de seguridad ofensiva-defensiva que simula ataques reales para evaluar y mejorar las defensas de un sistema.

TipModelo mental: flujo Red Team → Blue Team. 
[Red Team] → Diseña y ejecuta ataques
      ↓
[Informe de vulnerabilidades]
      ↓
[Blue Team] → Analiza, mitiga y monitoriza
      ↓
[Sistema más robusto]

1.1 Red Team

El Red Team es un equipo especializado en actividades ofensivas. Atacan su propio sistema de forma controlada con el objetivo de:

  • Probar la eficacia y robustez de las soluciones de seguridad frente a ataques reales.
  • Analizar posibles fugas de información, conexiones o redirecciones remotas.
  • Determinar posibles comportamientos y técnicas de futuros atacantes.

Metodología de trabajo:

  1. Diseñan ataques específicos adaptados a la arquitectura del sistema objetivo.
  2. Identifican herramientas de hacking apropiadas para explotar vulnerabilidades encontradas.
  3. Ejecutan los ataques prediseñados de forma controlada.
  4. Extraen debilidades y vulnerabilidades para reportarlas al equipo Blue.

1.2 Blue Team

El Blue Team es un equipo especializado en actividades defensivas. Tratan, evitan o mitigan vulnerabilidades con el objetivo de:

  • Proporcionar herramientas, soluciones y estrategias defensivas.
  • Analizar los informes detallados del Red Team para identificar y mitigar vulnerabilidades.
  • Monitorizar las actividades del sistema y elaborar planes de actuación.

Metodología de trabajo:

  1. Recopilan información del sistema y evalúan riesgos.
  2. Identifican soluciones de seguridad existentes o diseñan nuevas para evitar riesgos.
  3. Monitorizan constantemente la seguridad del sistema evaluando los eventos producidos.
  4. Trabajan en la mejora continua de la seguridad del sistema.
NoteRefuerzo conceptual: Red Team vs Blue Team.
  • Red Team = el atacante controlado interno. Simula al adversario.
  • Blue Team = el defensor. Reacciona, monitoriza y endurece el sistema.
  • Ambos equipos colaboran: sin informe del Red Team, el Blue Team no sabe qué corregir.

2. Herramientas Red Team

2.1 Sistemas Operativos Especializados

Kali Linux

Distribución Debian GNU/Linux diseñada principalmente para auditoría y seguridad informática. Ofrece un conjunto relevante de herramientas de seguridad preinstaladas y actualizadas.

Parrot Security OS

Distribución Debian GNU/Linux diseñada específicamente para:

  • Pruebas de penetración (pentesting).
  • Evaluación y análisis de vulnerabilidades.
  • Análisis forense de sistemas.
  • Preservación del anonimato.
  • Análisis y prueba de criptografía.

!(images/6064463a7ac28bd156ca279e607c28bca3dceebc8063db2af78d4182a28c0690.jpg)

2.2 Principales Herramientas en Linux

Herramienta Función principal Capa/Ámbito
Nmap / Zenmap Escaneo de puertos, fingerprinting, detección de SO Red
Wireshark Captura y análisis de tráfico de red (sniffing) Red / Transporte
Hydra Ataque de fuerza bruta a credenciales de acceso Aplicación
Scapy Creación, modificación, envío y captura de paquetes Red
Ettercap Intercepción de comunicaciones mediante ARP spoofing (MitM) Red / Enlace
Metasploit Suite flexible para pruebas de penetración Transversal
Burpsuite Pruebas de seguridad en aplicaciones web Aplicación
Aircrack-ng Descifrado de claves WPA-PSK y WEP Inalámbrico
John the Ripper Derivación y crackeo de contraseñas Aplicación
Maltego Inteligencia de fuentes abiertas (OSINT) y análisis forense OSINT
OWASP-ZAP Pruebas de seguridad en aplicaciones web Aplicación

2.3 Descripción Detallada de Herramientas Clave

Hydra — Fuerza Bruta
TipDefinición.

Hydra es un cracker de inicio de sesión que lanza ataques de fuerza bruta usando un diccionario de posibles contraseñas contra múltiples servicios de red (SSH, FTP, HTTP, SMB, etc.).

!(images/d8d795da8755dce3a22787fe4ed44383494b28265e929ea6d215a5ca341a9214.jpg)

Nmap y Zenmap — Rastreo y Fingerprinting
TipDefinición.

Nmap es una herramienta de escaneo de redes que realiza fingerprinting: recolecta información de un sistema (puertos abiertos, SO, servicios y versiones) para conocer su superficie de ataque. El fingerprinting suele dejar rastro en los logs del sistema objetivo.

  • Compatible con Windows, Linux, macOS y Solaris.
  • Análisis en línea de comandos o mediante interfaz gráfica (Zenmap).

Opciones principales de Nmap:

# Puertos abiertos y servicios (escaneo básico)
nmap IP/localhost

# Ping simple (sin escaneo de puertos)
nmap -sP IP/localhost

# Rango de puertos en modo agresivo
nmap -p T:1-65535 -T4 IP/localhost

# Puertos concretos
nmap -p T:X-Y,Z -T4 IP/localhost

# Puertos, servicios y versiones de los servicios
nmap -sV -T4 IP/localhost

Zenmap es la interfaz gráfica open-source que permite ejecutar estas instrucciones mediante una GUI.

Wireshark — Captura de Tráfico (Sniffing)
TipDefinición.

Wireshark es un disector (analizador) de red multiplataforma que captura tráfico en vivo y permite su análisis fuera de línea. Es la herramienta de referencia para el análisis de protocolos de red.

Características principales:

  • Compatible con Windows, Linux, macOS, Solaris, FreeBSD, NetBSD y otros.
  • Soporte de descifrado para múltiples protocolos: IPsec, ISAKMP, Kerberos, SNMPv3, SSL/TLS, WEP, WPA/WPA2.
  • Exportación en XML, PostScript, CSV o texto plano.
Scapy — Manipulación de Paquetes
TipDefinición.

Scapy es una librería desarrollada en Python con su propio intérprete de línea de comandos. Permite crear, modificar, enviar y capturar paquetes de red de forma programática.

  • Compatible con Linux, macOS y Windows.
  • Ideal para pruebas de protocolo y construcción de exploits a nivel de red.
Ettercap — Ataques Man-in-the-Middle
TipDefinición.

Ettercap es una herramienta que intercepta comunicaciones mediante ARP spoofing (envenenamiento ARP), creando ataques de tipo Man-in-the-Middle (MitM).

Funcionamiento:

  • La máquina del atacante anuncia que su IP es la del router real, pero su dirección MAC es la del atacante.
  • Todo el tráfico de red de la víctima es atraído hacia la máquina del atacante en lugar del router legítimo.
  • El atacante puede capturar, analizar e incluso modificar el tráfico en tránsito.
[Víctima] → (cree hablar con el router) → [Ettercap / Atacante] → [Router real]
                                             ↑ intercepta todo el tráfico
MITRE ATT&CK
TipDefinición.

MITRE ATT&CK es un repositorio de conocimiento ampliamente reconocido que documenta tácticas, técnicas y procedimientos (TTPs) utilizados por atacantes reales, clasificados por ámbito: entornos empresariales, sistemas móviles y sistemas de control industrial (ICS).

  • Disponible públicamente en https://attack.mitre.org.
  • Usado por equipos Red y Blue para modelar amenazas y planificar defensas.
  • Permite mapear ataques a técnicas conocidas, facilitando la detección y respuesta.

3. Seguridad en Email: PGP y S/MIME

El correo electrónico es la aplicación más ampliamente utilizada en entornos distribuidos. Su crecimiento ha generado una mayor necesidad de integrar servicios de autenticación y confidencialidad.

Las dos soluciones de seguridad en email más extendidas son:

  • PGP (Pretty Good Privacy)
  • S/MIME (Secure/Multipurpose Internet Mail Extension)
NoteRefuerzo conceptual: PGP vs S/MIME.
Aspecto PGP S/MIME
Modelo de confianza Web of Trust (distribuida, entre usuarios) Jerarquía de CAs (centralizada, PKI)
Certificados Formato propio (no estándar X.509) X.509v3
Uso típico Personal, técnico, privado Corporativo, comercial
Gestión de claves Descentralizada (anillos de claves) Centralizada (CAs y PKI)
Estándar OpenPGP (RFC 4880) RFC 5751
WarningConfusión habitual.

PGP y S/MIME ofrecen servicios equivalentes (firma y cifrado de correo), pero su modelo de confianza es radicalmente distinto. PGP usa una web of trust donde los propios usuarios avalan las claves ajenas; S/MIME usa una jerarquía de Autoridades de Certificación como en HTTPS.

3.1 PGP (Pretty Good Privacy)

TipDefinición.

PGP es una solución criptográfica diseñada por Phil Zimmerman en 1991. Integra algoritmos criptográficos ya existentes en una única aplicación independiente del sistema operativo, proporcionando servicios de autenticidad y confidencialidad para correo electrónico y almacenamiento de ficheros.

Algoritmos integrados: RSA, DSS, Diffie-Hellman (ElGamal), CAST-128, IDEA, 3DES, SHA-1.

Disponible para Windows, UNIX y Mac (versiones libres y comerciales). El IETF ha estandarizado el formato en la RFC 3156 (MIME Security with OpenPGP).

Servicios de PGP
Función Algoritmos Descripción
Firma digital DSS/SHA o RSA/SHA Hash SHA-1 del mensaje, cifrado con clave privada del remitente
Cifrado del mensaje CAST / IDEA / 3DES + DH o RSA Cifrado con clave de sesión de un solo uso; la clave de sesión se cifra con la clave pública del destinatario
Compresión ZIP El mensaje puede comprimirse antes de cifrar
Compatibilidad email Radix-64 (Base64) Conversión a ASCII para transparencia en clientes de correo
Esquema de Transmisión PGP
EMISOR (A)
   ↓
1. Firma: H(Mensaje) → cifrado con PR_a → Firma digital
2. Cifrado: Mensaje comprimido → cifrado con K_s (sesión)
3. K_s → cifrado con PU_b (clave pública del destinatario)
4. Codificación Radix-64
   ↓
[Correo electrónico]
   ↓
RECEPTOR (B)
   ↓
1. Decodificación Radix-64
2. Descifrar K_s con PR_b → obtiene K_s
3. Descifrar mensaje con K_s
4. Verificar firma con PU_a

Notación utilizada en los diagramas:

  • \(K_s\): clave de sesión (simétrica, de un solo uso)
  • \(PR_a / PU_a\): clave privada/pública del usuario A
  • \(H\): función hash (SHA-1)
  • \(Z\): compresión ZIP
  • \(R64\): conversión a Radix-64
Gestión de Claves: Anillos de Claves

PGP proporciona, para cada usuario U, dos estructuras de datos:

  • Private-Key Ring: almacena los pares <clave pública, clave privada> propios del usuario U. La clave privada se almacena cifrada: \(E(H(P_i), PR_i)\).
  • Public-Key Ring: almacena las claves públicas de los otros usuarios con los que U se comunica.

Private-Key Ring:

Timestamp Key ID (\(PU_i \mod 2^{64}\)) Public Key Encrypted Private Key User ID
\(T_i\) \(PU_i \mod 2^{64}\) \(PU_i\) \(E(H(P_i), PR_i)\) User \(i\)

Public-Key Ring:

Timestamp Key ID Public Key Owner Trust User ID Key Legitimacy Signature(s) Signature Trust
\(T_i\) \(PU_i \mod 2^{64}\) \(PU_i\) trust_flag\(_i\) User \(i\) trust_flag\(_i\)
NoteRefuerzo conceptual: certificados PGP.

Cada fila del Public-Key Ring actúa como un certificado digital no estándar. PGP no usa el formato X.509, sino un formato propio. La legitimidad de una clave pública se determina a través de la web of trust: cuantas más firmas de usuarios de confianza tiene una clave, más legítima se considera.

OpenPGP y Aplicaciones

OpenPGP (RFC 4880) es el estándar abierto derivado del PGP original. Permite cifrar emails usando criptografía de clave pública con un formato interoperable.

Aplicaciones que soportan OpenPGP:

Plataforma Cliente de correo Plugin/Herramienta
Windows Outlook gpg4o, Gpg4win, p=p
Windows/Linux/Mac Thunderbird Enigmail
Mac Apple Mail GPGTools
Android K-9 Mail OpenKeychain
iOS — iPGMail
Linux Evolution Seahorse
Linux Kmail Kleopatra

GnuPG es la implementación de referencia del estándar OpenPGP. Permite:

  • Gestionar y generar claves públicas y privadas.
  • Visualizar y distribuir claves públicas (exportar/importar).
  • Cifrar y descifrar documentos.
  • Firmar y validar documentos.

3.2 S/MIME (Secure/Multipurpose Internet Mail Extension)

TipDefinición.

S/MIME es una mejora de seguridad del formato MIME para correo electrónico (que a su vez mejora SMTP). Proporciona firma digital y cifrado de mensajes basándose en una infraestructura PKI con certificados X.509v3.

Documentos de referencia:

  • RFC 5652: Cryptographic Message Syntax (CMS)
  • RFC 5750: Certificate Handling (versión 3.2)
  • RFC 5751: Message Specification (versión 3.2)
Modelo de Confianza S/MIME

S/MIME sigue un modelo PKI híbrido entre la jerarquía estricta de Autoridades de Certificación (CA) y el modelo en malla. Utiliza certificados de clave pública con formato X.509v3.

NoteRefuerzo conceptual: jerarquía de CAs vs web of trust.
  • En S/MIME, una CA (como DigiCert o Sectigo) certifica la identidad del usuario. Si confías en la CA, confías en el certificado.
  • En PGP, cualquier usuario puede firmar la clave de otro. La confianza es transitiva y social.
Algoritmos Criptográficos S/MIME
Función Requisito
Resumen del mensaje (firma) MUST SHA-1; SHOULD MD5 (retrocompat.)
Cifrado del resumen (firma digital) MUST DSS; SHOULD RSA
Cifrado de clave de sesión SHOULD DH; MUST RSA (512–1024 bits)
Cifrado del mensaje MUST Triple-DES; SHOULD AES; SHOULD RC2/40
Código de autenticación (MAC) MUST HMAC-SHA-1
ImportantImportante: consolidación de estándares.

Aunque tanto PGP como S/MIME están en vías de estandarización, S/MIME tiende a consolidarse como el estándar para uso comercial, mientras que PGP permanece predominante para uso personal y técnico.

4. Conexión Remota Segura

4.1 Telnet y FTP — Protocolos Inseguros

WarningImportante: comunicación en claro.

Tanto Telnet como FTP transmiten toda la información en texto claro, incluyendo credenciales (usuario y contraseña). No se recomienda su uso en redes no confiables.

Protocolo Puerto Función
Telnet 23 (TCP) Acceso remoto a sistemas; el terminal local emula el terminal remoto
FTP 20/21 (TCP) Transferencia de ficheros entre recursos remotos

Problema fundamental: La información transferida y las acciones remotas se realizan completamente en claro, exponiendo contraseñas, comandos y datos.

4.2 SSH: Secure Shell v2

TipDefinición.

SSH (Secure Shell) es una herramienta similar a Telnet que opera en el puerto 22 (TCP). Permite acceso remoto seguro mediante el modelo cliente/servidor, cifrando todas las transacciones usando criptografía de clave pública.

Arquitectura de Capas de SSH
Cliente SSH
    │
    ├── Capa de Aplicación
    │       Autenticación del cliente:
    │       - Modo básico: usuario + contraseña
    │       - Modo avanzado: criptografía de clave pública (par de claves SSH)
    │
    ├── Capa de Transporte
    │       - Intercambio inicial de claves
    │       - Establecimiento de modos de cifrado y compresión
    │
    └── Capa de Red
            - Conexión directa cliente-servidor
            - Modo túnel (cifrado simétrico negociado en la capa de transporte)

Servidor SSH
Protección contra Ataques

SSH mitiga o evita ataques específicos:

  • IP Spoofing: suplantación de identidad por nodo remoto.
  • DNS Spoofing: el atacante suplanta el nombre del servidor.
Clientes SSH

Dos clientes de referencia multiplataforma:

  • PuTTY (Windows/Linux): cliente SSH gráfico muy extendido.
  • OpenSSH (Linux/macOS/Windows): implementación open-source de SSH.

4.3 SFTP y FTPS — Transferencia Segura de Ficheros

WarningConfusión habitual: SFTP ≠ FTPS.

SFTP y FTPS son dos protocolos completamente distintos que se confunden frecuentemente por sus nombres similares.

  • SFTP = SSH File Transfer Protocol → funciona dentro del túnel SSH (puerto 22).
  • FTPS = FTP Secure → FTP con soporte para TLS/SSL (puerto 990 o 21).

Son protocolos diferentes, con arquitecturas y mecanismos de cifrado distintos.

SFTP (SSH File Transfer Protocol)

SSH puede usarse también para transferencia de ficheros, conocido como SFTP (y SCP — Secure Copy).

Modos de autenticación en SFTP:

  • Modo básico: usuario y contraseña convencionales.
  • Modo avanzado: uso de claves públicas SSH previamente generadas. El cliente transmite su clave pública al servidor para autenticación; no se envía ninguna contraseña.

Todas las conexiones SFTP están cifradas a nivel de red mediante el túnel SSH.

FTPS (FTP Secure)

FTPS proporciona soporte adecuado para TLS (Transport Layer Security).

Funcionamiento:

  1. El cliente verifica que el certificado del servidor es correcto y de confianza.
  2. Se negocia una clave de sesión (proceso similar al handshake TLS).
  3. Las credenciales (usuario y contraseña) se cifran a lo largo de la conexión FTPS.
Cliente FTPS
    │
    ├── 1. Verificación del certificado del servidor (X.509)
    ├── 2. Negociación de clave de sesión (TLS handshake)
    └── 3. Transferencia cifrada de datos y credenciales

Servidor FTPS
Comparativa SSH / SFTP / FTPS vs Telnet / FTP
Característica Telnet/FTP SSH SFTP FTPS
Cifrado No (texto claro) Sí (simétrico + asimétrico) Sí (tunel SSH) Sí (TLS)
Autenticación Usuario/contraseña (en claro) Contraseña o clave pública Contraseña o clave pública Certificado X.509
Puerto 23 / 20-21 22 22 990 o 21
Uso recomendado ❌ Obsoleto ✅ Acceso remoto ✅ Transferencia de ficheros ✅ FTP con TLS

5. Herramientas de Cifrado

5.1 Herramientas Open-Source

TrueCrypt
TipDefinición.

TrueCrypt es una herramienta de cifrado de discos duros disponible para Windows (XP/2000/2003) y Linux. Soporta los algoritmos: AES-256, Blowfish, CAST5, Serpent, Triple DES y Twofish. Permite también la ocultación de particiones mediante cifrado y aleatoriedad de la información.

DiskCryptor

Similar a TrueCrypt, pero con la capacidad adicional de cifrar dispositivos de almacenamiento externo USB. Incluye algoritmos: AES, Twofish y Serpent.

VeraCrypt
TipDefinición.

VeraCrypt es el sucesor espiritual de TrueCrypt. La diferencia clave es que incluye un número específico de iteraciones para el proceso de cifrado, lo que aumenta la resistencia a ataques de fuerza bruta a costa de una mayor lentitud en operaciones de lectura/escritura en disco. Aplica: AES, Twofish y Serpent.

Herramientas de Esteganografía
TipDefinición: Esteganografía.

La Esteganografía (del griego “cubierto” u “oculto” + “escritura”) es la técnica de ocultar información dentro de otro medio (imagen, audio, vídeo) de forma que su existencia sea imperceptible. A diferencia del cifrado (que oculta el contenido), la esteganografía oculta la existencia del mensaje.

  • OpenStego: aplica técnicas de esteganografía para ocultar información usando imágenes o archivos multimedia.
  • OpenPuff: similar a OpenStego para Windows, con soporte para BMP, JPG, MP3, WAV y MP4.

5.2 Herramientas Propietarias

BitLocker
TipDefinición.

BitLocker es una herramienta de cifrado de disco completo desarrollada por Microsoft para proteger los datos almacenados en discos duros o unidades flash USB. Disponible en varias ediciones de Windows, compatible con los sistemas de archivos NTFS y exFAT.

Característica destacada: hace uso de hardware criptográfico para el cifrado del disco mediante el TPM (Trusted Platform Module), un chip de seguridad integrado en la placa base que almacena las claves de cifrado y valida la integridad del sistema en el arranque.

Herramienta Plataforma Algoritmos Soporte USB TPM
TrueCrypt Windows / Linux AES-256, Blowfish, Serpent, Twofish, 3DES, CAST5 No No
DiskCryptor Windows AES, Twofish, Serpent Sí No
VeraCrypt Windows / Linux / Mac AES, Twofish, Serpent Sí No
BitLocker Windows AES-128/256 Sí Sí

Segunda Parte: Seguridad en Pagos Electrónicos

1. Conceptos Generales

1.1 Introducción

En el ámbito del e-commerce se han desarrollado esquemas de pago electrónico que proporcionan en el mundo digital la misma heterogeneidad y funcionalidad que los sistemas de pago tradicionales. Los pagos se realizan a través de redes abiertas como Internet, pero la correspondencia entre los pagos electrónicos y la transferencia del valor real es realizada y garantizada por los bancos, a través de los sistemas financieros de compensación, que operan sobre redes cerradas de las instituciones bancarias.

Participantes en un Pago Electrónico
[Comprador] ←→ [Internet] ←→ [Vendedor]
                                    │
                            [Pasarela de pago]
                                    │
                         [Red bancaria privada]
                                    │
                    [Banco emisor] ←→ [Banco adquirente]
                                    │
                    [TTP / Árbitro de disputas] (opcional)

En general, los pagos electrónicos involucran a un comprador y a un vendedor, aunque pueden existir:

  • TTPs (Trusted Third Parties): entidades de confianza que participan en la transacción.
  • Mediadores para la resolución de disputas (en muchos protocolos, las disputas se resuelven fuera del sistema de pago).

1.2 Clasificación de los Sistemas de Pago

Por el momento en que el vendedor contacta con el banco
Tipo Descripción
On-line Antes de enviar el producto, el vendedor verifica con la entidad financiera la validez del pago del comprador
Off-line El vendedor acepta el pago y envía el producto sin contactar con el banco durante la compra-venta; deposita el dinero para verificación posteriormente
Por el momento en que se retira el dinero de la cuenta del comprador
Tipo Analogía Descripción
Pre-pago Monedero electrónico, tarjeta telefónica, papel moneda La cuenta del comprador se decrementa antes de la compra
Pago instantáneo Tarjeta de débito El cargo se realiza en el momento exacto de la compra
Post-pago Tarjeta de crédito El banco garantiza el pago al vendedor; el comprador ve decrementada su cuenta tiempo después
WarningConfusión habitual: pre-pago vs pago instantáneo.

El pre-pago implica cargar fondos en un monedero o tarjeta con antelación, antes de saber qué se va a comprar. El pago instantáneo (débito) se produce en el momento de la compra, pero sin reserva previa de fondos.

Por la cantidad implicada en la transacción
Categoría Umbral
Micropagos < 1 €
Pagos Entre 1 € y 10 €
Macropagos > 10 €
NoteRefuerzo conceptual: micropagos.

Los pagos inferiores a 10 € presentan el problema del coste de implementación: no tendría sentido utilizar un sistema de pago cuyo coste económico sea del orden de magnitud del importe de la transacción. Esto motiva el uso de protocolos criptográficos más ligeros (hash, criptografía simétrica) para micropagos.

1.3 Problemas de Seguridad y Soluciones

Los sistemas de pago electrónico están expuestos a:

  • Ataques de escucha (eavesdropping).
  • Suplantación de identidad (del cliente o del comerciante).
  • Generación de datos falsos.
  • Modificación de datos en tránsito.

Para mitigarlos, los protocolos suelen implementar: primitivas criptográficas, mecanismos de autenticación y autorización de usuarios, firmas digitales y certificados digitales.

1.4 Breve Historia: El Papel de SSL

Inicialmente se aplicaba SSL (Secure Sockets Layer) como medida de protección de los canales de comunicación en pagos electrónicos.

SSL fue creado por Netscape en 1994. Proporcionaba criptografía híbrida:

  • Asimétrica: autenticación mediante certificados X.509 v3 y negociación de claves de sesión (RSA o Diffie-Hellman).
  • Simétrica: cifrado de punto a punto (DES, 3DES, RC2, RC4, IDEA).
  • Integridad: mediante MAC (MD5 o SHA-1).
ImportantImportante: SSL está obsoleto.

La última versión SSLv3 está obsoleta. Fue reemplazado por TLS. No debe usarse SSL en ningún sistema moderno.

Sin embargo, SSL presentaba problemas para pagos electrónicos:

  • Solo protege transacciones entre dos puntos, mientras que una transacción con tarjeta involucra al menos un banco.
  • No protege al comprador frente al vendedor: el vendedor obtiene datos de la tarjeta que puede usar ilícitamente.
  • No hay mecanismos de autenticación de tarjetas ni de facturación/recibos.

Esto motivó el desarrollo de protocolos de pago más específicos.

2. Protocolo SET (Secure Electronic Transaction)

TipDefinición.

SET (Secure Electronic Transaction) es un protocolo desarrollado en 1996 por VISA y Mastercard (con American Express, IBM, Microsoft, Verisign, RSA, Netscape y GTE) para proporcionar seguridad a las transacciones electrónicas basadas en tarjetas de crédito, reducir el fraude mercantil y garantizar el pago a través de redes abiertas.

No es un sistema de pago en sí mismo, sino un conjunto de protocolos de seguridad y formatos estándar que permiten usar de forma segura la infraestructura ya existente de tarjetas de crédito.

2.1 Servicios de Seguridad que Proporciona

  • Confidencialidad en las comunicaciones entre todas las entidades de la transacción.
  • Autenticación mediante certificados digitales X.509 (obligatorio para cliente, vendedor y pasarela de pago).
  • Privacidad: la información solo está disponible para cada entidad cuando y donde es necesario.
  • Integridad mediante firmas digitales.
  • No repudio, reduciendo disputas.
  • Autorización de pago y confirmación de la transacción.

2.2 Participantes en SET

[Comprador / Cardholder]
         │
         ├──────────────────→ [Vendedor / Merchant]
         │                            │
         │                   [Pasarela de Pago / Payment Gateway]
         │                            │
         └──────────→ [Banco Emisor] ←→ [Banco Adquirente]
                              │
                        [CA / PKI SET]

2.3 Pasos del Protocolo SET

Paso Acción
1. Petición del producto El comprador selecciona el producto y solicita el pedido al vendedor
2. Inicialización El vendedor envía sus certificados digitales al comprador
3. Información del pedido e instrucciones de pago El comprador envía la descripción de la compra (OI) y las instrucciones de pago (PI) usando la firma dual
4. Petición de autorización El vendedor contacta con la pasarela de pago; la pasarela contacta con el banco emisor
5. Aprobación de autorización El banco emisor autoriza (o deniega) el pago; la pasarela responde al vendedor
6. Finalización El vendedor reclama la cantidad a la pasarela; petición de compensación hacia el banco del vendedor

2.4 Firma Dual (Innovación Técnica de SET)

TipDefinición: Firma Dual.

La firma dual es una innovación técnica de SET cuyo propósito es enlazar dos mensajes que han de ir a receptores distintos sin que cada receptor conozca el contenido del mensaje del otro:

  • La información de pago (PI) va al banco.
  • La información del pedido (OI) va al comerciante.

Objetivo de privacidad:

  • El comerciante recibe los detalles del pedido, pero NO el número de tarjeta del cliente.
  • El banco recibe las instrucciones de pago, pero NO los detalles del pedido.
  • Sin embargo, ambos documentos quedan criptográficamente enlazados para una posible resolución de disputas posterior.

Notación:

Símbolo Significado
PI Payment Information (información de pago)
OI Order Information (información del pedido)
H Función hash SHA-1
|| Concatenación
PIMD PI message digest = H(PI)
OIMD OI message digest = H(OI)
POMD Payment Order message digest = H(PIMD || OIMD)
E Cifrado RSA
PRc Clave privada del cliente

Construcción de la Firma Dual:

H(PI) → PIMD ─┐
               ├─ H(PIMD || OIMD) → POMD → E(PRc, POMD) → Firma Dual
H(OI) → OIMD ─┘
  • Verificación por el vendedor: recibe OI, PIMD y la Firma Dual. Puede verificar que el PIMD es coherente sin conocer PI.
  • Verificación por el banco: recibe PI, OIMD y la Firma Dual. Puede verificar que el OIMD es coherente sin conocer OI.
Important¡Hay NO-REPUDIO!

Gracias a la firma dual, el cliente no puede negar haber enviado tanto las instrucciones de pago como la información del pedido.

2.5 Ventajas y Desventajas de SET

Ventajas Desventajas
Seguro y bien diseñado Dependiente de algoritmos específicos (RSA, DES, SHA-1)
Garantiza autenticación, confidencialidad, integridad y no-repudio Gestión compleja de certificados digitales
Garantiza privacidad (vendedor no accede a datos de tarjeta; banco no accede a detalles del pedido) Fuerte esfuerzo de implantación (especialmente para el vendedor)
Reduce disputas gracias al no-repudio No adaptado a micropagos

3. Protocolo CyberCash

TipDefinición.

CyberCash es un protocolo de pago electrónico basado en el uso de una pasarela propia que gestiona los pagos electrónicos. Permite el uso de cualquier tipo de tarjeta e integra el software de cliente (CyberWallet) con la red financiera del banco del comprador.

3.1 Pasos del Protocolo CyberCash

Paso Acción
1 Orden de compra (descripción del producto)
2 Petición de pago (precio)
3 Orden de pago (firmada por el CyberWallet)
4 Redirección de la orden de pago
5 Verificación del pedido y petición de autorización
6 Petición de autorización al banco emisor
7 Respuesta de autorización (banco adquirente y pasarela)
8 Envío de facturas cifradas (cliente y comerciante)
9 Redirección de la factura del cliente

3.2 Problemas de CyberCash

WarningImportante: problema de privacidad en CyberCash.

Parte de la información del cliente es conocida por la pasarela “privada”, lo que permite analizar los hábitos del cliente — problema de privacidad que no existía en SET.

  • Hace uso de DES y RSA (1024 bits).
  • Tras caer en bancarrota, Verisign adquirió los derechos. Posteriormente, PayPal compró la solución a Verisign.

4. Protocolo iKP (i-Key Protocol)

TipDefinición.

iKP (donde i = 1, 2 o 3) es una familia de protocolos de pago basados en criptografía de clave pública, desarrollada por IBM. La implantación es gradual para conseguir un pago seguro multiparte completo, requiriendo una infraestructura de certificación avanzada.

Los tres protocolos (1KP, 2KP, 3KP) se diferencian en el número de entidades que poseen certificado digital:

Protocolo Entidades con certificado Nivel de seguridad
1KP Solo el banco (adquirente) Básico
2KP Banco + Vendedor Intermedio
3KP Banco + Vendedor + Cliente Completo

4.1 Elementos Intercambiados en iKP

Item Descripción
CAN Número de cuenta del cliente (ej. número de tarjeta)
\(ID_M\) Identificador del comerciante
\(TID_M\) ID de transacción (identificador único)
DESC Descripción de los bienes; incluye nombre del titular y BIN bancario
\(SALT_C\) Número aleatorio del cliente para aleatorizar DESC (privacidad del enlace M→A)
\(NONCE_M\) Número aleatorio del vendedor para proteger frente a replay
DATE Fecha/hora actual del vendedor
PIN PIN del cliente (opcional en 1KP)
CID Pseudo-ID del cliente: \(CID = H(R_C, CAN)\)
Common Información en común: PRICE, \(ID_M\), \(TID_M\), DATE, \(NONCE_M\), CID, \(H(DESC, SALT_C)\)
SLIP Instrucciones de pago: PRICE, \(H(Common)\), CAN, \(R_C\)
EncSlip SLIP cifrado con la clave pública del banco: \(PK_A(SLIP)\)

⚠️ No es necesario memorizar todos los campos; sirven de referencia para comprender la estructura del protocolo.

4.2 Protocolo 1KP

Solo el banco necesita poseer (y distribuir) su certificado digital \(CERT_A\).

Actor Información inicial
Cliente DESC, CAN, \(PK_{CA}\), [PIN], \(CERT_A\)
Vendedor DESC, \(PK_{CA}\), \(CERT_A\)
Banco (adquirente) \(SK_A\), \(CERT_A\)

Desventajas de 1KP:

  • El cliente se autentica solo con número de tarjeta y PIN opcional, no con firma digital.
  • El vendedor no se autentica ante el cliente ni ante el banco.
  • Ni el vendedor ni el cliente proporcionan evidencias de intervención en la transacción.

4.3 Protocolo 2KP

Además del banco, cada vendedor necesita un par <clave pública, clave privada> y distribuir su certificado \(CERT_M\) al cliente y al banco.

Actor Información inicial
Cliente DESC, CAN, \(PK_{CA}\), \(CERT_A\)
Vendedor DESC, \(PK_{CA}\), \(CERT_A\), \(SK_M\), \(CERT_M\)
Banco (adquirente) \(PK_{CA}\), \(SK_A\), \(CERT_A\)

Con 2KP, el vendedor puede firmar mensajes y queda autenticado ante el banco.

5. Micropagos y Protocolo Millicent

5.1 El Problema de los Micropagos

En algunos escenarios hay que transferir cantidades muy pequeñas. El objetivo es minimizar el tráfico y los recursos utilizados para que los costes de realizar el pago sean mínimos en comparación con el pago en sí mismo.

Soluciones aplicadas:

  • Servicios de prepago.
  • Autorizaciones off-line.
  • Agrupación de facturas para micropago por lotes.
  • Soluciones online usando funciones hash (la criptografía de clave pública es demasiado costosa para micropagos).
WarningImportante: hash y no-repudio en micropagos.

El uso de funciones hash en micropagos conlleva la imposibilidad de garantizar el no-repudio, ya que no se generan firmas digitales verificables.

5.2 Protocolo Millicent

TipDefinición.

Millicent es un protocolo para gestionar micropagos basado en criptografía simétrica que NO utiliza procesamiento online. Introduce la figura del agente de negocios (broker) y usa una forma de moneda electrónica denominada scrip.

Concepto de Scrip:

Los scrips son “cupones electrónicos” que representan dinero, con los que el comprador obtiene la mercancía del vendedor. No sería eficiente comprar scrips para cada vendedor por separado; el broker vende lotes mixtos de scrips de distintos vendedores.

Participantes:

  • Cliente / Comprador
  • Vendedor / Comerciante (A)
  • Agente de negocios / Broker (institución financiera)

Flujo del protocolo Millicent:

1. Compra-Venta de scrips de A (broker ↔ vendedor A)
2. Cliente compra scrips de agente (MACROPAGO)
3. Agente envía scrips al cliente
4. Cliente compra scrips de A (MICROPAGO mediante scrips de agente)
5. Agente envía scrips de A al cliente
6. Cliente envía petición + MICROPAGO (scrips de A) al vendedor
7. Vendedor envía el producto al cliente

Modelo de anonimato en Millicent:

  • El agente conoce la identidad del comprador y su número de tarjeta, pero nunca sabe qué producto compra.
  • El vendedor sabe lo que el cliente compra, pero desconoce su identidad.

Este modelo multiparte proporciona un cierto grado de anonimato por parte del comprador.

Otros sistemas de micropago: Subscrip, Kleline, Flattr, M-coin.

Tercera Parte: Privacidad de los Usuarios en Aplicaciones

1. Conceptos Generales de Privacidad

1.1 Definición de Privacidad

TipDefinición: Privacidad.

La privacidad puede definirse como el derecho de los individuos y entidades de proteger, salvaguardar y controlar el acceso, almacenamiento, distribución y uso de información sobre su “propia persona”. La información a proteger depende de lo que el usuario considere privado: identidad, localización, preferencias, rutinas, etc.

1.2 Privacidad ≠ Confidencialidad

ImportantImportante: distinción fundamental.

Confidencialidad y privacidad son conceptos distintos que se confunden frecuentemente:

  • Confidencialidad → relativa a los datos: mantener datos en secreto.
  • Privacidad → relativa a las personas: mantener la integridad de la persona.

El cifrado de un mensaje garantiza confidencialidad pero no necesariamente privacidad: las cabeceras IP (origen, destino) siguen siendo visibles.

1.3 Formas de Violar la Privacidad

Rastreo de Actividad en la Red

Todo lo que se sube a la red es público y se pierde el control sobre esa información. Las redes sociales facilitan la adquisición de información personal que puede usarse para: despidos, robos, discriminación, incriminación, etc.

Análisis de Tráfico

El análisis de tráfico permite a observadores externos obtener información a través de las comunicaciones de un usuario:

  • Si la comunicación está en claro: el atacante accede directamente a la carga útil.
  • Si la comunicación está cifrada: el cifrado solo protege los datos, no las cabeceras (dirección IP origen y destino). Además, se puede estimar: tamaño de los paquetes, número de paquetes, frecuencia y tiempos de envío.
[Comunicación cifrada]
    → Dirección IP origen: VISIBLE
    → Dirección IP destino: VISIBLE
    → Tamaño de paquetes: ESTIMABLE
    → Frecuencia y tiempos: ESTIMABLE
    → Contenido del mensaje: CIFRADO ✓

1.4 Enfoques para Proteger la Privacidad

Enfoque Descripción
Legislativo Creación de leyes que impongan sanciones y limiten prácticas abusivas (ej. GDPR en Europa)
Tecnológico Mecanismos de preservación de la privacidad basados en algoritmos criptográficos, probabilísticos y de aleatorización

1.5 Propiedades de la Privacidad

  • No-vinculación (unlinkability): incapacidad de un atacante para relacionar dos mensajes o entidades observadas.
  • No-observabilidad (unobservability): imposibilidad de distinguir la presencia de mensajes o la identidad de las entidades.

1.6 Tipos de Anonimato

El anonimato se define como “el estado de no ser identificable entre un grupo de sujetos”. Las técnicas de anonimato buscan hacer indistinguible a un individuo dentro de un conjunto de identidades con características similares.

Tipo Descripción
Pseudónimos Oculta la identidad mediante alias; el uso continuado puede permitir derivar la identidad real
Anonimato rastreable Ofrece anonimato, pero en caso de necesidad se puede revelar la identidad del usuario (ej. banco/vendedor honesto)
Anonimato no rastreable Garantiza que la identidad de los usuarios no puede revelarse bajo ninguna circunstancia
Anonimato no rastreable y no vinculante Además de no poder revelar la identidad, el conjunto de operaciones del usuario no puede vincularse entre sí

1.7 Técnicas para Conseguir Privacidad

  • Esquemas avanzados de firma digital: permiten que entidades autorizadas firmen sin revelar su identidad.
  • Protocolos criptográficos y de enrutado: evitan que la dirección de red o el camino de los paquetes identifiquen a las partes comunicantes.
  • Técnicas de ofuscación: mecanismos basados en generalización o supresión de información para limitar la precisión de lo que se revela.

2. Privacidad Basada en Esquemas Avanzados de Firma Digital

A partir del concepto básico de firma digital surgen esquemas más avanzados con objetivos más ambiciosos:

Esquema Anonimato Descripción breve
Firma ciega Rastreable El firmante firma sin conocer el contenido
Firma de grupo Rastreable Cualquier miembro firma en nombre del grupo; el administrador puede revelar al firmante
Firma de anillo No rastreable ni vinculante Similar a grupo pero sin administrador ni posibilidad de revelar al firmante

2.1 Firma Ciega (Blind Signature)

TipDefinición.

Con la firma ciega, el mensaje M generado por Bob es firmado por Alice sin que esta conozca su contenido. La firma resultante puede verificarse públicamente con posterioridad como una firma digital normal. Proporciona anonimato rastreable.

Caso de uso típico: voto electrónico, donde la autoridad electoral firma el voto para validar que el votante tiene derecho a votar, pero sin conocer el contenido del voto.

Implementación con RSA:

Sean \(e\) y \(d\) las claves pública y privada de Alice, \(n\) el módulo RSA, y \(r\) un número aleatorio mod \(n\) (blinding factor).

  1. Bob genera \(r\) aleatorio.
  2. Bob calcula: \(M^* = M \cdot r^e \mod n\) (mensaje “cegado”).
  3. Bob envía \(M^*\) a Alice.
  4. Alice firma: \((M^*)^d \mod n = [M^d \cdot (r^e)^d \mod n] = [M^d \cdot r \mod n]\).
  5. Bob elimina el factor cegador: \(M^d \cdot r \cdot r^{-1} \mod n = M^d \mod n\).

El resultado \(M^d \mod n\) es la firma legítima de Alice sobre \(M\), pero Alice nunca vio \(M\).

BOB                                  ALICE
 │                                     │
 ├─ r (random) ─→ M* = M·rᵉ mod n     │
 │                                     │
 ├─────────────── M* ────────────────→ │
 │                                     ├─ (M*)ᵈ = Mᵈ·r mod n  (firma ciega)
 │ ←──────────── (M*)ᵈ ───────────────┤
 │                                     │
 ├─ Elimina r: Mᵈ·r·r⁻¹ = Mᵈ mod n   │
 │   → Firma válida de Alice sobre M   │

2.2 Firma de Grupo

TipDefinición.

Los esquemas de firma de grupo permiten que cualquier miembro de un grupo firme en nombre del grupo de forma anónima. Un administrador del grupo puede, en caso de disputa, revelar la identidad del firmante. Proporciona anonimato rastreable.

Ejemplo: un empleado de un banco firma documentos en nombre del banco sin revelar cuál empleado firmó.

Participantes:

  • Administrador del grupo: controla la membresía, emite la clave de firma del grupo y puede “abrir” cualquier firma.
  • Miembro del grupo: firma mensajes de forma anónima en nombre del grupo.
  • Verificador: receptor del documento firmado; puede verificar que la firma pertenece al grupo.

Propiedades requeridas (anonimato rastreable):

  • Solo los miembros del grupo pueden firmar correctamente (infalsificable).
  • Nadie excepto el administrador puede descubrir qué miembro firmó (anonimato).
  • Nadie excepto el administrador puede saber si dos firmas provienen del mismo miembro (no-vinculación).
  • Los miembros no pueden evitar que el administrador abra la firma.

Procedimientos de un esquema de firma de grupo:

Procedimiento Descripción
① Establecimiento Protocolo entre administrador y miembros. Genera: clave pública del grupo \(Y\), claves privadas individuales \(X_i\), clave secreta de administración \(Z\)
② Firma \(S = E_{X_i}(M)\): el miembro \(i\) firma el mensaje \(M\) con su clave privada
③ Verificación \(E_Y(S) == M\): cualquier usuario verifica con la clave pública del grupo
④ Apertura El administrador identifica al firmante usando la clave secreta \(Z\); devuelve la identidad y una prueba de este hecho

Ejemplo básico de diseño (Ejemplo 1):

  • El administrador proporciona a cada miembro \(i\) una lista disjunta de claves privadas: \(L_i = \{X_{i,1}, \ldots, X_{i,n}\}\).
  • Se publican en un directorio público, en orden aleatorio, todas las claves públicas correspondientes (clave pública del grupo \(Y\)).
  • Cada miembro firma un mensaje con una sola clave privada de su lista (para evitar vinculación).
  • El receptor verifica con la clave pública del directorio.
  • El administrador, conociendo todas las claves privadas, puede identificar al firmante.

Ejemplo 2 — basado en RSA:

Sea \(e\) el exponente público del grupo (clave pública \(Y\)), \(C_p = (p_1, p_2, \ldots, p_L)\) primos relativos a \(e\), y \(n = p_1 \cdot p_2 \cdots p_L\) el módulo compuesto.

Se generan módulos individuales para cada miembro: \(n_i = p_{i1} \cdot p_{i2}\)

Se calculan exponentes privados: \(d_i = e^{-1} \mod \theta(n_i)\)

  • Firma del miembro \(k\): \(S = M^{d_k} \bmod n_k\)
  • Verificación: \(M' = S^e \bmod n\)
  • Apertura (administrador): prueba firma con las claves privadas de cada miembro hasta encontrar la coincidencia.

2.3 Firma de Anillo

TipDefinición.

Las firmas de anillo son similares a las firmas de grupo, pero con anonimato total e incondicional: no existe administrador, ni procedimiento de establecimiento, ni mecanismo de revocación del anonimato. Proporciona anonimato no rastreable ni vinculante.

Características diferenciadoras:

  • No hay administrador de grupo ni clave secreta de administración.
  • No hay procedimiento de establecimiento formal entre los posibles firmantes.
  • No hay revocación del anonimato bajo ninguna circunstancia.
  • Cualquier usuario puede elegir un conjunto de posibles firmantes (incluyéndose él mismo) sin la aprobación ni ayuda de esos otros miembros.
  • Computa la firma usando solo su propia clave privada y las claves públicas de los demás.
  • Los otros miembros pueden desconocer totalmente que sus claves públicas están siendo utilizadas.

3. Privacidad Basada en Protocolos Criptográficos y de Enrutado

Los protocolos criptográficos y de enrutado tratan de proteger el tráfico frente a entidades que observan las comunicaciones. Las soluciones se clasifican en cuatro categorías:

Categoría Arquitectura Latencia
a) Proxy Centralizada Baja
b) Mezcladores (Mix Networks) Centralizada Alta
c) Enrutado de Cebolla (Onion Routing) Centralizada Muy alta
Tor (2ª generación de Onion Routing) Centralizada Media-baja
d) Crowds / Hordes Distribuida Media-baja

3.1 Proxy

TipDefinición.

Un servidor proxy actúa como intermediario en la comunicación, aceptando conexiones de los clientes y reenviándolas, ocultando así la dirección IP del verdadero origen. El destino cree que el origen de la comunicación es el proxy.

Limitaciones:

  • No protegen frente a atacantes externos que controlen parte de la red.
  • El proxy puede ser “honesto pero curioso”: conoce la identidad real del usuario y su destino.

3.2 Mix Networks (Mezcladores)

TipDefinición.

Los mezcladores (mixers) son un tipo de proxy capaz de ocultar la relación entre los mensajes que recibe y los que envía. Son dispositivos de almacenamiento y reenvío.

Funcionamiento:

  1. El usuario envía el mensaje cifrado al mixer.
  2. El mixer lo almacena durante cierto tiempo para mezclarlo con otros mensajes recibidos.
  3. Los mensajes salen del mixer en un orden diferente al de llegada.

El esquema funciona solo si el número de mensajes almacenados temporalmente es suficientemente grande (para que la mezcla sea efectiva).

Limitaciones:

  • Los retrasos introducidos pueden ser grandes.
  • El mezclador puede ser honesto o deshonesto, pero siempre curioso.

3.3 Onion Routing y Tor

Onion Routing
TipDefinición.

El Onion Routing (enrutado de cebolla) es un mecanismo en el que el onion proxy crea un paquete cifrado en capas, que se irán “pelando” a medida que el paquete atraviese una cadena de onion routers. Cada nodo solo descifra su capa y solo conoce el nodo anterior y el siguiente.

[Alice] → Cifra con K_nodo3(Cifra con K_nodo2(Cifra con K_nodo1(Mensaje)))
               ↓
         [Nodo 1] → descifra con K_nodo1 → ve solo "enviar a Nodo 2"
               ↓
         [Nodo 2] → descifra con K_nodo2 → ve solo "enviar a Nodo 3"
               ↓
         [Nodo 3] → descifra con K_nodo3 → ve solo "enviar a Destino"
               ↓
         [Destino]

Analogía: como una cebolla con capas. Cada nodo “pela” una capa (descifra su nivel) pero no puede ver las capas internas.

Limitación de Onion Routing: vulnerable a ataques en un extremo (el atacante controla el nodo de entrada o de salida).

Tor — Segunda Generación de Onion Routing
TipDefinición.

Tor (The Onion Router) es la segunda generación de Onion Routing. Evita algunas deficiencias del diseño original añadiendo control de congestión, comprobación de integridad y forward secrecy.

Características principales:

  • Permite navegar a través de una ruta privada creada aleatoriamente entre distintos repetidores (onion routers) de la red Tor.
  • Se negocian nuevos caminos frecuentemente y, tras su uso, las claves se borran (forward secrecy).
  • Se aplican guardianes de entrada (el onion proxy) para reducir posibles ataques de correlación.
  • Incluye servidores ocultos que solo son accesibles desde dentro de la red Tor.

Funcionamiento detallado:

  1. Elección de ruta: los paquetes se envían a través de varios onion routers elegidos de forma aleatoria por un servidor central. Todos los nodos Tor se eligen al azar; ningún nodo se usa dos veces en la misma ruta.

  2. Establecimiento del túnel: el cliente se conecta a un nodo aleatorio a través de una conexión cifrada. Una vez conocido el camino, cada salto de la red es cifrado, excepto la conexión del nodo de salida al destino final (no cifrada).

  3. Cifrado asimétrico por capas: Alice cifra el mensaje primero con la clave pública del último router onion, luego con la del penúltimo, y así sucesivamente. Cada nodo solo puede descifrar su capa.

  4. Rotación periódica: cada 10 minutos se cambian los nodos de la conexión, escogiendo nuevos nodos, para evitar el análisis de tráfico pasivo.

WarningImportante: Tor no garantiza privacidad total.
  • Tor es lento por su arquitectura: múltiples saltos y uso de criptografía de clave pública.
  • Garantiza anonimato, pero no garantiza la privacidad de los datos (el nodo de salida puede ver el contenido si el tráfico no está cifrado end-to-end).
  • El anonimato en Tor no es incondicional: ataques de correlación entre nodo de entrada y salida pueden desanonimizar al usuario.

Formas de acceder a la red Tor:

  • Usar el Tor Browser (navegador compatible, también disponible para móviles).
  • Usar una extensión del navegador habitual.

3.4 Crowds y Hordes

Crowds

Los Crowds agrupan a los emisores creando una “multitud” en la que todos enrutan de manera aleatoria los paquetes recibidos de sus compañeros. Cada nodo solo conoce el destino y el nodo del que recibe el paquete.

  • Los nodos comparten claves con sus vecinos para cifrar los mensajes.
  • El camino seguido por el mensaje se almacena temporalmente en cada nodo para enrutar las respuestas.
Hordes

Hordes es un esquema muy similar a Crowds con una diferencia principal: la respuesta se envía mediante broadcast desde el router a todos los miembros del grupo donde se encuentra el originador del mensaje.

Aspecto Crowds Hordes
Enrutado de respuesta Punto a punto (inverso del camino) Broadcast al grupo
Rendimiento (tiempo) Menor Mayor (broadcast es más rápido)
Robustez Mayor Menor (el broadcast da indicios sobre la localización del usuario y sobrecarga el sistema)

3.5 Comparativa de Protocolos de Privacidad

Protocolo Arquitectura Latencia Nivel de anonimato
Proxy Centralizada Baja Bajo (el proxy conoce origen y destino)
Mezcladores Centralizada Alta Medio (depende del volumen de mensajes)
Enrutado de cebolla Centralizada Muy alta Alto
Tor Centralizada Media-baja Alto (con limitaciones en nodo de salida)
Crowds / Hordes Distribuida Media-baja Medio-alto

Referencias Bibliográficas

Bibliografía básica

  • Cryptography and Network Security: Principles and Practice — William Stallings. Prentice Hall, 2010 (5ª edición).
  • Electronic Payment Systems for E-commerce — Donal O’Mahony. Artech House, 2001 (2ª edición).
  • Blind Signatures for Untraceable Payments — David Chaum.
  • Group Signatures — David Chaum, Eugène van Heyst.

Referencias

  • “The International PGP Home Page” — http://www.pgpi.org
  • RFC 3156: MIME Security with OpenPGP
  • RFC 5652: Cryptographic Message Syntax (CMS)
  • RFC 5750: Secure/Multipurpose Internet Mail — Version 3.2 — Certificate Handling
  • RFC 5751: Secure/Multipurpose Internet Mail Extensions — Version 3.2 — Message Specification
  • SET Secure Electronic Transaction Specification (V1.0), Books 1, 2 and 3
  • MITRE ATT&CK Framework — https://attack.mitre.org