3. Seguridad de la Información: Esquemas, Protocolos y Certificados.

Primera Parte: Gestión de las “claves” y Protocolos de Soporte.

1. El problema de la distribución de claves simétricas.

En criptografía simétrica, dos entidades (por ejemplo, Alice y Bob) necesitan compartir una misma clave secreta (\(K_{AB}\)) para comunicarse de forma segura. En redes pequeñas esto es manejable, pero hay escenarios donde la utilización de la criptografía de clave pública (o asimétrica) para el intercambio de una clave de sesión \(K_{AB}\) puede ser NO conveniente: por ejemplo, en redes LAN grandes sin conexión a la red WAN. En este caso, Alice y Bob necesitan igualmente alguna solución que les permita, aun estando geográficamente (moderadamente) lejanos, acordar esa clave de sesión \(K_{AB}\).

La solución estándar es introducir una tercera parte confiable, conocida como Centro de Distribución de Claves (KDC - Key Distribution Center). En el modus operandi general de este tipo de protocolos, cada usuario del sistema comparte, de inicio, una clave secreta con el KDC mediante algún proceso de registro o inscripción previo.

Definición.

KDC (Key Distribution Center): Es un servidor central de confianza. Cada usuario del sistema comparte una clave maestra secreta a largo plazo con el KDC (mediante un registro previo). El KDC utiliza estas claves maestras para generar y distribuir de forma segura claves de sesión temporales entre los usuarios. Su uso se basa en el empleo de claves jerárquicas: se requieren al menos dos niveles de claves (las claves maestras \(K_{AT}\), \(K_{BT}\) con el KDC, y la clave de sesión \(K_{AB}\) entre los usuarios).

Ventajas del KDC: Permite que usuarios que no se conocen previamente puedan establecer una clave de sesión segura de forma automática, sin necesidad de haber contactado antes.

Inconvenientes del KDC:

Punto único de fallo: Si el KDC se cae, nadie puede establecer nuevas comunicaciones seguras.
Cuello de botella: Todo el tráfico de establecimiento de claves pasa por él, ya que todos los usuarios necesitan comunicar con el KDC de forma frecuente para obtener claves. Esto puede saturar la red.
Punto crítico de seguridad: El KDC posee suficiente información para suplantar a cualquier usuario. Si un atacante lo compromete, toda la red queda vulnerable.

2. Mecanismos contra ataques de repetición.

El mayor riesgo en la distribución de claves son los ataques de repetición (Replay Attacks), donde un atacante (habitualmente denominado Mallory) intercepta un mensaje cifrado legítimo y lo reenvía más tarde para causar estragos (ej. Denegación de Servicio o suplantación de identidad). El atacante no necesita conocer el contenido del mensaje para causar daño: le basta con reenviarlo.

Para evitar que se procesen mensajes antiguos, los protocolos utilizan mecanismos que garantizan la “frescura” (freshness) del mensaje:

Marcas de tiempo (Timestamps): Se incluye la hora exacta en el mensaje. Si el receptor recibe un mensaje con una marca de tiempo muy antigua, lo descarta. Inconveniente: Requiere que todos los relojes de la red estén perfectamente sincronizados. Por fallos del sistema o por sabotaje, los relojes pueden desincronizarse, lo que puede derivar en un ataque de denegación de servicio.
Nonces (Núnicos): Un número aleatorio de un solo uso. Cada parte de la comunicación debe recordar todos los nonces enviados o recibidos, y rechazar cualquier mensaje que contenga un nonce previamente usado. Inconveniente: Si una de las partes pierde la lista de nonces, es susceptible a ataques de repetición.
Combinación de ambas estrategias: Se pueden combinar timestamps y nonces para limitar el tiempo durante el cual hay que recordar los nonces, aunque el protocolo resultante se vuelve más complejo.

Modelo mental.

Timestamp responde a: ¿Es este mensaje reciente? (Basado en el reloj del sistema).
Nonce responde a: ¿He visto exactamente este mensaje antes? (Basado en memoria de mensajes procesados).

3. Modelos y Protocolos de KDC.

La mayoría de las técnicas de distribución de claves se adaptan a situaciones, escenarios y aplicaciones específicas. Hay muchos modelos de distribución de claves: simples y genéricos. Dentro de los genéricos encontramos los modelos PULL, PUSH, o sus combinaciones.

3.1. Modelo Simple (“La Rana de la Boca Grande”).

Alice genera la clave de sesión (\(K_{AB}\)) y se la envía al KDC (cifrada con su clave maestra \(K_{AT}\)). El KDC la descifra y se la reenvía a Bob (cifrada con la clave maestra de Bob \(K_{BT}\)).

Como se puede observar, existe validación de identidad: las claves con el KDC son secretas, por lo que nadie más habría sido capaz de cifrar la clave secreta \(K_{AB}\); además, existe autenticación de cada parte involucrada.

Problema: Es vulnerable a ataques de repetición. Si Mallory intercepta el canal y captura todos los mensajes del KDC a Bob, puede reenviarlos continuamente causando un ataque de Denegación de Servicio (DoS) sin necesidad de derivar \(K_{AB}\) ni \(K_{BT}\). La solución pasa por incorporar nonces o timestamps, tal y como se describió en la sección anterior.

3.2. Modelo PULL.

La entidad A desea tener comunicación segura con B, por lo que contacta con el KDC primero para solicitar la clave. El KDC le responde a Alice con la clave de sesión y un “ticket” cifrado que Alice debe entregar a Bob. Generalmente incorpora un mecanismo de desafío-respuesta (challenge-response) entre Alice y Bob para confirmar que ambos poseen la clave correcta.

3.3. Modelo PUSH.

La entidad A contacta primero con la entidad B a fin de que ésta última sea la encargada de solicitar al KDC la clave correspondiente. Es decir, es Bob quien “empuja” (push) la solicitud al KDC en nombre de Alice.

4. Protocolo Needham-Schroeder.

Es el protocolo PULL más representativo. Está basado en nonces y en un proceso final de desafío-respuesta (challenge-response) entre Alice y Bob para confirmar que ambos tienen la clave. Se denomina formalmente:

\[A \rightarrow S: A, B, N_A\] \[S \rightarrow A: E_{K_{AT}}\{N_A, K_{AB}, B, E_{K_{BT}}\{K_{AB}, A\}\}\] \[A \rightarrow B: E_{K_{BT}}\{K_{AB}, A\}\] \[B \rightarrow A: E_{K_{AB}}\{N_B\}\] \[A \rightarrow B: E_{K_{AB}}\{f(N_B)\}\]

Donde \(S\) es el KDC (Trent), \(N_A\) y \(N_B\) son nonces, y \(f(n) = n - 1\) es una función muy obvia pero suficiente para el desafío-respuesta.

Descripción de los pasos:

Alice pide al KDC (\(S\)) hablar con Bob enviando su identidad, la de Bob y un nonce \(N_A\).
El KDC envía a Alice la clave \(K_{AB}\) y un ticket cifrado para Bob, todo ello cifrado con \(K_{AT}\). El nonce \(N_A\) garantiza la frescura de la respuesta del KDC.
Alice envía el ticket a Bob (no puede descifrarlo, solo reenviarlo).
Bob descifra el ticket, obtiene \(K_{AB}\), y envía un nonce \(N_B\) cifrado con \(K_{AB}\) a Alice (Desafío).
Alice responde enviando \(f(N_B) = N_B - 1\) cifrado con \(K_{AB}\) (Respuesta), demostrando que posee la clave.

Vulnerabilidades de Needham-Schroeder.

Este protocolo presenta tres ataques que fueron descubiertos años después de su publicación:

Ataque 1: Mallory puede suplantar la identidad de Alice si consigue derivar la clave \(K_{AT}\). A partir de ese punto, todos los mensajes quedan comprometidos.
Ataque 2: Mallory puede suplantar la identidad de Bob si consigue derivar la clave \(K_{BT}\).
Ataque 3 (el más sutil): Mallory puede producir un ataque de DoS mediante repetición, especialmente en las últimas fases del protocolo. El problema es que la frescura de los mensajes solo se garantiza en los mensajes 1 y 2, pero no en el resto de la transacción. El ticket que Alice envía a Bob en el paso 3 no contiene ningún mecanismo de frescura generado por Bob, por lo que Mallory puede almacenar ese ticket y reutilizarlo más tarde.

