Mecanismos_de_Proteccion

La criptografía estudia, desde un punto de vista matemático, los méto-dos de protección de la información. Por otro lado, el criptoanálisis estudia las posibles técnicas utilizadas para contrarrestar los métodos criptográficos, y es de gran utilidad para ayudar a que estos sean más robustos y difíciles de atacar. El conjunto formado por estas dos disci-plinas, criptografía y criptoanálisis, se conoce comocriptología.CriptografíaLos términos criptografía, criptología, etc. provienen de la raíz griega kryptós, que significa “escondido”. Cuando la protección que queremos obtener consiste en garantizar el secreto de la información, es decir, la confidencialidad, utilizamos el método crip-tográfico conocido como cifrado.

Uso de cifradoEl hecho de usar técnicas de cifrado parte de la idea que es muy costoso intentar evitar que un intruso intercepte la información. Enviar mensajes cifrados es más fácil, ya que no podrá interpretar la información que contienen.Un esquema como el del cifrado de César tiene el inconveniente de que, si el enemigo descubre cuál es el algoritmo de cifrado (y a partir de aquí deduce el algoritmo inverso), será capaz de interpretar todos los mensajes cifrados que capture. Entonces se requeriría instruir a todos los “oficiales de comunica-ciones” del ejército para que aprendieran un nuevo algoritmo, lo cual podría resultar complejo. En lugar de ello, lo que se hace en la actualidad es utilizar como algoritmo una función con un parámetro llamadoclave

Continuando con el ejemplo del algoritmo del César generalizado (con clave), un ataque criptoanalítico podría consistir en el análisis de las propiedades estadísticas del texto cifrado. Las letras cifradas que más se repiten probablemente corresponderán a vocales o a las consonantes más frecuentes, las combinaciones más repetidas de dos (o tres) letras seguidas probablemente corresponden a los dígrafos (o trígrafos) que normalmente aparecen más veces en un texto.Por otro lado, el ataque por fuerza bruta consistiría en intentar el descifrado con cada uno de los 25 posibles valores de la clave (1 ≤ x ≤ 25, si el alfabeto tiene 26 letras) y mirar cuál de ellos da un resultado inteligible. En este caso, la cantidad necesaria de recursos es tan modesta que incluso se puede realizar el ataque a mano. Por lo tanto, este cifrado seria un ejemplo de algoritmo inseguro o débil.

Los sistemas criptográficos de clave simétricase caracterizan porque la clave de descifrado x es idéntica a la clave de cifradok, o bien se puede deducir directamente a partir de ésta.Para simplificar, supondremos que en este tipo de criptosistemas la clave de descifrado es igual a la de cifrado: x = k (si no, siempre podemos considerar que en el algoritmo de descifrado el primer paso es calcular la clave x a partir de k). Es por esto que estas técnicas criptográficas se denominan declave simétrica, o a veces también declave compartida. Así, tenemos:

El funcionamiento de una cifrado en flujo consiste en la combinación de un texto en claro M con un texto de cifrado S que se obtiene a partir de la clave simétricak. Para descifrar, sólo se requiere realizar la operación inversa con el texto cifrado y el mismo texto de cifrado S.La operación de combinación que se utiliza normalmente es la suma, y la operación inversa por tanto es la resta. Si el texto está formado por caracteres, este algoritmo sería como una cifra de César en que la clave va cambiando de un carácter a otro. La clave que corresponde cada vez viene dada por el texto de cifrado S (llamado keystream en inglés).

Si el texto de cifrado S depende exclusivamente de la clave k, se dice que el cifrado es síncrono. Este cifrado tiene el problema de que, si por algún error de trans-misión, se pierden bits (o llegan repetidos), el receptor se desincronizará y sumará bits del texto S con bits del texto cifrado C que no corresponden, con lo cual el texto descifrado a partir de entonces será incorrecto.Esto se puede evitar con el cifrado asíncrono (o auto-sincronizante), en el cual el texto S se calcula a partir de la clave k y el mismo texto cifrado C. Es decir, en lugar de realimentarse con sus propios bits de estado, el generador se realimenta con los últimos n bits cifrados transmitidos. De este modo, si se pierden m bits consecutivos en la comunicación, el error afectará como máximo al descifrado de m + n bits del mensaje original.

En una cifra de bloque, el algoritmo de cifrado o descifrado se aplica separadamente a bloques de entrada de longitud fija b, y para cada uno de ellos el resultado es un bloque de la misma longitud.Para cifrar un texto en claro de L bits debemos dividirlo en bloques de b bits cada uno y cifrar estos bloques uno a uno. Si L no es múltiple deb, se pueden agregar bits adicionales hasta llegar a un número lleno de bloques, pero luego puede ser necesario indicar de alguna forma cuántos bits había realmente en el mensaje original. El descifrado también se debe realizar bloque a bloque.

