Tabla de Contenidos

Seguridad a nivel de transporte [L4]

TLS (Transport Layer Security)

Es una evolución de SSL (Secure Socket Layer) para proveer comunicaciones seguras a través de infraestuctura insegura. Provee un canal seguro a un servicio arbitrario de internet. Garantiza autenticación, confidencialidad e integridad, tiene los siguientes objetivos:

La arquitectura de TLS en internet es la siguiente: master_cs:secom:tls_internet.png

Competidores de TLS

Protocolo TSL (1.2 y 1.3)

Transporta y, opcionalmente, cifra cada mensaje TLS entre 2 aplicaciones. Un registro TLS tiene la siguiente estructura: master_cs:secom:diagtls2.png

Protocolo de Handshake

Responsable de la negociación de los parámetros de conexión y realizar la autenticación. Intercambia entre 6 y 10 mensajes, dependiendo de las características. Suelen haber 3 flujos comunes:

especificación_del_mensaje
struct {
  HandshakeType msg_type; //1 Byte
  uint24 length;
  HandshakeMessage message; //Depende del tipo de mensaje
} Handshake;

El funcionamiento de un handshake con autenticación de servidor sería el siguiente:

  1. Intercambio de capacidades y negociación de parámetros
  2. Autenticación, se validan los certificados presentados
  3. Se establece una clave secreta maestra para proteger la sesión
  4. Se verifica la integridad de los mensajes de handshake

Handshake completo con atenticación de servidor

Siguen los siguientes pasos:

master_cs:secom:diagflujofullhadshakeserver.png

  1. [Cliente] solicita sesión TLS y se envían las capabilities
    1. Client Hello: Compueto por los siguientes campos
      1. Random: Previene ataques de replay y asegura la integridad
      2. Session ID: Vacío para la primera conexión
      3. Cipher Suites: Ordenadas por preferencia.
  2. [Server] selecciona los parámetros de conexión
    1. Server Hello: La versión puede ser inferior a la del cliente. Contiene solo una opción por campo.
  3. [Server] envía la cadena de certificados si es necesaria autenticación
    1. Certificate Message: Sirve un certificado X.509
      1. Primero viene el certificado principal y luego los intermedios. No se debe enviar el certificado raid
      2. El certificadod epende de la cipher suite
      3. Un server puede ser configurado con múltiples certificados
  4. [Server] envía información adicional para generar la clave maestra
    1. Key Exchange: Los contenidos dependen de la cipher suite.
      1. El ClientKeyExchange es obligatorio y el SeverKeyExchange es opcional.
  5. [Server] Indica la finalización de la negociación
  6. [Cliente] Envía información adicional para generar la clave maestra
  7. [Cliente] Cambia el cifrado e informa al servidor
  8. [Cliente] Envía un MAC (Message Authentication Code) para todos los mensajes intercambiados
  9. [Server] Cambia el cifrado e informa al cliente
  10. [Server] Envía un MAC para todos los mensajes intercambiados

Handshake completo con autenticación mutua

master_cs:secom:diagflujofullhadshakemutuo.png

En este caso tenemos 2 tipos de comunicación extra:

  • Certificate Request: Se necesita que el server se auntentique. Puede usar algoritmos firmados, algoritmos de clave pública o autoridades de certificación
  • Certifiate Verify: Una firma de un mensaje de handshake previo para verificar la posesión de la clave privada del certificado.

Caso típico de Handshake

master_cs:secom:handshakecasohaitual.png

  • El Client Hello incluye parte de la clave de cliente. Solo DHE$^a$ (Diffie-Hellman Ehemeral) y PSK$^d$ (Pre-Shared Key) son soportados para la derivación de la clave

Continuación de Sesión

master_cs:secom:retomadesesion.png

Esto reduce el tiempo necesitado para el establecimiento de conexión. El procedimiento para el ID de sesión sigue estos pasos:

  1. El servidor almacena en cache prámetros de conexión de viejas conexiones
  2. El cliente manda un ID de sesión con el Client Hello
  3. El server confirma enviando el ID de sesión de vuelta en el Server Hello
  4. Se derivan un nuevo set de claves y se activa el cifrado.

Intercambio de claves

Se usa para derivar la clave premaestra:

Autenticación

Normalmente se usa altún tipo de clave pública criptográfica. Normalmente se usa RSA, pero también el Algoritmo de Firma Digital de Curva Elíptica (ECDSA):

  1. El cliente obtiene y valida el certificado del servidor.
  2. Dependiendo de si es RSA o ECDSA:
    1. RSA: El cliente cifra la clave premaestra con la clave pública del servidor. El server se autentica si se recibe el mensaje “Finished” correcto.
    2. ECDSA: El Server comunica los parámetros firmados con su propia clave provada. Los parámentros se concatenan con valores aleatorios para evitar ataques replay.

Cifrado

Cifrado Stream

master_cs:secom:streamcipher.png

Cifrado Block

master_cs:secom:cifradobloque1.png master_cs:secom:cofradobloque2.png master_cs:secom:cirbadobloque3.png

Cifrado Autenticado con Datos Asociados (AEAD)

master_cs:secom:aead.png

Cierre de la conexión

Operaciones Criptográficas

Una funcion Pseudo-Aleatoria (PRF) genera cantidades arbitrarias de datos pseudoaleatorios. en TLSv1.2 se basa en HMAC (Hash-Based MAC) y SHA256 (Secure Hash Algorithm). TLSv1.3 usa HKDF (Hashed Message Authentication Code)

PRF(Secret, label, seed) = P_hash(secret, label⊕seed)

Siendo ⊕ la concatenación de la operación.

$$ P_{\text{hash}}(secret, seed) = \underset{i=1}{\bigoplus} \mathrm{HMAC}_{\text{hash}} \left(secret, A(i) \oplus seed\right) $$

P_hash es una función de expansión de datos donde:

Internet Public Key Infraestructure (PKI)

La meta de la PKI es permitir a personas que nunca se han conocido comunicarse de forma segura. Los objetivos que tiene PKI son los siguentes:

Se basa en terceras partes, en este caso, Autoridades Certificadoras (CA), estas emiten certificados con claves públicas. X.509 Es un estándar internacional para PKI adaptado para ser usando en internet.

Normalmente los certificados tienen los siguientes campos:

Se puede extender el certificado con las siguientes extensiones:

Los certificados tienen el siguiente ciclo de vida: master_cs:secom:ciclodevidacertificado.png

Infraestructura PKI

master_cs:secom:cadena_de_certificados.png

Partes de Confianza

Se debe confiar en una serie de certificados CA raiz por sistemas operativos o desarrollador, por ejemplo:

Problemas con la infraestructura PKI actual

Mejoras de infraestructura