La solución consiste en extender el uso del nonce al resto de transacciones, incluyendo un nonce de Bob desde el principio.

4.1. Protocolo Amended Needham-Schroeder.

Soluciona el fallo del protocolo anterior en relación a los ataques de repetición. En esta versión, Bob participa desde el principio aportando un nonce propio antes de que Alice contacte con el KDC, garantizando así la frescura en todos los pasos del protocolo.

5. Protocolo Otway-Rees.

Diseñado también para solucionar el fallo de frescura de Needham-Schroeder, aunque con un diseño diferente. El protocolo formalizado es:

\[A \rightarrow B: I, A, B, E_{K_{AT}}\{N_A, I, A, B\}\] \[B \rightarrow T: I, A, B, E_{K_{AT}}\{N_A, I, A, B\}, E_{K_{BT}}\{N_B, I, A, B\}\] \[T \rightarrow B: I, E_{K_{AT}}\{K_{AB}, N_A\}, E_{K_{BT}}\{K_{AB}, N_B\}\] \[B \rightarrow A: I, E_{K_{AT}}\{K_{AB}, N_A\}\]

Donde \(I\) es un identificador de sesión y \(N_A\), \(N_B\) son nonces de Alice y Bob respectivamente. La presencia de los nonces de ambas partes en los mensajes al KDC intenta solucionar el problema del freshness.

Vulnerabilidades de Otway-Rees.

Sin embargo, el protocolo presenta dos agujeros de seguridad importantes:

Primer agujero: Mallory puede interceptar y reenviar los mismos mensajes cifrados (\(E_{AT}(R_A, I, Alice, Bob)\) y \(E_{BT}(R_B, I, Alice, Bob)\)) al KDC, haciendo que las partes acepten una clave predecible o inválida.
Segundo agujero: Mallory puede reenviar exactamente los mismos mensajes sin modificarlos, de forma que Alice y Bob piensan que el canal es seguro cuando en realidad la clave de sesión \(K_{AB}\) puede ser conocida o controlada por el atacante (por ejemplo, \(K_{AB} = (I \| Alice \| Bob)\)).

6. Protocolo Kerberos.

Protocolo ampliamente utilizado en redes corporativas (y el mecanismo de autenticación por defecto en entornos Windows Active Directory). Se basa en timestamps y tiempos de vida de la sesión (\(L\)). Su flujo básico es:

\[A \rightarrow T: Alice, Bob\] \[T \rightarrow A: E_{K_{BT}}\{Time, L, K_{AB}, Alice\}, E_{K_{AT}}\{Time, L, K_{AB}, Bob\}\] \[A \rightarrow B: E_{K_{AB}}\{Alice, Time\}, E_{K_{BT}}\{Time, L, K_{AB}, Alice\}\] \[B \rightarrow A: E_{K_{AB}}\{Time + 1\}\]

Donde \(Time\) es el timestamp de frescura y \(L\) es el tiempo de vida del token (caducidad).

Características clave de Kerberos:

Proporciona un mecanismo de Single Sign-On (SSO): Alice se autentica una sola vez ante el servidor Kerberos y obtiene tickets que le permiten acceder a múltiples servicios (por ejemplo, el servidor de Contabilidad) sin necesidad de tener una cuenta en cada uno de ellos ni volver a autenticarse.
Su principal debilidad: por fallos del sistema o por sabotaje, los relojes pueden desincronizarse, lo que puede derivar en un ataque de denegación de servicio, ya que los tickets con timestamps desfasados son rechazados.

Ejemplo de uso de Kerberos.

Alice desea acceder al Servidor del Departamento de Contabilidad sin tener una cuenta en ese servidor. Alice se autentica ante el KDC Kerberos. El KDC le entrega un ticket de servicio para el servidor de Contabilidad, firmado con la clave que comparte con dicho servidor. Alice presenta el ticket al servidor, que lo verifica sin necesidad de contactar de nuevo con el KDC.

7. Protocolos Avanzados: Combinaciones PULL-PUSH.

Existen protocolos que combinan múltiples tipos de estrategias (tanto a nivel de modelos como de mecanismos de seguridad):

PUSH con PULL → PUSH extendido.
PULL con PUSH → PULL extendido.

7.1. Protocolo Yahalom.

Objetivo: Permitir a Trent (el KDC) generar la clave de sesión \(K_{AB}\) y enviarla directamente a Alice, e indirectamente a Bob (a través de Alice).

\[A \rightarrow B: A, N_A\] \[B \rightarrow T: B, E_{K_{BT}}\{A, N_A, N_B\}\] \[T \rightarrow A: E_{K_{AT}}\{B, K_{AB}, N_A, N_B\}, E_{K_{BT}}\{A, K_{AB}\}\] \[A \rightarrow B: E_{K_{BT}}\{A, K_{AB}\}, E_{K_{AB}}\{N_B\}\]

Alice inicia el protocolo, Bob aporta un nonce propio (\(N_B\)) que va cifrado hasta el KDC, lo que garantiza la frescura en toda la cadena.

7.2. Protocolo Neuman-Stubblebine.

Objetivo: Combinar timestamps y nonces para verificar la frescura de las transacciones, aprovechando las ventajas de ambos mecanismos y mitigando sus inconvenientes individuales.

\[A \rightarrow B: A, N_A\] \[B \rightarrow T: B, E_{K_{BT}}\{A, N_A, timestamp_B\}, N_B\] \[T \rightarrow A: E_{K_{AT}}\{B, K_{AB}, N_A, timestamp_B\}, \\ E_{K_{BT}}\{A, K_{AB}, timestamp_B\}, N_B\] \[A \rightarrow B: E_{K_{BT}}\{A, K_{AB}, timestamp_B\}, E_{K_{AB}}\{N_B\}\]

En fases posteriores, si Alice y Bob desean renovar la sesión sin pasar de nuevo por el KDC:

\[A \rightarrow B: N'_A, E_{K_{BT}}\{A, K_{AB}, timestamp_B\}\] \[B \rightarrow A: N'_B, E_{K_{AB}}\{N'_A\}\] \[A \rightarrow B: E_{K_{AB}}\{N'_B\}\]

7.3. Protocolo Kao-Chow.

\[A \rightarrow T: A, B, N_A\] \[T \rightarrow B: E_{K_{AT}}\{N_A, K_{AB}, A, B\}, E_{K_{BT}}\{N_A, K_{AB}, A, B\}\] \[ B \rightarrow A: E_{K_{AT}}\left\{N_A, K_{AB}, A, B\right\},\; E_{K_{AB}}\left\{N_A\right\},\; N_B \] \[A \rightarrow B: E_{K_{AB}}\left\{N_B\right\}\]

Resumen: ¿Qué protocolo elegir?

Hemos visto que existen diversos protocolos para solucionar el problema de la administración e intercambio de claves. El protocolo a elegir depende del escenario y de lo que se quiere proteger. Como regla general:

Si la red tiene relojes sincronizados y se busca SSO: Kerberos.
Si se necesita frescura sin depender de relojes: Amended Needham-Schroeder o Yahalom.
Si se quieren combinar ambas estrategias de frescura: Neuman-Stubblebine.

Recuerda además que usar un KDC no está exento de riesgos: el KDC posee suficiente información para suplantar a cualquier usuario, representa un único punto de fallo, y puede convertirse en un cuello de botella de rendimiento.

Segunda Parte: Infraestructuras de Clave Pública (PKI) y Certificados.

1. El problema de la Autenticidad de la Clave Pública.

En sistemas criptográficos asimétricos, las claves públicas son visibles para todos. El riesgo aquí no es que roben la clave pública, sino la suplantación: ¿Cómo sabe Bob que la clave pública que afirma ser de Alice realmente le pertenece a ella y no a un atacante que se hace pasar por ella? Y recíprocamente, ¿cómo sabe Alice que la clave pública de Bob es genuina?