Aparte de cifrar datos, existen algoritmos basados en técnicas criptográficas que se usan para garantizar la autenticidad de los mensajes. Un tipo de al-goritmos de estas características son las llamadas funciones hash seguras, también conocidas como funciones deresumen de mensaje (message digest, en inglés).En general, podemos decir que una función hash nos permite obtener una cadena de bits de longitud fija, relativamente corta, a partir de un mensaje de longitud arbitraria:

Como hemos visto en el subapartado anterior, uno de los problemas de la crip-tografía de clave simétrica es el de la distribución de las claves. Este problema se puede solucionar si utilizamos algoritmos de clave pública, también lla-mados de clave asimétrica.En un algoritmo criptográfico de clave pública se utilizan claves distin-tas para el cifrado y el descifrado. Una de ellas, la clave pública, se puede obtener fácilmente a partir de la otra, laclave privada, pero por el contrario es computacionalmente de muy difícil obtención la clave privada a partir de la clave pública.

un canal inseguro para comunicarse se resuelve con la criptografía de clave pública. Cuando A quiere mandar un mensaje secreto M a B, no hace falta cifrar todo el mensaje con un algoritmo de clave pública (esto podría re-sultar muy lento), sino que se escoge una clave simétricaks, en ocasiones llamada clave de sesión o clave de transporte, y se cifra el mensaje con un algoritmo simétrico usando esta clave. Lo único que hace falta cifrar con la clave pública deB (kpubB ) es la clave de sesión. En recepción, B utiliza su clave privada (kprB ) para recuperar la clave de sesión ks, y entonces ya puede descifrar el mensaje cifrado.

Como hemos visto hasta ahora, la criptografía de clave pública permite re-solver el problema del intercambio de claves, utilizando las claves públicas de los participantes. Pero se platea otro problema: si alguien afirma ser A y su clave pública eskpub, ¿cómo podemos saber que realmente kpub es la clave pública de A? Porque es perfectamente posible que un atacante Z genere su par de claves (kpr0, kpub0) y afirme “yo soy A, y mi clave pública eskpub0”.Una posible solución a este problema es que exista una entidad de confian-za que nos asegure que, efectivamente, las claves públicas pertenecen a sus supuestos propietarios. Esta entidad puede firmar un documento que afirme “la clave pública de A es kpubA ”, y publicarlo para que todos los usuarios lo sepan. Este tipo de documento se llama certificado de clave pública o cer-tificado digital, y es la base de lo que se conoce como infraestructura de clave pública.

Un certificado de clave pública o certificado digital consta de tres partes básicas:•    Una identificación de usuario como, por ejemplo, su nombre.•    El valor de la clave pública de este usuario.•    La firma de las dos partes anteriores.PKILa sigla PKI corresponde al nombre en inglés de la infraestructura de clave pública (Public Key Infrastructure).Si el autor de la firma es alguien en quien confiamos, el certificado nos sirve como garantía de que la clave pública pertenece al usuario que figura iden-tificado en el certificado. Quien firma el certificado puede ser una autoridad que se responsabilice de verificar fehacientemente la autenticidad de las claves públicas. En este caso, se dice que el certificado ha sido generado por una au-toridad de certificación (CA).

Un certificado nos soluciona el problema de la autenticidad de la clave pública si está firmado por una CA en la cual confiamos, Pero que pasa si nos comu-nicamos con un usuario que tiene un certificado emitido por una CA que no conocemos?Existe la posibilidad que una CA tenga un certificado que garantice la auten-ticidad de su clave pública, firmado por otra CA. Esta otra CA puede que si que la conozcamos, o puede que a su vez tenga un certificado firmado por una tercera CA, y así sucesivamente. De esta forma, se puede establecer una jer-arquía de autoridades de certificación, donde las CA de nivel más bajo emiten los certificados de usuario, y las CA de cada nivel son certificadas por una de nivel superior.