Bob necesita algún documento digital con algún “sello de garantía”, es decir, algo equivalente a lo que en papel sería un documento oficial certificado por una autoridad.

Para resolver esto, se utilizan los Certificados Digitales.

Definición.

Certificado Digital (o de clave pública): Es un documento electrónico que vincula de manera criptográfica e inequívoca la información de identificación de un usuario con su clave pública. Esta garantía es proporcionada por la firma digital de una tercera parte confiable (TTP - Trusted Third Party), denominada Autoridad de Certificación (CA). La CA garantiza que una clave pública pertenece a cierto usuario inequívocamente identificado.

Nótese que la identidad del usuario por sí sola no es suficiente para este propósito, ya que un usuario puede tener más de un par <clave pública, clave privada>. El certificado vincula un par de claves concreto a una identidad.

Analogía.

Un certificado digital es como el Documento Nacional de Identidad (DNI) físico. Tu nombre es tu identidad, tu fotografía es tu clave pública, y el sello del Ministerio del Interior es la firma que garantiza que ambos te pertenecen.

2. Estructura de un Certificado (X.509).

La ITU-T ha definido una estructura estándar de certificado digital que ha sido adoptada internacionalmente: el certificado X.509. Contiene los siguientes campos fundamentales:

Campo	Descripción
Versión	Indica el número de versión de X.509 (1, 2 ó 3).
Número de Serie	Número de identificación único para este certificado digital, asignado por la CA.
Algoritmo de Firma	Algoritmo usado por la CA para firmar (ej. SHA-1 con RSA), para que el receptor sepa cómo validar la firma.
*Emisor (Issuer)*	Nombre X.500 de la CA emisora.
Período de Validez	Fecha y hora de inicio y de expiración (No válido antes de / No válido después de).
*Sujeto (Subject)*	Nombre en formato X.500 del usuario cuya clave pública se está certificando.
Algoritmo de Clave Pública	Identifica el algoritmo de la clave pública del sujeto (ej. RSA).
Clave Pública	El valor matemático de la clave pública del Sujeto (ej. RSA 1024 bits).
Identificador único de emisor	Cadena opcional para que el nombre de la CA no sea ambiguo (ej. dirección de email, dirección postal).
Identificador único de usuario	Cadena opcional para que el nombre del usuario no sea ambiguo (ej. dirección de email).
Extensiones (v3)	Campo opcional para almacenar información adicional, como el Uso de la clave (ver sección 2.1).

La Firma de la CA.

Al final del documento se añade la Firma de la CA (Autoridad de Certificación). Esta firma es el resultado de:

Aplicar una función Hash (un resumen matemático) a todos los campos anteriores del certificado.
Cifrar ese hash con la clave privada de la CA: \(SELLO\_DIGITAL = E_{K_{priv\_CA}}(H(documento))\).

Quien verifique el certificado usará la clave pública de la CA para descifrar la firma y comparar el hash resultante con el hash que calcule él mismo sobre los campos del certificado. Si coinciden, el certificado es auténtico e íntegro.

2.1. Uso de Claves en los Certificados Digitales.

Cuando una CA crea un certificado, debe indicar expresamente para qué se van a utilizar las claves asociadas a dicho certificado. Esto es fundamental: no todas las claves deben poder usarse para todo. El campo X.509v3 Key Usage (Uso de Clave) permite especificar usos como:

Digital Signature: Necesario para firmar (ej. firmar documentos PDF).
Non Repudiation: Para garantizar el no repudio.
Key Encipherment: Necesario para cifrar.
Key Agreement: Para protocolos de acuerdo de clave (ej. Diffie-Hellman).
Certificate Sign: Permite a una entidad firmar otros certificados. Este es el uso que debe asignarse a una CA cuando se la está certificando.
CRL Sign: Permite firmar Listas de Revocación de Certificados.

El campo X.509v3 Extended Key Usage permite especificar usos más específicos, como firma de código (Code Signing), autenticación de servidor TLS, OCSP Signing, acceso con Smartcard (Microsoft Smartcard Login), etc.

Los certificados se exportan habitualmente en formato PKCS#12, que empaqueta el certificado junto con su clave privada en un único fichero protegido por contraseña.

Pregunta de reflexión.

¿Qué tipo de uso de clave se le debería asignar a una nueva CA por defecto? La respuesta es Certificate Sign y CRL Sign: la CA necesita poder firmar certificados de otros y firmar las listas de revocación, pero no necesariamente cifrar o firmar documentos de usuario final.

3. Infraestructura de Clave Pública (PKI).

Es imposible que una sola Autoridad de Certificación (CA) gestione todos los certificados del mundo. Por ello, las CAs se agrupan en una jerarquía llamada PKI (Public Key Infrastructure).

La PKI gestiona todo el ciclo de vida de los certificados: los emite, distribuye, salvaguarda, renueva y revoca.

Cadenas de Confianza (Certification Paths):

Entre las CAs se utiliza de forma recursiva el esquema de certificación, creándose las cadenas de confianza (o caminos de certificación). La jerarquía establece dos tipos de certificados:

Certificado raíz (Root CA): Una CA Raíz se autofirma su propio certificado (es el ancla de confianza). Tu ordenador o navegador incluye de fábrica una lista de CAs Raíz en las que confía.
Certificados intermedios: Una CA Raíz firma el certificado de una CA Intermedia, la cual a su vez firma el certificado del usuario final. Al validar, tu ordenador escala por esta cadena hasta llegar a una CA Raíz en la que confía.

Ejemplos de CAs públicas.