La Recomendación X.509, además de definir el formato de los certificados, también define otra estructura llamada lista de revocación de certificados o CRL. Una lista de este tipo sirve para publicar los certificados que han dejado de ser válidos antes de su fecha de caducidad. Los motivos pueden ser diversos: se ha emitido otro certificado que sustituye al revocado, ha cambiado el DN del titular (por ejemplo, ha dejado de trabajar en la empresa en la que estaba), le han robado su clave privada, etc.De este modo, si queremos asegurarnos completamente de la validez de un cer-tificado, no basta con verificar su firma, sino que debemos obtener la versión actual de la CRL (publicada por la CA que emitió el certificado) y comprobar que el certificado no aparece en esta lista.Una CA normalmente actualizará su CRL de forma periódica, añadiendo cada vez los certificados que hayan sido revocados. Cuando llegue la fecha de ca-ducidad que constaba en el certificado, ya no será necesario volver a incluirlo en la CRL. Esto permite que las CRL no crezcan indefinidamente.

•    La autenticación de mensaje o autenticación de origen de datos permite confirmar que el originador A de un mensaje es auténtico, es decir, que el mensaje no ha sido generado por un tercero Z que quiere hacer creer que lo ha generado A.Como efecto adicional, la autenticación de mensaje proporciona im-plícitamente el servicio de integridad de datos, que permite confir-mar que nadie ha modificado un mensaje enviado por A.•    La autenticación de entidad permite confirmar la identidad de un participante A en una comunicación, es decir, que no se trata de un tercero Z que dice ser A.

•    Los códigos de autenticación de mensaje o MAC, basados en claves simétricas.• Las firmas digitales, que se basan en la criptografía de clave pública.

Un código de autenticación de mensaje o MAC se obtiene con un algoritmo a que tiene dos entradas: un mensaje M de longitud arbitraria, y una clave secreta k compartida por el originador y el destinatario del mensaje. Como resultado da un código CMAC = a(k, M) de longitud fija. El algoritmo MAC debe garantizar que sea computacionalmente inviable encontrar un mensaje M0 6=M que de el mismo código que M, y también obtener el código de un mensaje cualquiera sin conocer la clave.

Los códigos MAC, dado que se basan en una clave secreta, sólo tienen signifi-cado para quienes conozcan dicha clave. Si A envía mensajes a B autenticados con una clave compartida, sólo B podrá verificar la autenticidad de estos men-sajes.Por otro lado, en caso de un conflicto en que     A denegase la autoría de unmensaje autenticado, B no podría demostrar delante de un tercero imparcial (por ejemplo, un árbitro o un juez) que el mensaje lo generó A. Revelar la clave secreta no sería prueba suficiente ya que, por el hecho de ser conocida por las dos partes, siempre habría la posibilidad que el mensaje en disputa y el su código de autenticación los hubiera generado B.En cambio, si A autentica los mensajes adjuntándoles la firma digital calculada con su clave privada, todo el mundo podrá verificarlos con su clave pública. Esta técnica de autenticación proporciona, como efecto adicional, el servicioCódigo HMACPara calcular el código HMAC, al mensaje se le añade como prefijo una cadena de bits derivada de la clave, se calcula su hash, al resultado se le prefija otra cadena de bits derivada de la clave, y se vuelve a calcular el hash. (Aun que se tenga que llamar dos veces la función hash, la segunda será mucho más rápida puesto que los datos a resumir serán más cortos.)de no repudio. Esto quiere decir que un destinatario B puede demostrar feha-cientemente ante un tercero que un mensaje ha sido generado por A.

La autenticación de entidad se utiliza cuando en una comunicación una de las partes quiere asegurarse de la identidad de la otra. Normalmente, esta autenticación es un requisito para permitir el acceso a un recurso restringido, como, por ejemplo, una cuenta de usuario en un ordenador, dinero en efectivo en un cajero automático, acceso físico a una habitación, etc.En general, las técnicas utilizadas para la identificación de un usuario A pueden estar basadas en:•    Algo que A sabe como, por ejemplo, una contraseña o una clave privada.•    Algo que A tiene como, por ejemplo, una tarjeta con banda magnética o con chip.•    Algo que A es o, dicho de otro modo, alguna propiedad inherente a A como, por ejemplo, sus características biométricas.

La idea básica de la autenticación basada en contraseñas es que el usuarioA manda su identidad (su identificador de usuario, su nombre de login, etc.) seguida de una contraseña secreta xA (una palabra o combinación de carac-teres que el usuario pueda memorizar). El verificador B comprueba que la contraseña sea válida, y si lo es da por buena la identidad deA.Existen distintas maneras de llevar a cabo esta autenticación, y también hay maneras diversas de intentar atacarla. A continuación veremos algunas vari-antes de la autenticación con contraseñas que intentan evitar determinados tipos de ataques.

Si se trata de las contraseñas correspondientes a usuarios de un sistema infor-mático,es evidente que no pueden estar guardadas en un fichero de acceso público: es necesario que la lista esté protegida contra lectura. Pero si alguien encuentra la manera de saltarse esta protección (cosa que en ocasiones pasa en los sistemas multiusuario), automáticamente tendrá acceso a las contraseñas de todos los usuarios.