Existen CAs gestionadas por la comunidad y gratuitas, como CAcert.org, aunque no están incluidas por defecto en todos los navegadores. La CA más utilizada en la actualidad para certificados de servidores web es Let’s Encrypt (https://letsencrypt.org/), que emite certificados gratuitos y automatiza su renovación, siendo un proyecto de la Linux Foundation.

4. Revocación de Certificados.

Si la clave privada de un usuario es comprometida, o si el usuario deja de trabajar en una organización, su certificado debe ser invalidado inmediatamente, antes de que llegue su fecha natural de expiración. La CA se encarga de realizar la revocación bajo petición del usuario, y tiene la obligación de publicar esa información para que el resto de usuarios puedan comprobarlo antes de usar el certificado.

Escenario típico: Para que Bob verifique la firma de Alice sobre un documento digital, no solo ha de verificar el certificado de Alice y su validez temporal; además, ha de comprobar que ese certificado no ha sido revocado.

Existen dos mecanismos principales:

CRL (Certificate Revocation List): Una lista publicada periódicamente (con timestamping) por la CA, firmada por la propia CA, que contiene los números de serie de los certificados revocados. Quien verifica debe descargar la lista y comprobar que el número de serie del certificado de Alice no aparece en ella. El estándar X.509 define la estructura de una CRL versión 2.
OCSP (Online Certificate Status Protocol): Un protocolo (RFC 6960) para consultar el estado de un certificado específico en tiempo real a un servidor (OCSP Responder). Define un formato estándar para mensajes de peticiones y respuestas. Es más ágil que la CRL ya que evita descargar listas completas, y permite una respuesta inmediata sobre si un certificado está válido, revocado o se desconoce su estado.

Tercera Parte: Tarjetas Inteligentes y DNI Electrónico.

1. Tarjetas Inteligentes (Smartcards).

Una tarjeta inteligente o smartcard es una tarjeta que incluye un chip cuya función puede ser variada. Su uso se extiende hoy a muchos sectores (banca, salud, transporte, identidad, etc.).

Clasificación según el método de comunicación o interfaz:

Contacto: Requieren inserción física en un lector.
Sin contacto / NFC (Near-Field Communication): Comunicación por radiofrecuencia a corta distancia.

Clasificación según las capacidades del chip:

Tarjetas de memoria: Solo almacenan datos y no albergan aplicaciones. Uso: identificación y control de acceso sin altos requisitos de seguridad (ej. tarjetas de fidelización).
Tarjetas microprocesadas: Albergan datos y aplicaciones. Uso: pago con monederos electrónicos.
Tarjetas criptográficas: Tarjetas microprocesadas avanzadas que incluyen módulos hardware para la ejecución de cifrados y firmas digitales en su interior de forma segura. Son el tipo más relevante para ciberseguridad.

2. El DNI Electrónico (DNI-e).

El DNI-e español es un claro ejemplo de tarjeta criptográfica. A través de las capacidades criptográficas que aporta, permite identificar al ciudadano en medios telemáticos y realizar firmas electrónicas con plena validez legal.

Hardware del DNI-e:

El DNI-e está dotado con el chip ST19WL34 (STMicroelectronics), que incorpora, entre otros componentes relevantes:

CPU de 8 bits de la familia ST19X.
Acelerador hardware para algoritmos criptográficos: DES, Triple DES (con modos CBC), RSA 1024 bits (con y sin CRT), AES-128. Esto es crucial porque las operaciones criptográficas pesadas se realizan físicamente dentro de la tarjeta, sin exponer las claves al exterior.
Soporte hardware para aritmética de gran precisión (hasta 2176 bits de operando), lo que permite implementar RSA con mayor eficiencia.
Generador de números aleatorios compatible con FIPS 140-2, con dos fuentes de entropía.
Bloque de cálculo de CRC ISO 3309.
Retención de datos de al menos 10 años y resistencia de 500.000 ciclos de borrado y escritura.

El sistema operativo que gestiona el chip se denomina DNIe v3.0, desarrollado por la FNMT (Fábrica Nacional de Moneda y Timbre / CERES) a partir de las especificaciones funcionales de la Dirección General de Policía. Este SO ha sido sometido a los perfiles de protección de la certificación Common Criteria.

Interfaces de acceso:

El DNI-e 3.0 ofrece dos opciones para acceder al chip: mediante contacto físico (lector de tarjetas) o mediante NFC. En el acceso por NFC se utiliza el CAN (Card Access Number), un número que aparece en la parte inferior del DNI 3.0 y corresponde con el número de la tarjeta, como medida de seguridad adicional para establecer el canal cifrado con el chip.

Zonas de Memoria del DNI-e:

La memoria del chip está dividida en tres áreas protegidas por cortafuegos (firewalls) lógicos:

Zona Pública: Accesible sin restricciones. Contiene el certificado de la CA emisora y las claves públicas genéricas.
Zona Privada: Accesible únicamente tras introducir el PIN del ciudadano. Contiene los certificados de uso del titular:
- Certificado de Autenticación: Asegura que la comunicación electrónica se realiza con el titular del DNI, pero no demuestra voluntad de firma. Está restringido a operaciones de confirmación de identidad y acceso seguro a sistemas remotos.
- Certificado de Firma Digital: Para la firma de documentos, garantizando la integridad del documento y el no repudio de origen.
Zona de Seguridad: Solo accesible en los puntos de actualización del DNI-e (en las comisarías). Contiene datos biométricos (huella dactilar), fotografía y firma manuscrita.

El DNI-e cuenta además con un certificado de componente, emitido para autenticar al propio chip y cifrar la comunicación con él, de forma similar a como se utiliza un certificado TLS en un servidor web.

Generación y Custodia de Claves.

El par de claves (pública y privada) de los certificados del DNI-e se genera en el interior del chip gracias al generador de números aleatorios integrado, en presencia del ciudadano. Esto garantiza que solo existirá una copia de cada clave privada, y que ésta residirá siempre en el interior del chip.

La clave privada jamás sale al exterior: cuando se firma un documento, el documento (o su hash) entra a la tarjeta, la tarjeta aplica la clave privada internamente, y devuelve únicamente la firma resultante. Esto hace al DNI-e resistente a ataques de extracción de claves desde el exterior.

Revocación y Validación en el DNI-e:

En el ámbito del DNI-e se usa el protocolo OCSP para las revocaciones, aislando la carga de trabajo de forma eficiente. En la PKI adoptada para el DNI-e se ha optado por asignar las funciones de Autoridad de Validación a entidades diferentes de la Autoridad de Certificación:

La Autoridad de Certificación es la Policía Nacional / FNMT-CERES.
Las Autoridades de Validación son entidades independientes (como el Ministerio de Administraciones Públicas o el Ministerio de Industria), que responden a las consultas OCSP sin sobrecargar a la CA.

Marco legal del DNI-e:

El DNI-e está regulado por un marco legal básico que le otorga plena validez jurídica a los documentos firmados con él, equiparando la firma electrónica cualificada a la firma manuscrita ante la ley.

Cuarta Parte: Mecanismos de Autenticación y Control de Acceso.

1. Mecanismos de Autenticación de Usuarios

La autenticación es el proceso de verificar que una entidad es quien dice ser. Es el primer eslabón de la cadena de seguridad, anterior a la autorización y al control de acceso.

Importante: autenticación ≠ autorización.

Autenticación: ¿Quién eres? → Verifica identidad.
Autorización: ¿Qué puedes hacer? → Verifica permisos.

Una entidad puede autenticarse correctamente y aun así no tener permiso para acceder a un recurso concreto. Son servicios independientes aunque relacionados.

Usuario presenta credencial
         │
         ▼
┌─────────────────────┐
│   AUTENTICACIÓN     │  ← ¿Eres quien dices ser?
└──────────┬──────────┘
           │ (identidad verificada)
           ▼
┌─────────────────────┐
│   AUTORIZACIÓN      │  ← ¿Tienes permiso para esto?
└──────────┬──────────┘
           │
           ▼
     Acceso al recurso

1.1 Clasificación de Factores de Autenticación

Existen tres categorías fundamentales, basadas en lo que el usuario aporta como evidencia:

Factor	Categoría	Ejemplos
Conocimiento	Algo que solo yo CONOZCO	Contraseñas, PINs
Posesión	Algo que solo yo TENGO	Tokens físicos, tarjetas inteligentes, certificados
Inherencia	Algo que yo SOY	Huella dactilar, iris, geometría facial

1.2 Factor CONOZCO — Autenticación por Contraseña

En los sistemas basados en contraseñas, el usuario conoce cierta información que se supone que nadie más conoce (acceso a S.O., servicios web, etc.).

Características principales:

La contraseña puede transferirse de un usuario a otro (riesgo).
Más de un usuario puede usarla simultáneamente (no garantiza exclusividad).

Inconvenientes del uso de contraseñas.

Requieren ser robustas (longitud, complejidad) y no reutilizarse entre servicios.
La proliferación de servicios lleva a demasiadas contraseñas → tendencia a reutilizarlas o simplificarlas.
Las políticas de seguridad no siempre se cumplen:
- Tamaño mínimo y carácter alfanumérico.
- Renovación periódica (rekeying).

Salt: Almacenamiento Seguro de Contraseñas

Las contraseñas nunca deben almacenarse en claro. El mecanismo estándar es almacenar un hash de la contraseña:

Usuario introduce contraseña
        │
        ▼
   H(contraseña)  ──→  comparar con hash almacenado

Sin embargo, el hash simple presenta una vulnerabilidad crítica: los ataques de Rainbow Table.

Definición: Rainbow Table.

Una Rainbow Table es una tabla precalculada que relaciona valores hash con las contraseñas originales. Permite a un atacante, una vez obtenida la base de datos de hashes, derivar contraseñas de forma extremadamente rápida sin necesidad de calcular hashes en tiempo real.

La solución: el Salt (Sal)

¿Qué es el Salt?

Salt es un valor aleatorio que se añade a la contraseña antes de aplicar la función hash. El resultado es:

\[H(\text{Salt} \| \text{Contraseña})\]

El Salt se almacena junto al hash en la base de datos (no es secreto).

¿Por qué el Salt frustra las Rainbow Tables?

CASO 1 — El atacante tiene una tabla de hashes precalculados:
No puede comparar directamente \(H(\text{1234})\) con \(H(\text{Salt} \| \text{1234})\). La tabla queda obsoleta.
CASO 2 — El atacante tiene una lista de contraseñas robadas:
Puede calcular \(H(\text{Salt} \| \text{ContraseñaRobada})\) para cada usuario. Sin embargo, no puede saber si dos usuarios tienen la misma contraseña, ya que sus Salts distintos producen hashes distintos.

Importante: el Salt NO es secreto.

El Salt no necesita ser secreto. Su utilidad radica en ser único por usuario, no en ser confidencial. Almacenarlo junto al hash es correcto y esperado.

bcrypt — Función Hash Adaptativa

¿Qué es bcrypt?

bcrypt es una función hash diseñada específicamente para contraseñas. Combina Salt y contraseña, y está basada en el algoritmo de cifrado Blowfish.

¿Para qué sirve? Almacenar contraseñas de forma resistente a ataques de fuerza bruta.
¿Cuándo se usa? Siempre que se almacenen contraseñas en un sistema de autenticación.

Su resistencia se debe a que incorpora un factor de coste (número de iteraciones): a mayor número de iteraciones, más lento es el cómputo, dificultando los ataques.

Almacenamiento en BD:
  ┌─────────────────────────────────────────────┐
  │  Cristina  │  Salt  │  BCrypt(Salt ∥ 1234)  │
  └─────────────────────────────────────────────┘

Principios del Salt (Resumen)

Principio	Descripción	Ejemplo
No reutilizar el Salt	Un Salt único por cada contraseña	Generado con `os.urandom()`
Salt suficientemente largo	Al menos 57 bits de entropía	`/etc/shadow`: 10 chars `[a-z\\|A-Z\\|0-9]`
Usar funciones hash lentas	Aumentan el coste de ataques de fuerza bruta	`Argon2id`, `PBKDF2`, `bcrypt`

1.3 Factor TENGO — Tokens Físicos

Existe un secreto guardado en un dispositivo físico (token). El usuario posee ese objeto y lo usa para demostrar su identidad.

Tipos más comunes: tarjetas inteligentes (smartcards), llaves hardware (USBs criptográficos), certificados digitales.

Características principales:

Basados principalmente en criptografía asimétrica (“tengo una clave privada en el token”).
La transferencia del token es posible físicamente, pero depende del diseño del sistema.
Solo un usuario puede usarlo simultáneamente si el factor es físico.

Inconvenientes de los tokens físicos.

No siempre garantiza la identidad del poseedor (cualquiera con el token pasa la autenticación).
En caso de pérdida o daño, el usuario legítimo queda sin acceso.
Algunos tokens pueden falsificarse o clonarse.

Ejemplo: DNI Electrónico (DNI-e)

El DNI electrónico es un ejemplo paradigmático de autenticación basada en posesión combinada con criptografía asimétrica.

Capacidades del DNI-e:

Identificación telemática: acredita la identidad del titular ante servicios electrónicos.
Firma electrónica: garantiza la integridad del documento y el no repudio de origen.

Certificados incluidos:

Certificado	Función	Garantía
Autenticación	Confirma que la comunicación es con el titular	No implica voluntad de firma
Firma	Firma de documentos electrónicos	Integridad + no repudio

Seguridad de las claves: el par de claves se genera dentro del chip, garantizando que solo existe una copia de cada clave privada, que nunca abandona el interior del chip.

1.4 Factor SOY — Autenticación Biométrica

Los sistemas biométricos extraen características biológicas o de comportamiento del usuario:

Huella dactilar
Imagen del iris
Geometría facial
Tamaño y forma de la oreja

Características principales:

No transferible: los datos biométricos no pueden pasarse de un usuario a otro.
Exclusivo: solo el usuario puede usarlos en un momento determinado.

Inconvenientes de la autenticación biométrica.

El perfil biométrico debe almacenarse previamente en el sistema (requiere protección especial).
Son sistemas más costosos que contraseñas o tokens.
Si un dato biométrico se compromete, se pierde para siempre (ej.: huella destruida por quemadura → no se puede regenerar, a diferencia de una contraseña).

1.5 Comparativa de Factores de Autenticación

Característica	CONOZCO (Contraseña)	TENGO (Token)	SOY (Biométrica)
Transferible	✅ Sí	⚠️ Sí (físico)	❌ No
Uso simultáneo	✅ Sí	❌ No	❌ No
Revocable	✅ Sí	✅ Sí	❌ No
Coste	Bajo	Medio	Alto
Principal riesgo	Robo/adivinanza	Pérdida/clonación	Compromiso permanente

1.6 Autenticación de Doble Factor (2FA)

La autenticación de doble factor combina dos categorías distintas de los factores anteriores para aumentar la seguridad.

Ejemplos: - Contraseña (CONOZCO) + Token físico (TENGO) - Dato biométrico (SOY) + Token (TENGO)

Ejemplo legal: Directiva Europea PSD2.

La Segunda Directiva de Servicios de Pago (PSD2) obliga a usar autenticación de doble factor para pagos online: código de la tarjeta + aplicación móvil / SMS.

⚠️ El uso de SMS como segundo factor es considerado débil debido al riesgo de duplicado de SIM (SIM swapping).

1.7 Autenticación Basada en Códigos QR

Los códigos QR (Quick Response) permiten autenticar y autorizar el acceso usando dispositivos móviles.

Proceso:

El servidor genera un código QR con una contraseña OTP (One Time Password) codificada en él.
El usuario escanea el código para autenticarse.

Combinación recomendada: QR + OTP

El QR contiene la OTP (de un solo uso), lo que añade resistencia frente a ataques de repetición (replay attacks).

Inconvenientes de la autenticación por QR.

La información del usuario debe estar en el servidor remoto.
El servidor necesita software para generar los códigos QR.
El cliente necesita software para escanearlos.

1.8 Single Sign-On (SSO)

¿Qué es el SSO?

Single Sign-On (SSO) es un mecanismo que permite a un usuario autenticarse una sola vez para acceder a múltiples sistemas independientes pero relacionados, sin necesidad de volver a autenticarse.

¿Para qué sirve? Evitar la gestión y memorización de múltiples credenciales.
¿Cuándo se usa? Entornos corporativos con múltiples servicios internos, portales web federados.

Usuario se autentica
       │
       ▼
  [Servidor SSO]
       │
       ├──→ Sistema A  (sin nueva autenticación)
       ├──→ Sistema B  (sin nueva autenticación)
       └──→ Sistema C  (sin nueva autenticación)

Ventajas del SSO:

Dimensión	Beneficio
Usabilidad	Un solo password / token / certificado
Seguridad	Reduce el riesgo de ataques de intercepción por reducir el número de transmisiones de credenciales
Productividad	Reduce el tiempo invertido en autenticación

Desventaja crítica del SSO: punto único de fallo.

El servidor SSO es un único punto de ataque. Si el atacante compromete el SSO, obtiene acceso a todos los sistemas protegidos por él.

2. Mecanismos de Control de Acceso

2.1 Fundamentos del Control de Acceso

El control de acceso es uno de los servicios esenciales de la seguridad en ordenadores. El RFC-2828 define la seguridad en ordenadores como las medidas que aseguran especialmente el servicio de control de acceso.

Objetivos del control de acceso:

Prevenir accesos a recursos por parte de usuarios no autorizados.
Prevenir que usuarios legítimos accedan a recursos de forma no autorizada.
Permitir a usuarios legítimos acceder a recursos de forma autorizada.

Relación con otros servicios de seguridad (modelo AAA):

Autenticación  →  Autorización  →  Auditoría (Accounting)
   (¿Quién?)       (¿Qué puede?)    (¿Qué hizo?)

Autorización: concesión de un derecho o permiso para acceder a un recurso.
Auditoría: revisión de registros y actividades del sistema para garantizar el cumplimiento de la política, detectar problemas y recomendar mejoras.

2.2 Elementos Básicos del Control de Acceso

Elemento	Definición	Ejemplos
Objeto	Recurso al que se controla el acceso	Ficheros, registros, puertos, programas, bases de datos
Sujeto	Entidad que potencialmente accede a los objetos	Usuario, proceso, aplicación
Derecho de acceso	Forma en que el sujeto puede acceder al objeto	`read`, `write`, `execute`, `delete`

Refuerzo conceptual: el sujeto es un proceso.

El concepto de sujeto se asimila al concepto de proceso: cualquier usuario o aplicación accede a un objeto a través de un proceso que lo representa. No es el usuario directamente quien lee un fichero, sino el proceso que actúa en su nombre.

El mecanismo de control de acceso actúa como mediador entre el sujeto y el objeto, aplicándose sobre:

Aplicaciones, Sistemas operativos, Firewalls, Routers
Ficheros, Bases de datos
Dispositivos: servidores, sensores, dispositivos móviles

2.3 Categorías de Mecanismos de Control de Acceso

Las principales categorías de control de acceso no son mutuamente excluyentes: un sistema puede combinar varios de ellos para cubrir distintos tipos de recursos.

Modelo	Base del control	Quién decide
DAC	Identidad del solicitante + reglas	El propietario del recurso
MAC	Etiquetas de seguridad vs. autorizaciones	El sistema / administrador central
RBAC	Rol del usuario	El administrador de roles
ABAC	Atributos del sujeto	Evaluación de condiciones

2.4 DAC — Control de Acceso Discrecional

¿Qué es DAC?

Discretionary Access Control (DAC) basa el control de acceso en la identidad del solicitante y en las reglas de acceso (autorizaciones) que indican qué solicitantes están o no autorizados a realizar determinadas acciones.

El término “discrecional” implica que el propietario del recurso puede, a su discreción, conceder o revocar accesos a otros sujetos.

Matriz de Acceso

La herramienta fundamental del DAC es la matriz de acceso, donde:

Filas → Sujetos (usuarios, grupos, hosts, aplicaciones)
Columnas → Objetos (ficheros, campos de datos, registros)
Celda → Derechos del sujeto sobre el objeto

	File 1	File 2	File 3	File 4
User A	Own, Read, Write	—	Own, Read, Write	—
User B	Read	Own, Read, Write	Write	Read
User C	Read, Write	Read	—	Own, Read, Write

En la práctica, la matriz de acceso se descompone en dos estructuras más manejables:

Access Control List (ACL) — Descomposición por columnas

Para cada objeto, la ACL lista los sujetos y sus derechos de acceso.

Analogía: una ACL es como la lista de invitados en la puerta de un local. Cada puerta tiene su lista.

Ejemplo:

\[L_{bar.txt} = \{(pepe, \{r\}),\ (paco, -),\ (luis, \{r, d\})\}\] \[L_{foo.exe} = \{(pepe, -),\ (paco, \{x, d\}),\ (luis, \{x\})\}\]

Ventajas de las ACL:

Fácil ver todos los permisos sobre un objeto determinado.
Fácil revocar todos los permisos sobre un objeto: \(L_{ob} = \{\}\).
Fácil eliminar los permisos al eliminar el objeto: eliminar \(L_{ob}\).

Desventaja: comprobar todos los permisos de un sujeto concreto es costoso (hay que recorrer todas las ACL).

Uso típico: sistemas orientados a la gestión de recursos, como sistemas operativos (ej. permisos UNIX).

Ticket de Capacidades (Capability List) — Descomposición por filas

Para cada sujeto, el ticket (perfil de acceso) lista los objetos autorizados y las operaciones permitidas.

Ejemplo:

\[L_{pepe} = \{(bar.txt, \{r\}),\ (foo.exe, -)\}\] \[L_{paco} = \{(bar.txt, -),\ (foo.exe, \{x, d\})\}\] \[L_{luis} = \{(bar.txt, \{r, d\}),\ (foo.exe, \{x\})\}\]

Ventajas:

Fácil ver todos los permisos de un sujeto determinado.
Fácil revocar todos los permisos de un sujeto: \(L_{sj} = \{\}\).

Desventaja: comprobar todos los sujetos con acceso a un objeto concreto es costoso.

Uso típico: sistemas orientados al usuario, como bases de datos o sistemas distribuidos.

Tabla de Autorización: tercera alternativa.

La Tabla de Autorización almacena una fila por cada derecho de acceso de un sujeto sobre un recurso. Es más eficiente para consultas ad-hoc, aunque puede resultar más voluminosa.

Subject	Access Mode	Object
A	Own	File 1
A	Read	File 1
B	Read	File 1
B	Own	File 2
C	Write	File 4
…	…	…

2.5 MAC — Control de Acceso Obligatorio

¿Qué es MAC?

Mandatory Access Control (MAC) basa el control de acceso en la comparación de etiquetas de seguridad (que indican la criticidad de los recursos) con las autorizaciones de seguridad (que indican qué entidades pueden acceder a recursos de cierto nivel).

A diferencia de DAC, el propietario del recurso no puede modificar las políticas de acceso; lo hace el sistema de forma centralizada.

Etiquetas de clasificación (de mayor a menor sensibilidad):

Top Secret → Secret → Confidential → Restricted → Unmarked → Unclassified

Lógica de acceso MAC: un sujeto con autorización de nivel \(N\) puede acceder a recursos con etiqueta \(\leq N\).

Uso típico: entornos militares, gubernamentales y sistemas de alta seguridad donde la política de acceso no puede ser discrecional.

2.6 RBAC — Control de Acceso Basado en Roles

¿Qué es RBAC?

Role-Based Access Control (RBAC) no basa el control de acceso en la identidad del usuario, sino en los roles que asume dentro de la organización. Un rol es una función o tarea específica (ej. administrador, auditor, operador).

¿Para qué sirve? Simplificar la gestión de permisos en organizaciones con muchos usuarios y recursos.
¿Cuándo se usa? Cuando el conjunto de roles es relativamente estable aunque los usuarios cambien.

Analogía: RBAC desacopla usuarios y permisos mediante roles intermedios. En lugar de asignar permisos a cada persona, se asignan a su cargo, y el cargo a la persona.

Modelo de asignación:

Usuario
   │
   └──→ Rol
           │
           └──→ Permisos
                    │
                    └──→ Recursos (Objetos)

El modelo RBAC asigna:

Los derechos de acceso a los roles.
Los roles a los usuarios.

Fundamento: tanto el conjunto de roles como los permisos asociados a cada rol cambian con poca frecuencia, a diferencia de los usuarios.

Estandarización: RBAC ha sido estandarizado por el NIST (FIPS PUB 140-2, 2001). Está ampliamente adoptado en: Oracle DBMS, PostgreSQL, SAP R/3, Microsoft Active Directory, SELinux, Wikipedia, entre otros.

Entidades del Modelo RBAC

El modelo RBAC consta de 4 tipos de entidades:

Entidad	Descripción
Usuario	Persona o proceso que accede al sistema
Rol	Función o tarea dentro de la organización
Permiso	Autorización para realizar una operación sobre un objeto
Sesión	Instancia activa de un usuario con roles activados

Las relaciones muchos-a-muchos entre usuarios↔︎roles y roles↔︎permisos proporcionan flexibilidad y granularidad que no es factible con DAC.

Restricciones en RBAC

RBAC permite definir restricciones avanzadas:

Roles mutuamente exclusivos: un usuario solo puede asumir uno de los roles de un conjunto dado (restricción estática o dinámica por sesión).
Cardinalidad: límites sobre el número de usuarios por rol, roles por usuario, o roles por sesión.
Prerrequisitos: un usuario solo puede asumir un rol si previamente tiene otro rol asignado (ej. jerarquía de ascenso funcional en una organización).

Extensiones del Modelo NIST

Extensión	Descripción
SSD (Static Separation of Duties)	Define roles mutuamente excluyentes de forma permanente
DSD (Dynamic Separation of Duties)	Define restricciones sobre los roles que un usuario puede activar en una sesión concreta

2.7 ABAC — Control de Acceso Basado en Atributos

¿Qué es ABAC?

Attribute-Based Access Control (ABAC) autoriza el acceso no en función de la identidad del usuario ni de su rol, sino de los atributos que posee (características del sujeto, el objeto o el contexto).

¿Para qué sirve? Políticas de acceso muy granulares y expresivas.
¿Cuándo se usa? Cuando las condiciones de acceso son complejas y variables (ej. “solo usuarios mayores de 18 años y con residencia en España”).

Ejemplo:
“Cualquier usuario con más de 18 años y de piel morena tiene acceso al sistema” → esto permite incluso el acceso anónimo si la identificación no es estrictamente necesaria.

\[\text{Atributo del sujeto} = \text{Condición de acceso}\]

2.8 Modelos Adicionales de Control de Acceso

CapBAC — Control de Acceso Basado en Capacidades

Combina roles (funciones) con atributos (capacidades).
El acceso solo es posible si el usuario recibe del proveedor del recurso un token de autorización (capability) que demuestra su capacidad para realizar determinadas acciones.
Principal desventaja: hay que mantener y gestionar todos los certificados de autorización.

Risk-Based Access Control

Diseñado para escenarios heterogéneos donde no es posible predecir el número de usuarios y recursos.

El acceso depende del riesgo evaluado en tiempo real:

\[\text{Risk} = V \times P\]

Donde: - \(V\) = valor de la información (criticidad/confidencialidad/integridad del recurso). - \(P\) = probabilidad del acceso (determinada por el análisis de escenarios amenazantes y políticas de seguridad).

OrBAC — Control de Acceso Basado en la Organización

Extiende y mejora RBAC, añadiendo tres dimensiones:

Dimensión	Descripción
Sujetos	Entidades con roles predefinidos y permisos específicos
Actividades	Conjunto de acciones bajo una misma política de seguridad
Vistas	Relación con los objetos y su acceso según políticas organizativas

Depende de: (1) las políticas de seguridad de la organización, y (2) el nivel de confianza de cada entidad.

2.9 Comparativa Global de Modelos de Control de Acceso

Modelo	Base del control	Flexibilidad	Escalabilidad	Uso típico
DAC	Identidad + reglas del propietario	Alta	Baja (muchos-a-muchos)	S.O., BD
MAC	Etiquetas de clasificación	Baja	Alta	Militar, gobierno
RBAC	Roles organizativos	Alta	Alta	Empresas, ERPs, BBDD
ABAC	Atributos del sujeto/objeto	Muy alta	Media	IoT, cloud, acceso anónimo
CapBAC	Tokens de capacidad	Media	Media	IoT, servicios distribuidos

Quinta Parte: Protocolos Criptográficos Avanzados

1. Introducción a los Protocolos Criptográficos

¿Qué es un protocolo criptográfico?

Un protocolo criptográfico es un algoritmo distribuido definido para alcanzar un objetivo específico de seguridad. Consta de una secuencia precisa de pasos que especifica las acciones a llevar a cabo por dos o más entidades.

Las primitivas criptográficas que los sustentan son: algoritmos de cifrado, firmas digitales, funciones hash, MACs, generadores pseudoaleatorios, etc.

Ejemplos de protocolos criptográficos avanzados (más allá del intercambio de claves y autenticación de entidades):

División y compartición de secretos
Timestamping (sellado de tiempo)
Bit-commitment (compromiso de bit)
Lanzamiento de moneda
Póker mental
Demostraciones de conocimiento cero (Zero-Knowledge)
Canal subliminal

2. Protocolo de División de Secretos

2.1 Concepto

El protocolo de división de secretos se usa cuando hay que dividir un mensaje \(M\) en \(n\) trozos de forma que:

Cada trozo por sí mismo no tiene valor.
Cuando se combinan todos, se recupera el mensaje original.

El esquema más simple divide un mensaje entre dos personas y requiere la intervención de una Tercera Parte Confiable (TTP), habitualmente denominada Trent.

2.2 Ejemplo con 2 personas (XOR)

División (realizada por Trent):

Trent genera una cadena aleatoria de bits \(R\) de la misma longitud que \(M\).
Trent computa \(S = M \oplus R\).
Trent entrega \(R\) a Alice y \(S\) a Bob.

Reconstrucción:

Alice y Bob computan: \(R \oplus S = M\)

Analogía criptográfica.

En esencia, Trent está cifrando el mensaje con un one-time pad: entrega el texto cifrado a una persona y el pad a otra. El sistema es perfectamente seguro si ninguno de los dos coopera con el adversario.

2.3 Extensión a 4 personas

Trent genera tres cadenas aleatorias \(R\), \(S\), \(T\) de la misma longitud que \(M\).
Computa: \(M \oplus R \oplus S \oplus T = U\)
Distribuye: \(R\) → Alice, \(S\) → Bob, \(T\) → Carol, \(U\) → Dave.

Reconstrucción:

\[R \oplus S \oplus T \oplus U = M\]

Limitación crítica.

Si una sola parte pierde su trozo, el mensaje no puede recuperarse. Todos los trozos son necesarios sin excepción. Esto lo diferencia del protocolo de compartición de secretos.

3. Protocolo de Compartición de Secretos (Secret Sharing)

¿Qué es el Secret Sharing?

El protocolo de compartición de secretos se basa en el concepto de esquema umbral \((k, n)\): se divide un mensaje \(M\) en \(n\) trozos (llamados sombras), de forma que cualquier subconjunto de \(k\) sombras es suficiente para reconstruir el mensaje original.

¿Para qué sirve? Compartir secretos críticos (claves criptográficas, contraseñas maestras) con tolerancia a pérdidas.
¿Cuándo se usa? Custodias de claves, sistemas de recuperación ante desastres, acceso a bóvedas.

Ventaja clave: el conocimiento de \(k-1\) sombras no revela ninguna información sobre el secreto.

3.1 Fundamento Matemático: Interpolación Polinómica

El esquema umbral \((k, n)\) se basa en la propiedad de que dados \(k\) puntos de un polinomio de grado \(k-1\), hay uno y solo un polinomio que los interpola:

\[q(x_i) = y_i, \quad \forall i\]

Se elige aleatoriamente un polinomio de grado \(k-1\):

\[q(x) = a_0 + a_1 x + a_2 x^2 + \dots + a_{k-1} x^{k-1}\]

Donde \(a_0 = D\) (el secreto a compartir), y los demás coeficientes se eligen aleatoriamente.

Las sombras son los valores evaluados en el polinomio:

\[D_1 = q(1),\quad D_2 = q(2),\quad \dots,\quad D_n = q(n)\]

Con \(k\) sombras cualesquiera se puede reconstruir el polinomio por interpolación y obtener \(D = q(0) = a_0\).

3.2 Ejemplo — Esquema Umbral (3, 5)

Datos del problema: - Secreto: \(D = 11\) - Número total de sombras: \(n = 5\) - Umbral de reconstrucción: \(k = 3\)

Construcción del polinomio (\(k-1 = 2\) → grado 2):

\[q(x) = a_0 + a_1 x + a_2 x^2\]

Con \(a_0 = 11\) (el secreto), \(a_1 = 2\), \(a_2 = 1\) (aleatorios):

\[q(x) = 11 + 2x + x^2\]

Distribución de sombras:

Usuario	Evaluación	Sombra
Alice	\(q(1)\)	14
Bob	\(q(2)\)	19
Carol	\(q(3)\)	26
Dave	\(q(4)\)	35
Eve	\(q(5)\)	46

Ningún usuario posee el secreto original (11), pero cualquier trío puede cooperar para recuperarlo.

Reconstrucción con Alice, Bob y Dave:

\[q(1) = 14 = a_0 + a_1 \cdot 1 + a_2 \cdot 1^2\] \[q(2) = 19 = a_0 + a_1 \cdot 2 + a_2 \cdot 2^2\] \[q(4) = 35 = a_0 + a_1 \cdot 4 + a_2 \cdot 4^2\]

Sistema de 3 ecuaciones con 3 incógnitas → se obtiene \(a_0 = D = 11\).

3.3 Comparativa: División vs. Compartición

Característica	División de Secretos	Compartición \((k, n)\)
Trozos necesarios	Todos los \(n\)	Cualquier \(k\) de los \(n\)
Tolerancia a pérdidas	Ninguna	Sí (hasta \(n - k\) pérdidas)
Seguridad con \(k-1\) trozos	No garantizada	Información cero revelada
Complejidad matemática	XOR simple	Interpolación polinómica

4. Protocolos de Bit-Commitment

¿Qué es el Bit-Commitment?

El bit-commitment es un protocolo que permite a Alice comprometerse con un valor (bit) sin revelarlo a Bob, garantizando que tampoco podrá modificarlo más tarde.

¿Para qué sirve? Garantizar que una predicción o apuesta es irrevocable, incluso antes de revelarse.
¿Cuándo se usa? Protocolos de negociación, apuestas digitales, licitaciones ciegas, bases de protocolos más complejos.

Propiedades requeridas: - Ocultamiento (hiding): Bob no puede conocer el bit comprometido. - Vinculación (binding): Alice no puede cambiar el bit después de comprometerse.

Escenario: Alice quiere hacer una predicción sin revelarla hasta después del evento. Bob quiere asegurarse de que Alice no puede cambiar la predicción a posteriori.

4.1 Solución con Criptografía Simétrica

Bob genera aleatoriamente una cadena \(R\) de bits y la envía a Alice.
\(\text{Bob} \to \text{Alice}: R\)
Alice crea un mensaje con el bit \(b\) y la cadena aleatoria de Bob, lo cifra con una clave aleatoria \(K\) y envía el resultado a Bob.
\(\text{Alice} \to \text{Bob}: E_K(R, b)\)
(Alice queda comprometida; Bob no puede descifrar sin \(K\))
(Cuando llega el momento de revelar) Alice envía la clave a Bob.
\(\text{Alice} \to \text{Bob}: K\)
Bob descifra y verifica que su cadena aleatoria coincide.
\(\text{Bob}: D_K(E_K(R, b))\)
(La presencia de \(R\) en el mensaje impide que Alice haya enviado un mensaje distinto al original)

4.2 Solución con Funciones Hash

Alice genera dos cadenas aleatorias \(R_1\) y \(R_2\), y crea el mensaje \((R_1, R_2, b)\).
Computa el hash del mensaje y lo envía a Bob junto a \(R_1\).
\(\text{Alice} \to \text{Bob}: H(R_1, R_2, b),\ R_1\)
(El hash previene que Bob pueda invertirlo para obtener \(b\); \(R_2\) garantiza que Alice no pueda encontrar colisiones fácilmente)
(Cuando llega el momento de revelar) Alice envía el mensaje completo.
\(\text{Alice} \to \text{Bob}: R_1, R_2, b\)
Bob computa el hash y compara.
\(\text{Bob}: H(R_1, R_2, b)\) → verifica que coincide con el recibido en el paso 2.

5. Protocolos de Lanzamiento de Moneda

5.1 Concepto

Problema: Alice y Bob quieren decidir el resultado de un lanzamiento de moneda (cara o cruz) de forma justa, sin estar físicamente presentes y sin que ninguno pueda hacer trampa.

Propiedades requeridas del protocolo:

Alice debe lanzar la moneda antes de que Bob se pronuncie.
Alice no puede re-lanzar la moneda después del pronunciamiento de Bob.
Bob no puede conocer el resultado antes de pronunciarse.

Soluciones posibles:

Usando el protocolo de bit-commitment.
Usando criptografía de clave pública.

5.2 Solución con Criptografía Asimétrica

Requisito técnico clave: el sistema de cifrado debe satisfacer la propiedad conmutativa:

\[D_{K1}(E_{K2}(E_{K1}(M))) = E_{K2}(M)\]

Protocolo:

Alice y Bob generan, cada uno, un par de claves pública/privada: \[\text{Alice}: K_{Apu},\ K_{Apr} \qquad \text{Bob}: K_{Bpu},\ K_{Bpr}\]
Alice genera dos mensajes \(M_1\) (“cara”) y \(M_2\) (“cruz”), con cadenas aleatorias para verificar autenticidad. Los cifra con su clave pública y los envía a Bob en orden aleatorio: \[\text{Alice} \to \text{Bob}: E_{Apu}(M_1),\ E_{Apu}(M_2)\]
Bob, sin poder leer los mensajes, elige uno al azar, lo cifra con su clave pública y se lo devuelve a Alice: \[\text{Bob} \to \text{Alice}: E_{Bpu}(E_{Apu}(M))\]
Alice, sin poder leer el mensaje de Bob, lo descifra con su clave privada (gracias a la propiedad conmutativa) y lo devuelve: \[D_{Apr}(E_{Bpu}(E_{Apu}(M))) = E_{Bpu}(M)\] \[\text{Alice} \to \text{Bob}: E_{Bpu}(M)\]
Bob descifra con su clave privada y obtiene el resultado del lanzamiento; envía \(M\) a Alice: \[\text{Bob}: D_{Bpr}(E_{Bpu}(M)) = M \qquad \text{Bob} \to \text{Alice}: M\]
Alice lee el resultado y verifica la cadena aleatoria para confirmar autenticidad.

Refuerzo conceptual: ¿por qué esto es justo?

Ni Alice ni Bob conocen el resultado hasta el paso 5.
Alice no puede elegir qué mensaje descifra Bob (lo elige Bob en el paso 3 sobre mensajes que no puede leer).
La cadena aleatoria en los mensajes previene que Alice prepare mensajes trampa.
No se necesita una tercera parte de confianza.

6. Protocolo de Póker Mental

El protocolo de póker mental es una generalización del protocolo de lanzamiento de moneda, aplicado al reparto justo de cartas en una partida de póker sin baraja física ni árbitro.

Protocolo:

Alice y Bob generan sus pares de claves: \[\text{Alice}: K_{Apu},\ K_{Apr} \qquad \text{Bob}: K_{Bpu},\ K_{Bpr}\]
Alice genera 52 mensajes (uno por carta), con cadenas aleatorias. Los cifra con su clave pública y los envía a Bob en orden aleatorio: \[\text{Alice} \to \text{Bob}: E_{Apu}(M_i),\quad i = 1\ldots52\]
Bob elige aleatoriamente 5 mensajes para su mano, los cifra con su clave pública y los devuelve a Alice: \[E_{Bpu}(E_{Apu}(M_j^B)),\quad j = 1\ldots5\]
Alice descifra con su clave privada y devuelve los mensajes a Bob: \[D_{Apr}(E_{Bpu}(E_{Apu}(M_j^B))) = E_{Bpu}(M_j^B) \qquad \text{Alice} \to \text{Bob}: E_{Bpu}(M_j^B)\]
Bob descifra con su clave privada y obtiene su mano: \[D_{Bpr}(E_{Bpu}(M_j^B)) = M_j^B\]
De los 47 mensajes restantes, Bob elige 5 para Alice y se los envía: \[\text{Bob} \to \text{Alice}: E_{Apu}(M_k^A),\quad k = 1\ldots5\]
Alice descifra con su clave privada y obtiene su mano: \[D_{Apr}(E_{Apu}(M_k^A)) = M_k^A\]

Propiedad clave del protocolo.

En ningún momento ninguno de los dos puede conocer las cartas del otro antes de que el protocolo lo permita, y ninguno puede manipular el reparto sin que el otro lo detecte mediante la verificación de las cadenas aleatorias.

Referencias Bibliográficas

Bibliografía básica:

Schneier, B. Applied Cryptography: Protocols, Algorithms, and Source Code in C. Wiley, 1996 (2ª edición).
Stallings, W. Cryptography and Network Security: Principles and Practice. Prentice Hall, 2010 (5ª edición).
Stallings, W. y Brown, L. Computer Security: Principles and Practice. Prentice-Hall, 2011 (2ª edición).

Estándares y RFCs:

RFC 5280 — Internet X.509 PKI Certificate and CRL Profile, 2008.
RFC 6818 — Updates to RFC 5280, 2013.
RFC 6960 — X.509 OCSP, 2013.
RFC 2828 — Internet Security Glossary, 2000.
ITU-T X.509 — Public-key and attribute certificate frameworks, 2012.
FIPS PUB 140-2 — Security Requirements for Cryptographic Modules (NIST, 2001).

Otras referencias:

Guía de Referencia del DNIe con NFC, 2015.