Una segunda opción consiste en que en la lista de contraseñas, en lugar de estar guardadas éstas en claro por pares(A, xA), cada una esté codificada con alguna transformación C de manera que no se pueda deducir su valor real. De este modo, la lista debe contener pares (A,C(xA)).Esta codificación C podría ser, por ejemplo, un cifrado, pero entonces sería preciso tomar las precauciones oportunas con la clave de descifrado (quien consiguiera acceder a esta clave podría obtener todas las contraseñas). Lo más habitual es que la codificación consista en la aplicación de una función unidireccional como ,

Un caso muy conocido es el de la gestión de las contraseñas en el sistema operativo Unix, ya que la mayoría de las variantes de Unix usadas actualmente utilizan técnicas muy parecidas, basadas en las versiones originales de este sistema.En Unix existe un fichero en el que se guardan las contraseñas de los usuarios codi-ficadas con una función unidireccional. Pero en lugar de una función hash, lo que se utiliza es un cifrado simétrico: el texto en claro es fijo (una cadena de bits todos iguales a 0), como clave de cifrado se utiliza la contraseña, y lo que se guarda en la lista es el texto cifrado. De esta forma se aprovecha la propiedad que tienen los algoritmos crip-tográficos que no permiten deducir la clave a partir del texto cifrado ni que se conozca el texto en claro.

El problema que tienen los esquemas de autenticación basados en contraseñas es que cada vez que se quiere realizar la autenticación se tiene que enviar el mismo valor al verificador (excepto en las contraseñas de un solo uso, como acabamos de ver). Cualquier atacante que consiga interceptar este valor fijo podrá suplantar la identidad del usuario a quien corresponda la contraseña.Hay otro grupo de mecanismos donde el valor que se envía para la autenti-cación no es fijo, sino que depende de otro, generado por el verificador. Este último valor se llama reto, y se debe enviar al usuario A como primer paso para su autenticación. Entonces A, haciendo uso de una clave secreta, calcula una respuesta a partir de este reto, y lo envía al verificador B. Por este mo-tivo, estos mecanismos de autenticación reciben el nombre de protocolos de reto-respuesta.

El verificador descifra el mensaje recibido y comprueba si la marca de tiempo es aceptable, es decir, si está dentro la tolerancia de sincronía y no esta repetida.Si se utiliza la misma clave en los dos sentidos (de A a B y de B a A), el hecho de incluir la identidad del verificador B evita que, en un proceso de autenticación mutua, un atacante intente hacerse pasar por B delante de A repitiendo el mensaje en sentido contrario.

El verificador descifra el mensaje y comprueba que el número aleatorio que contiene es igual al reto. El hecho de incluir la identidad del verificador B evita que el mensaje se pueda utilizar en sentido contrario si alguna vez A genera como reto el mismo númerorB.

de autenticación mutua, es decir, de A delante B y de B delante A. En este caso, A debe generar otro número aleatorio rA, que actuará como reto en sentido inverso, y incluirlo en su respuesta.

Los protocolos anteriores hacen uso de un algoritmo de cifrado simétrico, pero también es posible utilizar funciones unidireccionales con clave sec-reta como, por ejemplo, los algoritmos de MAC. Para la verificación, en lugar de descifrar es preciso comprobar que el MAC sea correcto y, por tanto, los valores necesarios para calcularlo se han de enviar en claro.A continuación se muestran las variantes de los protocolos anteriores cuan-do se utiliza un algoritmo de MAC en lugar de un algoritmo de cifrado.

Hay dos formas de utilizar las técnicas de clave pública en los protocolos de reto-respuesta:•    El reto se manda cifrado con clave pública y la respuesta es el reto descifra-do con la correspondiente clave privada.•    El reto se envía en claro y la respuesta es la firma del reto.

Si A recibe un reto cifrado con su clave pública, antes de enviar la respues-ta debe asegurarse que quien ha enviado el reto conoce su valor. Sino, un atacante podría enviarle a A un reto cifrado, haciendo creer que lo ha gen-erado aleatoriamente, pero que en realidad lo ha extraído de otro mensaje confidencial que alguien había enviado a A cifrado con su clave pública. Si A responde a este reto, está dando al atacante el mensaje confidencial descifrado.

La Recomendación X.509 no sólo especifica los formatos de certifica-dos y listas de revocación que hemos visto en el subapartado 1.3, sino que también define unos protocolos de autenticación fuerte basados en fir-mas digitales que utilizan marcas de tiempo y números aleatorios. Aquí mostraremos otros protocolos, que son los equivalentes a los que hemos visto anteriormente basados en claves simétricas.

La arquitectura IPsec (RFC 2401) añade servicios de seguridad al pro-tocolo IP (versión 4 y versión 6), que pueden ser usados por los proto-colos de niveles superiores (TCP, UDP, ICMP, etc.).

El campo Next Header sirve para indicar a que protocolo corresponden los datos que vienen a continuación de la cabecera AH. El campo Payload Length indica la longitud de la cabecera (esta información se necesita porque el últi-mo campo es de longitud variable, ya que depende del algoritmo de autentifi-cación).El campo SPI sirve para identificar a que SA corresponde esta cabecera AH, y el número de secuencia que se utiliza si se quiere proporcionar el servicio de protección contra repetición de datagramas.

A continuación vienen los datos del datagrama (payload ), a los cuales puede ser necesario añadir bytes adicionales (padding) si se utiliza un algoritmo de cifrado en bloque, para conseguir que el número de bytes a cifrar sea múltiple de la longitud de bloque. El campo Padding Length indica exactamente el número de bytes que se han añadido (puede ser 0). El campoNext Header indica de que protocolo son los datos del datagrama.

La arquitectura IPsec define dos modos de uso de los protocolos AH y ESP, dependiendo de como se incluyan las cabeceras correspondientes en un data-grama IP.•    En el modo transporte, la cabecera AH o ESP se incluye después de la cabecera IP convencional, como si fuera una cabecera de un protocolo de nivel superior, y a continuación van los datos del datagrama (por ejemplo, un segmento TCP con su cabecera correspondiente, etc.).•    En el modo túnel, el datagrama original se encapsula entero, con su cabecera y sus datos, dentro de otro datagrama. Este otro datagrama tendrá una cabecera IP en la cual las direcciones de origen y de destino serán las de los nodos inicio y final de la SA. Por tanto, se dice que entre estos dos nodos hay un “túnel” dentro del cual viajan intactos los datagramas orig-inales. A continuación de la cabecera IP del datagrama “externo” hay la cabecera AH o ESP.

Un método alternativo que no necesita modificaciones en los equipos de interconexión es introducir la seguridad en los protocolos de transporte. La solución más usada actualmente es el uso del protocolo SSL o de otros basados en SSL.

Las funciones de seguridad, pero, no se implementaron directamente en el protocolo de aplicación HTTP, si no que se optó por introducirlas a nivel de transporte. De este modo podría haber muchas más aplicaciones que hicieran uso de esta funcionalidad. Con este fin se desarrolló una interfaz de acceso a los servicios del nivel de transporte basada en la interfaz estándar de lossockets. En esta nueva inter-faz, funciones como connect, accept, send o recv fueron sustituidas por otras equivalentes pero que utilizaban un protocolo de transporte seguro:SSL_connect, SSL_accept, SSL_send, SSL_recv, etc. El diseño se realizó de tal modo que cualquier aplicación que utilizara TCP a través de las llamadas de los sockets podía hacer uso del protocolo SSL solamente cam-biando estas llamadas. De aquí proviene el nombre del protocolo.

El protocolo de negociación SSL/TLS, también llamado protocolo de encajada de manos (“Handshake Protocol”), tiene por finalidad aut-enticar el cliente y/o el servidor, y acordar los algoritmos y claves que se utilizaran de forma segura, es decir, garantizando la confidencialidad y la integridad de la negociación

Los protocolos SSL/TLS están diseñados para resistir los siguientes ataques:Lectura de los paquetes enviados por el cliente y servidor. Cuando los datos se envían cifrados, un atacante que pueda leer los paquetes, por ejemplo uti-lizando técnicas desniffing, se enfrenta al problema de romper el cifrado si quiere interpretar su contenido. Las claves que se utilizan para el cifrado se intercambian con métodos de clave pública, que el atacante tendría que romper si quiere saber cuales son los valores acordados.

Cuando se utiliza el cifrado simétrico para proteger las comunicaciones, se puede escoger el algoritmo que sea más apropiado a las necesidades de ca-da aplicación: normalmente, a más seguridad menos velocidad de cifrado, y viceversa.Un aspecto que hay que tener en cuenta es que, aunque el cifrado puede con-seguir que un atacante no descubra directamente los datos transmitidos, en ocasiones es posible que se pueda deducir información indirectamente. Por ejemplo, en un protocolo que utilice mensajes con una cabecera fija, la apari-ción de los mismos datos cifrados varias veces en una transmisión puede in-dicar dónde empiezan los mensajes.