FACULTAD DE INGENIERIA - materias.fi.uba.armaterias.fi.uba.ar/6669/alumnos/1999/ssl.pdfSistemas...

UNIVERSIDAD DE BUENOS AIRES

FACULTAD DE INGENIERIA

CRIPTOGRAFIA Y SEGURIDAD INFORMATICA

TRABAJO PRACTICO:

SEGURIDAD EN INTERNET

Integrantes: Miguel F. Gonzalez 68332 [email protected] Dantowitz 67214 [email protected] Rugna 66956

1er cuatrimestre de 1998

Criptografía y Seguridad Informática 1er cuatrimestre de 1998

Página: 2

Seguridad..........................................................................................................................4

Introducción ............................................................................................................................ 4

Amenazas deliberadas a la seguridad de la información ........................................................ 4

Servicios de seguridad ............................................................................................................ 6

Mecanismos de seguridad ....................................................................................................... 7

Gestión de claves .................................................................................................................... 9

Distribución de claves ........................................................................................................... 10

Almacenamiento de claves .................................................................................................... 11

Tiempo de vida de claves ...................................................................................................... 11

Destrucción de claves ............................................................................................................ 12

Referencias............................................................................................................................. 12

Correo Seguro.................................................................................................................13

Introducción .......................................................................................................................... 13

Cifrado................................................................................................................................... 13

Firma digital .......................................................................................................................... 15

Cómo proteger nuestro correo .............................................................................................. 16

Referencias............................................................................................................................. 16

WEB SEGURO ...............................................................................................................17

Introducción .......................................................................................................................... 17

Secure Socket Layer (SSL).................................................................................................... 17

El Protocolo SSL Handshake ................................................................................................ 18

El Protocolo SSL Record ...................................................................................................... 19

Secure HyperText Transfer Protocol (S-HTTP)................................................................... 20

SSL vs. S-HTTP.................................................................................................................... 21

Autoridades de Certificación: cómo estar seguro de un servidor seguro.............................. 22

Referencias............................................................................................................................. 22

COMERCIO ELECTRÓNICO SEGURO.......................................................................23

Introducción .......................................................................................................................... 23

Características del comercio electrónico .............................................................................. 23

Sistemas basados en tarjetas de crédito................................................................................. 25

Referencias............................................................................................................................. 27

El Protocolo SSL ............................................................................................................29

Introducción .......................................................................................................................... 29

Motivación ............................................................................................................................. 29


Página: 3

El Protocolo SSL Handshake ................................................................................................ 32

Especificación del SSL Record Protocol ............................................................................... 34

Especificación del SSL Handshake Protocol ......................................................................... 36

Ataques .................................................................................................................................. 46

Referencias............................................................................................................................. 48


Página: 4

SSeegguurriiddaadd

Introducción

En estas páginas nos centraremos en la seguridad en la comunicación a través de redes,especialmente Internet, consistente en prevenir, impedir, detectar y corregir violaciones a laseguridad durante la transmisión de información, más que en la seguridad en lascomputadoras, que abarca la seguridad de sistemas operativos y bases de datos.Consideraremos la información esencialmente en forma digital y la protección se asegurarámayormente mediante medios lógicos, más que físicos.

Amenazas deliberadas a la seguridad de la información [1][2]

Se entiende por amenaza una condición del entorno del sistema de información (persona,máquina, suceso o idea) que, dada una oportunidad, podría dar lugar a que se produjese unaviolación de la seguridad (confidencialidad, integridad, disponibilidad o uso legítimo). Lapolítica de seguridad y el análisis de riesgos habrán identificado las amenazas que han de sercontrarrestadas, dependiendo del diseñador del sistema de seguridad especificar losservicios y mecanismos de seguridad necesarios.

Las amenazas a la seguridad en una red pueden caracterizarse modelando el sistema comoun flujo de información desde una fuente, como por ejemplo un archivo o una región de lamemoria principal, a un destino, como por ejemplo otro archivo o un usuario. Un ataque noes más que la realización de una amenaza.

Las cuatro categorías generales de amenazas o ataques son las siguientes:

• Interrupción: un recurso del sistema es destruido o se vuelve no disponible. Este esun ataque contra la disponibilidad. Ejemplos de este ataque son la destrucción de unelemento hardware, como un disco duro, cortar una línea de comunicación odeshabilitar el sistema de gestión de archivos.

• Intercepción: una entidad no autorizada consigue acceso a un recurso. Este es unataque contra la confidencialidad. La entidad no autorizada podría ser una persona,un programa o una computadora. Ejemplos de este ataque son pinchar una líneapara hacerse con datos que circulen por la red y la copia ilícita de archivos oprogramas (intercepción de datos), o bien la lectura de las cabeceras de paquetespara ver la identidad de uno o más de los usuarios implicados en la comunicaciónobservada ilegalmente (intercepción de identidad).

• Modificación: una entidad no autorizada no sólo consigue acceder a un recurso, sinoque es capaz de manipularlo. Este es un ataque contra la integridad. Ejemplos deeste ataque son el cambio de valores en un archivo de datos, alterar un programapara que funcione de forma diferente y modificar el contenido de mensajes que estánsiendo transferidos por la red.


Página: 5

• Fabricación: una entidad no autorizada inserta objetos falsificados en el sistema.Este es un ataque contra la autenticidad. Ejemplos de este ataque son la inserción demensajes espurios en una red o añadir registros a un archivo.

Estos ataques se pueden asimismo clasificar de forma útil en términos de ataques pasivos yataques activos.

Ataques pasivos

En los ataques pasivos el atacante no altera la comunicación, sino que únicamente laescucha o monitorea, para obtener información que está siendo transmitida. Sus objetivosson la intercepción de datos y el análisis de tráfico, una técnica más sutil para obtenerinformación de la comunicación, que puede consistir en:

• Obtención del origen y destinatario de la comunicación, leyendo los headers de lospaquetes monitoreados.


Página: 6

• Control del volumen de tráfico intercambiado entre las entidades monitoreadas,obteniendo así información acerca de actividad o inactividad inusuales.

• Control de las horas habituales de intercambio de datos entre las entidades de lacomunicación, para extraer información acerca de los períodos de actividad.

Los ataques pasivos son muy difíciles de detectar, ya que no provocan ninguna alteración delos datos. Sin embargo, es posible evitar su éxito mediante el cifrado de la información yotros mecanismos que se verán más adelante.

Ataques activos

Estos ataques implican algún tipo de modificación del flujo de datos transmitido o lacreación de un falso flujo de datos, pudiendo subdividirse en cuatro categorías:

• Suplantación de identidad: el intruso se hace pasar por una entidad diferente.Normalmente incluye alguna de las otras formas de ataque activo. Por ejemplo,secuencias de autenticación pueden ser capturadas y repetidas, permitiendo a unaentidad no autorizada acceder a una serie de recursos privilegiados suplantando a laentidad que posee esos privilegios, como al robar la contraseña de acceso a unacuenta.

• Reactuación: uno o varios mensajes legítimos son capturados y repetidos paraproducir un efecto no deseado, como por ejemplo ingresar dinero repetidas veces enuna cuenta dada.

• Modificación de mensajes: una porción del mensaje legítimo es alterada, o losmensajes son retardados o reordenados, para producir un efecto no autorizado. Porejemplo, el mensaje “Ingresa un millón en la cuenta A” podría ser modificado paradecir “Ingresa un millón en la cuenta B”.

• Degradación fraudulenta del servicio: impide o inhibe el uso normal o la gestión derecursos informáticos y de comunicaciones. Por ejemplo, el intruso podría suprimirtodos los mensajes dirigidos a una determinada entidad o se podría interrumpir elservicio de una red inundándola con mensajes espurios.

Servicios de seguridad [1]

Para hacer frente a las amenazas a la seguridad del sistema se definen una serie de serviciospara proteger los sistemas de proceso de datos y de transferencia de información de unaorganización. Estos servicios hacen uso de uno o varios mecanismos de seguridad. Unaclasificación útil de los servicios de seguridad es la siguiente:

• Confidencialidad: requiere que la información sea accesible únicamente por lasentidades autorizadas. La confidencialidad de datos se aplica a todos los datosintercambiados por las entidades autorizadas o tal vez a sólo porciones o segmentosseleccionados de los datos, por ejemplo mediante cifrado. La confidencialidad deflujo de tráfico protege la identidad del origen y destino(s) del mensaje, por ejemploenviando los datos confidenciales a muchos destinos además del verdadero, asícomo el volumen y el momento de tráfico intercambiado, por ejemplo produciendo


Página: 7

una cantidad de tráfico constante al añadir tráfico espurio al significativo, de formaque sean indistinguibles para un intruso. La desventaja de estos métodos es queincrementan drásticamente el volumen de tráfico intercambiado, repercutiendonegativamente en la disponibilidad del ancho de banda bajo demanda.

• Autenticación: requiere una identificación correcta del origen del mensaje,asegurando que la entidad no es falsa. Se distinguen dos tipos: de entidad, queasegura la identidad de las entidades participantes en la comunicación, mediantebiométrica (huellas dactilares, identificación de iris, etc.), tarjetas de bandamagnética, contraseñas, o procedimientos similares; y de origen de información, queasegura que una unidad de información proviene de cierta entidad, siendo la firmadigital el mecanismo más extendido.

• Integridad: requiere que la información sólo pueda ser modificada por las entidadesautorizadas. La modificación incluye escritura, cambio, borrado, creación yreactuación de los mensajes transmitidos. La integridad de datos asegura que losdatos recibidos no han sido modificados de ninguna manera, por ejemplo medianteun hash criptográfico con firma, mientras que la integridad de secuencia de datosasegura que la secuencia de los bloques o unidades de datos recibidas no ha sidoalterada y que no hay unidades repetidas o perdidas, por ejemplo mediante time-stamps.

• No repudio: ofrece protección a un usuario frente a que otro usuario niegueposteriormente que en realidad se realizó cierta comunicación. Esta protección seefectúa por medio de una colección de evidencias irrefutables que permitirán laresolución de cualquier disputa. El no repudio de origen protege al receptor de queel emisor niegue haber enviado el mensaje, mientras que el no repudio de recepciónprotege al emisor de que el receptor niegue haber recibido el mensaje. Las firmasdigitales constituyen el mecanismo más empleado para este fin.

• Control de acceso: requiere que el acceso a los recursos (información, capacidad decálculo, nodos de comunicaciones, entidades físicas, etc.) sea controlado y limitadopor el sistema destino, mediante el uso de contraseñas o llaves hardware, porejemplo, protegiéndolos frente a usos no autorizados o manipulación.

• Disponibilidad: requiere que los recursos del sistema informático estén disponibles alas entidades autorizadas cuando los necesiten.

Mecanismos de seguridad [2]

No existe un único mecanismo capaz de proveer todos los servicios anteriormente citados,pero la mayoría de ellos hacen uso de técnicas criptográficas basadas en el cifrado de lainformación. Los más importantes son los siguientes:

• Intercambio de autenticación: corrobora que una entidad, ya sea origen o destino dela información, es la deseada, por ejemplo, A envía un número aleatorio cifrado conla clave pública de B, B lo descifra con su clave privada y se lo reenvía a A,demostrando así que es quien pretende ser. Por supuesto, hay que ser cuidadoso a la


Página: 8

hora de diseñar estos protocolos, ya que existen ataques para desbaratarlos (Verataques posibles en los ataques al protocolo SSL).

• Cifrado: garantiza que la información no es inteligible para individuos, entidades oprocesos no autorizados (confidencialidad). Consiste en transformar un texto enclaro mediante un proceso de cifrado en un texto cifrado, gracias a una informaciónsecreta o clave de cifrado. Cuando se emplea la misma clave en las operaciones decifrado y descifrado, se dice que el criptosistema es simétrico. Estos sistemas sonmucho más rápidos que los de clave pública, resultando apropiados para funcionesde cifrado de grandes volúmenes de datos. Se pueden dividir en dos categorías:cifradores de bloque, que cifran los datos en bloques de tamaño fijo (típicamentebloques de 64 bits), y cifradores en flujo, que trabajan sobre flujos continuos de bits.Cuando se utiliza una pareja de claves para separar los procesos de cifrado ydescifrado, se dice que el criptosistema es asimétrico o de clave pública. Una clave,la privada, se mantiene secreta, mientras que la segunda clave, la pública, puede serconocida por todos. De forma general, las claves públicas se utilizan para cifrar y lasprivadas, para descifrar. El sistema tiene la propiedad de que a partir delconocimiento de la clave pública no es posible determinar la clave privada. Loscriptosistemas de clave pública, aunque más lentos que los simétricos, resultanadecuados para las funciones de autenticación, distribución de claves y firmasdigitales.

• Integridad de datos: este mecanismo implica el cifrado de una cadena comprimida dedatos a transmitir, llamada generalmente valor de comprobación de integridad(Integrity Check Value o ICV). Este mensaje se envía al receptor junto con losdatos ordinarios. El receptor repite la compresión y el cifrado posterior de los datosy compara el resultado obtenido con el que le llega, para verificar que los datos nohan sido modificados.

• Firma digital: este mecanismo implica el cifrado, por medio de la clave secreta delemisor, de una cadena comprimida de datos que se va a transferir. La firma digital seenvía junto con los datos ordinarios. Este mensaje se procesa en el receptor, paraverificar su integridad. Juega un papel esencial en el servicio de no repudio.

• Control de acceso: esfuerzo para que sólo aquellos usuarios autorizados accedan alos recursos del sistema o a la red, como por ejemplo mediante las contraseñas deacceso.

• Tráfico de relleno: consiste en enviar tráfico espurio junto con los datos válidos paraque el atacante no sepa si se está enviando información, ni qué cantidad de datosútiles se está transmitiendo.

• Control de encaminamiento: permite enviar determinada información pordeterminadas zonas consideradas clasificadas. Asimismo posibilita solicitar otrasrutas, en caso que se detecten persistentes violaciones de integridad en una rutadeterminada.

• Unicidad: consiste en añadir a los datos un número de secuencia, la fecha y hora, unnúmero aleatorio, o alguna combinación de los anteriores, que se incluyen en la


Página: 9

firma digital o integridad de datos. De esta forma se evitan amenazas como lareactuación o resecuenciación de mensajes.

Los mecanismos básicos pueden agruparse de varias formas para proporcionar los serviciospreviamente mencionados. Conviene resaltar que los mecanismos poseen tres componentesprincipales:

• Una información secreta, como claves y contraseñas, conocidas por las entidadesautorizadas.

• Un conjunto de algoritmos, para llevar a cabo el cifrado, descifrado, hash ygeneración de números aleatorios.

• Un conjunto de procedimientos, que definen cómo se usarán los algoritmos, quiénenvía qué a quién y cuándo.

Asimismo es importante notar que los sistemas de seguridad requieren una gestión deseguridad. La gestión comprende dos campos bien amplios:

• Seguridad en la generación, localización y distribución de la información secreta, demodo que sólo pueda ser accedida por aquellas entidades autorizadas.

• La política de los servicios y mecanismos de seguridad para detectar infracciones deseguridad y emprender acciones correctivas.

Gestión de claves [3]

Abarca la generación, distribución, almacenamiento, tiempo de vida, destrucción yaplicación de las claves de acuerdo con una política de seguridad.

Generación de claves

La seguridad de un algoritmo descansa en la clave. Un criptosistema que haga uso de clavescriptográficamente débiles será él mismo débil. Algunos aspectos a considerar que sepresentan a la hora de la elección de las claves son:

Espacio de claves reducido

Cuando existen restricciones en el número de bits de la clave, o bien en la clase de bytespermitidos (caracteres ASCII, caracteres alfanuméricos, imprimibles, etc.), los ataques defuerza bruta con hardware especializado o proceso en paralelo pueden desbaratar en untiempo razonable estos sistemas.

Elección pobre de la clave

Cuando los usuarios eligen sus claves, la elección suele ser muy pobre en general (porejemplo, el propio nombre o el de la mujer), haciéndolas muy débiles para un ataque defuerza bruta que primero pruebe las claves más obvias (ataque de diccionario).

Claves aleatorias

Claves buenas son las cadenas de bits aleatorios generadas por medio de algún procesoautomático (como una fuente aleatoria fiable o un generador pseudo-aleatorio


Página: 10

criptográficamente seguro), de forma que si la clave consta de 64 bits, las 264 clavesposibles sean igualmente probables. En el caso de los criptosistemas de clave pública, elproceso se complica, ya que a menudo las claves deben verificar ciertas propiedadesmatemáticas (ser primos dos veces seguros, residuos cuadráticos, etc.).

Frases

Esta solución al problema de la generación de contraseñas seguras (y fáciles de recordar)por parte del usuario consiste en utilizar una frase suficientemente larga que posteriormentees convertida en una clave aleatoria por medio de un algoritmo (key-crunching).

Distribución de claves [3]

Sin duda alguna, el problema central de todo sistema de gestión de claves lo constituyen losprocedimientos de distribución de éstas. Esta distribución debe efectuarse previamente a lacomunicación. Los requisitos específicos en cuanto a seguridad de esta distribucióndependerán de para qué y cómo van a ser utilizadas las claves. Así pues, será necesariogarantizar la identidad de su origen, su integridad y, en el caso de claves secretas, suconfidencialidad.

Las consideraciones más importantes para un sistema de gestión de claves son el tipo deataques que lo amenazan y la arquitectura del sistema. Normalmente, es necesario que ladistribución de claves se lleve a cabo sobre la misma red de comunicación donde se estátransmitiendo la información a proteger. Esta distribución es automática y la transferenciasuele iniciarse con la petición de clave por parte de una entidad a un Centro de Distribuciónde Claves (intercambio centralizado) o a la otra entidad involucrada en la comunicación(intercambio directo). La alternativa es una distribución manual (mediante el empleo decorreos seguros, por ejemplo), independiente del canal de comunicación. Esta últimaalternativa implica un alto coste económico y un tiempo relativamente largo para llevarse acabo, lo que la hace descartable en la mayoría de las situaciones. La distribución segura declaves sobre canal inseguro requiere protección criptográfica y, por tanto, la presencia deotras claves, conformando una jerarquía de claves. En cierto punto se requerirá protecciónno criptográfica de algunas claves (llamadas maestras), usadas para intercambiar con losusuarios de forma segura las claves que usarán en su(s) futura(s) comunicación(es). Entrelas técnicas y ejemplos no criptográficos podemos citar seguridad física y confianza.

La distribución de claves se lleva siempre a cabo mediante protocolos, es decir, secuenciasde pasos de comunicación (transferencia de mensajes) y pasos de computación. Muchas delas propiedades de estos protocolos dependen de la estructura de los mensajesintercambiados y no de los algoritmos criptográficos subyacentes. Por ello, las debilidadesde estos protocolos provienen normalmente de errores cometidos en los niveles más altosdel diseño.

Las claves criptográficas temporales usadas durante la comunicación, llamadas claves desesión, deben ser generadas de forma aleatoria. Para protegerlas será necesaria seguridadfísica o cifrado mediante claves maestras, mientras que para evitar que sean modificadasdeberá utilizarse seguridad física o autenticación. La autenticación hace uso de parámetros


Página: 11

como time-stamps y contadores para protegerse también contra la reactuación con antiguasclaves.

Almacenamiento de claves [3]

En sistemas con un solo usuario, la solución más sencilla pasa por ser su retención en lamemoria del usuario. Una solución más sofisticada y que desde luego funcionará mejor paraclaves largas, consiste en almacenarlas en una tarjeta de banda magnética, en una llave deplástico con un chip ROM (ROM key) o en una tarjeta inteligente, de manera que el usuariono tenga más que insertar el dispositivo empleado en alguna ranura a tal efecto paraintroducir su clave.

Otra manera de almacenar claves difíciles de recordar es en forma encriptada mediante unaclave fácil de recordar, como por ejemplo almacenar en disco la clave privada RSA cifradamediante una clave DES.

Tiempo de vida de claves [3]

Una clave nunca debería usarse por tiempo indefinido. Debe tener una fecha de caducidad,por las siguientes razones:

• Cuanto más tiempo se usa una clave, aumenta la probabilidad de que se comprometa(la pérdida de una clave por medios no criptoanalíticos se denomina compromiso).

• Cuanto más tiempo se usa una clave, mayor será el daño si la clave se compromete,ya que toda la información protegida con esa clave queda al descubierto.

• Cuanto más tiempo se usa una clave, mayor será la tentación de alguien paraintentar desbaratarla.

• En general es más fácil realizar criptoanálisis con mucho texto cifrado con la mismaclave.

Para protocolos orientados a conexión, una elección obvia es usar la misma clave de sesióndurante la duración de la comunicación, siendo descartada al finalizar la comunicación ynunca reutilizada. Si la conexión lógica posee una vida muy larga, sería prudente en estecaso cambiar la clave de sesión periódicamente.

Para protocolos no orientados a conexión, no existe un inicio o fin de sesión explícitos. Porlo tanto, no resulta tan obvio con qué frecuencia debería cambiarse la clave. Con el fin de norecargar la información de control ni retrasar la transacción, una estrategia válida sería usaruna clave de sesión durante un cierto período o para un cierto número de transacciones.

Las claves maestras no necesitan ser reemplazadas tan frecuentemente, ya que se usanocasionalmente para el intercambio de claves. En cualquier caso, no hay que olvidar que siuna clave maestra se compromete, la pérdida potencial es enorme, de hecho, todas lascomunicaciones cifradas con claves intercambiadas con esa clave maestra.


Página: 12

En el caso del cifrado de grandes archivos de datos, una solución económica y segura,mejor que andar descifrando y volviendo a cifrar los archivos con una nueva clave todos losdías, sería cifrar cada archivo con una única clave y después cifrar todas las claves con unaclave maestra, que deberá ser almacenada en un lugar de alta seguridad, ya que su pérdida ocompromiso echaría a perder la confidencialidad de todos los archivos.

Destrucción de claves [3]

Las claves caducadas deben ser destruidas con la mayor seguridad, de modo que no caiganen manos de un adversario, puesto que con ellas podría leer los mensajes antiguos. En elcaso de haber sido escritas en papel, éste deberá ser debidamente destruido; si habían sidograbadas en una EEPROM, deberá sobreescribirse múltiples veces, y si se encontraba enEPROM, PROM o tarjeta de banda magnética, deberán ser hechas añicos. En función deldispositivo empleado, deberá buscarse la forma de que se vuelvan irrecuperables.

Referencias

1. “Criptonomicón”, por Gonzalo Alvarez Marañon. Instituto de Física Aplicada delConsejo Superior de Investigaciones Científicas. (Madrid 1998). En Internethttp://www.iec.csic.es/criptonomicon

2. “Privacy on the Web” TIME magazine.

3. "Applied Cryptography", por Bruce Schneier.


Página: 13

CCoorrrreeoo SSeegguurroo

Introducción

No hay nada más fácil que leer los correos de otras personas, ya que viajan desnudos por laRed. Valga la siguiente analogía. Un correo electrónico normal es como una tarjeta postalsin sobre, que puede leer todo el que tenga interés. Por consiguiente, la mejor manera depreservar la intimidad en los mensajes de correo electrónico es recurrir a la criptografía. Pormedio de potentes técnicas criptográficas, el contenido del mensaje puede ser enviadocifrado, permitiendo así que sólo el destinatario legítimo del correo sea capaz de leerlo. Coneste mecanismo se garantiza la confidencialidad del correo. Sin embargo, los modernossistemas de seguridad del correo, como PGP y otros, no se limitan a cifrar el contenido delos mensajes intercambiados, sino que también añaden otros servicios, como la integridad,que garantiza que el contenido del mensaje no ha sido alterado por el camino; laautenticación, que asegura la identidad del remitente del correo, de manera que podemosestar seguros de que fue escrito por quien lo envió y no ha sido falsificado; y el no repudio,que nos protege frente a que posteriormente el que envió el correo (o lo recibió denosotros) alegue posteriormente no haberlo enviado (o recibido si era el destinatario). Estosúltimos servicios se prestan mediante las firmas digitales.

Veamos a continuación muy brevemente cómo funcionan estas técnicas.

Cifrado

El cifrado consiste en transformar un texto en claro (inteligible por todos) mediante unmecanismo de cifrado en un texto cifrado, gracias a una información secreta o clave decifrado. Se distinguen dos métodos generales de cifrado:

Cifrado simétrico

Cuando se emplea la misma clave en las operaciones de cifrado y descifrado, se dice que elcriptosistema es simétrico o de clave secreta. Estos sistemas son mucho más rápidos que losde clave pública, y resultan apropiados para el cifrado de grandes volúmenes de datos.

Ésta es la opción utilizada para cifrar el cuerpo del mensaje. Para ello se emplean algoritmoscomo IDEA, RC5, DES, TRIPLE DES, etc.


Página: 14

Cifrado asimétrico

Por otro lado, cuando se utiliza una pareja de claves para separar los procesos de cifrado ydescifrado, se dice que el criptosistema es asimétrico o de clave pública. Una clave, laprivada, se mantiene secreta, mientras que la segunda clave, la pública, es conocida portodos. De forma general, las claves públicas se utilizan para cifrar y las privadas, paradescifrar. El sistema posee la propiedad de que a partir del conocimiento de la clave públicano es posible determinar la clave privada ni descifrar el texto con ella cifrado. Loscriptosistemas de clave pública, aunque más lentos que los simétricos, resultan adecuadospara los servicios de autenticación, distribución de claves de sesión y firmas digitales, comose explicará posteriormente. Se utilizan los algoritmos de RSA, Diffie-Hellman, etc.

En general, el cifrado asimétrico se emplea para cifrar las claves de sesión utilizadas paracifrar el documento, de modo que puedan ser transmitidas sin peligro a través de la Redjunto con el documento cifrado, para que en recepción éste pueda ser descifrado. La clavede sesión se cifra con la clave pública del destinatario del mensaje, que apareceránormalmente en una libreta de claves públicas.

El cifrado asimétrico se emplea también para firmar documentos y autenticar entidades,como se describe a continuación.


Página: 15

Firma digital

En principio, basta con cifrar un documento con la clave privada para obtener una firmadigital segura, puesto que nadie excepto el poseedor de la clave privada puede hacerlo.Posteriormente, cualquier persona podría descifrarlo con la clave pública, demostrándoseasí la identidad del firmante. En la práctica, debido a que los algoritmos de clave pública sonmuy ineficaces a la hora de cifrar documentos largos, los protocolos de firma digital seimplementan junto con funciones unidireccionales de resumen (hash), de manera que en vezde firmar un documento, se firma un resumen del mismo. Este mecanismo implica el cifrado,mediante la clave privada del emisor, del resumen de los datos, que serán transferidos juntocon el mensaje. Éste se procesa una vez en el receptor, para verificar su integridad. Por lotanto, los pasos del protocolo son:

1. A genera un resumen del documento.

2. A cifra el resumen con su clave privada, firmando por tanto el documento.

3. A envía el documento junto con el resumen firmado a B.

4. B genera un resumen del documento recibido de A, usando la misma funciónunidireccional de resumen. Después descifra con la clave pública de A el resumenfirmado. Si el resumen firmado coincide con el resumen que él ha generado, la firmaes válida.

De esta forma se ofrecen conjuntamente los servicios de no repudio, ya que nadie exceptoA podría haber firmado el documento, y de autenticación, ya que si el documento vienefirmado por A, podemos estar seguros de su identidad, dado que sólo él ha podido firmarlo.En último lugar, mediante la firma digital se garantiza asimismo la integridad deldocumento, ya que en caso de ser modificado, resultaría imposible hacerlo de forma tal quese generase la misma función de resumen que había sido firmada.


Página: 16

Cómo proteger nuestro correo

Lo mejor es instalar un programa de cifrado de correo. Indiscutiblemente, la mejor opciónes el PGP.

En cualquier caso, los clientes más recientes como el Outlook Express de Microsoft yaincorporan herramientas criptográficas para cifrado y firma de correos. Necesitan de unaautoridad de certificación.

Referencias

1. “Criptonomicón”, por Gonzalo Alvarez Marañon. Instituto de Física Aplicada delConsejo Superior de Investigaciones Científicas. (Madrid 1998). En Internethttp://www.iec.csic.es/criptonomicon



4. Pretty Good Privacy, Inc. Home Page – www.pgp.com


Página: 17

WWEEBB SSEEGGUURROO

Introducción

Hay ocasiones en las que se hace necesario recibir/enviar información sensible desde/a unservidor de Web. Veamos algunos ejemplos.

Existen sitios Web con información confidencial sobre becas, datos de personal, nóminas,etc. Resulta evidente que no interesa que esa información sea accesible a toda la Red, sinosólo a un pequeño número autorizado de usuarios, para asegurar la confidencialidad de lainformación. Por lo tanto, no vale con restringir el acceso mediante claves de acceso oprocedimientos similares, además la información que viaja hacia esos usuarios debe ircifrada, para evitar escuchas y permitir la integridad de la información.

En el extremo opuesto, a menudo enviamos a un servidor información confidencial sobrenuestra persona. Nos interesa que el servidor conozca los datos, pero no el resto de la Red,especialmente si estamos realizando una transacción comercial electrónica y revelamosnuestro número de tarjeta de crédito, o simplemente nuestra dirección. Como ya se vio, loque se busca es lograr la confidencialidad. Por otra parte es necesario proveer deautenticación e integridad, como ya se explico anteriormente. (Ver Servicios de seguridad).

En estos dos sencillos ejemplos se pone de manifiesto la necesidad de asegurar mediantealgún mecanismo la intimidad y la integridad en las sesiones con el servidor Web. A decirverdad, resulta imposible garantizar al 100% la seguridad de un sitio, pero cuanto másseguros sean nuestra red y servidores, menos probable será que un pirata intente atacarlosusando ataques pasivos y/o activos.

Secure Socket Layer (SSL)

El protocolo SSL es un sistema diseñado y propuesto por Netscape CommunicationsCorporation. Se encuentra en la pila OSI entre los niveles de TCP/IP y de los protocolosHTTP, FTP, SMTP, etc. Proporciona sus servicios de seguridad cifrando los datosintercambiados entre el servidor y el cliente con un algoritmo de cifrado simétrico,típicamente el RC4 o IDEA, y cifrando la clave de sesión de RC4 o IDEA mediante unalgoritmo de cifrado de clave pública, típicamente el RSA. La clave de sesión es la que seutiliza para cifrar los datos que vienen del y van al servidor seguro. Se genera una clave desesión distinta para cada transacción, lo cual permite que aunque sea descubierta por unatacante en una transacción dada, no sirva para descifrar futuras transacciones. MD5 se usacomo algoritmo de hash.

Proporciona cifrado de datos, autenticación de servidores, integridad de mensajes y,opcionalmente, autenticación de cliente para conexiones TCP/IP.

Cuando el cliente pide al servidor seguro una comunicación segura, el servidor abre un portcifrado (port 443), gestionado por un software llamado Protocolo SSL Record, situadoencima de TCP. Será el software de alto nivel, Protocolo SSL Handshake, quien utilice el


Página: 18

Protocolo SSL Record y el port abierto para comunicarse de forma segura con el cliente. Siel cliente desea tener otra comunicación no segura con el mismo servidor o con otro, lorealizara a través del port tradicional de HTTP (port 80).

Para una descripción mas profunda del protocolo SSL, ver “El Protocolo SSL” masadelante en este mismo trabajo. Aquí solo se hará una breve referencia a los aspectos masimportantes y fundamentales del mismo.

El Protocolo SSL Handshake

Durante el protocolo SSL Handshake, el cliente y el servidor intercambian una serie demensajes para negociar las mejoras de seguridad. Este protocolo sigue, de manera muyresumida, las siguientes seis fases (para mayores detalles ver “El Protocolo SSL” masadelante en este mismo trabajo):

• La fase Hola, usada para ponerse de acuerdo sobre el conjunto de algoritmos paramantener la intimidad y para la autenticación.

• La fase de intercambio de claves, en la que intercambia información sobre lasclaves, de modo que al final ambas partes comparten una clave maestra.

• La fase de producción de clave de sesión, que será la usada para cifrar los datosintercambiados.

• La fase de verificación del servidor, presente sólo cuando se usa RSA comoalgoritmo de intercambio de claves, y sirve para que el cliente autentique al servidor.

• La fase de autenticación del cliente, en la que el servidor solicita al cliente uncertificado X.509 (si es necesaria la autenticación de cliente).

• Por último, la fase de fin, que indica que ya se puede comenzar la sesión segura.

En la figura se ilustra el proceso de handshake:


Página: 19

Ahora que se ha establecido un canal de transmisión seguro SSL, es posible el intercambiode datos. Cuando el servidor o el cliente desea enviar un mensaje al otro, se genera undigest (utilizando un algoritmo de hash de una vía acordado durante el handshake),encriptan el mensaje y el digest y se envía, cada mensaje es verificado utilizando el digest.

Cuando el cliente deja una sesión SSL, generalmente la aplicación presenta un mensajeadvirtiendo que la comunicación no es segura y confirma que el cliente efectivamente deseaabandonar la sesión SSL.

El Protocolo SSL Record

El Protocolo SSL Record especifica la forma de encapsular los datos transmitidos yrecibidos. La porción de datos del protocolo tiene tres componentes:

• MAC-DATA, el código de autenticación del mensaje.

• ACTUAL-DATA, los datos de aplicación a transmitir.

• PADDING-DATA, los datos requeridos para rellenar el mensaje cuando se usacifrado en bloque.


Página: 20

Secure HyperText Transfer Protocol (S-HTTP)

El protocolo S-HTTP fue desarrollado por Enterprise Integration Technologies (EIT). Aligual que SSL, permite tanto el cifrado como la autenticación digital. Sin embargo, adiferencia de SSL, S-HTTP es un protocolo de nivel de aplicación, es decir, que extiende elprotocolo HTTP por debajo.

La propuesta de S-HTTP sugiere una nueva extensión para los documentos, .shttp, y elsiguiente nuevo protocolo:

Secure * Secure-HTTP/1.1

Usando GET, un cliente solicita un documento, le dice al servidor qué tipo de cifrado puedemanejar y le dice también dónde puede encontrar su clave pública. Si el usuario con esaclave está autorizado a acceder al documento, el servidor responde cifrando el documento yenviándoselo al cliente, que usará su clave secreta para descifrarlo y mostrárselo al usuario.

Las negociaciones entre el cliente y el servidor tienen lugar intercambiando datosformateados. Estos datos incluyen una variedad de opciones de seguridad y algoritmos autilizar. Las líneas usadas en los headers incluyen:

• Dominios privados S-HTTP, que especifica la clase de algoritmos de cifrado asícomo la forma de encapsulamiento de los datos. Estos pueden ser: Privacy-Enhanced Mail (PEM) que es un standard que provee intercambio de correoelectrónico seguro. PEM usa técnicas criptográficas para permitir confidencialidad(DES), autenticación (Certificados), e integridad del mensaje (RSA-MD2 y RSA-MD5). Otro muy usado es Public-Key Cryptography Standards (PKCS-7) queespecifica el formato general de un mensaje criptográfico. Este standard describe lasintaxis general de los datos a los que se le pueden aplicar técnicas criptográficas,como firmas digitales. La sintaxis admite recursión. También admite atributosarbitrarios, como hora de la firma, para ser autenticados junto con el mensaje. Estestandard es compatible con PEM ya que los datos firmados construidos en un modoPEM compatible pueden ser convertidos en mensajes PEM sin operacionescriptográficas.

• Tipos de certificado S-HTTP, que especifica el formato de certificado aceptable,actualmente X.509.

• Algoritmos de intercambio de clave S-HTTP, que indica los algoritmos que seusarán para el intercambio de claves (RSA, fuera de bando, dentro de banda y Krb).

• Algoritmos de firmas S-HTTP, que especifica el algoritmo para la firma digital(RSA o NIST-DSS).

• Algoritmos de resumen de mensaje S-HTTP, que identifica el algoritmo paraproporcionar la integridad de los datos usando funciones de hash (RSA-MD2, RSA-MD5 o NIST-SHS).

• Algoritmos de contenido simétrico S-HTTP, que especifica el algoritmo simétricode cifrado en bloque usado para cifrar los datos:

• DES-CBC


Página: 21

• DES-EDE-CBC

• DES-EDE3-CBC

• DESX-CBC

• IDEA-CFB

• RC2-CBC

• RC4

• CDMF

• Algoritmos de cabecera simétrica de S-HTTP, que proporciona una lista del cifradode clave simétrica utilizada para cifrar las cabeceras.

• DES-ECB

• DES-EDE-ECB

• DES-EDE3-ECB

• DESX-ECB

• IDEA-ECB

• RC2-ECB

• CDMF-ECB

• Mejoras de la intimidad de S-HTTP, que especifica las mejoras en la intimidadasociadas con los mensajes, como firmar, cifrar o autenticar.

Uno de los métodos de cifrado disponible en S-HTTP es el popular PGP (Ver Ref. 1).

SSL vs. S-HTTP

S-HTTP y SSL utilizan aproximaciones distintas con el fin de proporcionar servicios deseguridad a los usuarios de la Red. SSL ejecuta un protocolo de negociación para estableceruna conexión segura a nivel de socket (nombre de máquina más port). Los servicios deseguridad de SSL son transparentes al usuario y a la aplicación. Cuando se comienza unaconexión SSL el cliente envía los cifradores que soporta y el servidor elige aquel que proveala mayor seguridad y que este soportado por él.

Por su parte, los protocolos S-HTTP están integrados con HTTP. Aquí, los servicios deseguridad se negocian a través de los headers y atributos de la página. Por lo tanto, losservicios de S-HTTP están disponibles sólo para las conexiones de HTTP.

Dado que SSL se integra en la capa de sockets, también permite ser usado por otrosprotocolos además del HTTP, mientras que el S-HTTP está concebido para ser usadoexclusivamente en comunicaciones HTTP.

Otra diferencia entre estos protocolos es que SSL utiliza un port especial (443) mientrasque S-HTTP sigue utilizando el port de HTTP (80).


Página: 22

Un usuario puede saber si un sitio es seguro, y que protocolo de seguridad esta utilizando,mirando en el comienzo de la URL. Un pedido común comenzaría con el "http://" que todoslos navegadores entienden. En un esquema SSL, un pedido que utiliza SSL se identifica con"https://", y en S-HTTP con "shttp://".

Autoridades de Certificación: cómo estar seguro de un servidorseguro

Aunque nuestros datos viajen cifrados por la Red, si los estamos enviando a (los recibimosde) un impostor, no saldremos mucho mejor parados. Se hace imprescindible el contar conun mecanismo que dé fe de si un servidor seguro es quien creemos que es y podemosconfiar en él a la hora de transmitirle nuestra información. La forma como se hace esmediante las Autoridades de Certificación (AC), conocidas informalmente como escribanoselectrónicos, encargadas de autenticar a los participantes en transacciones y comunicacionesa través de la Red. Su función es emitir certificados a los usuarios, de manera que se puedaestar seguro de que el interlocutor (cliente o servidor) es quien pretende ser, garantizandoasí la seguridad de las transacciones.

El certificado de seguridad se concede a una entidad después de comprobar una serie dereferencias, para asegurar la identidad del receptor de los datos cifrados. Se construye apartir de la clave pública del servidor solicitante, junto con algunos datos básicos del mismoy es firmado por la autoridad de certificación correspondiente con su clave privada.

En la práctica, sabremos que el servidor es seguro porque en nuestro navegador veremosuna llave o un candado cerrado en la parte izquierda, si usamos Netscape, o bien uncandado cerrado en la parte derecha, si usamos el Explorer.

Advertencia: Una llave entera o un candado cerrado no garantizan una comunicaciónsegura. Es necesario comprobar el certificado.

Otro cambio importante es el identificador de protocolo en la URL, que varía ligeramente:ya no empieza con http, sino con https (usando SSL) y con shttp si se utiliza S-HTTP.

Referencias

1. “Criptonomicón”, por Gonzalo Alvarez Marañon. Instituto de Física Aplicada delConsejo Superior de Investigaciones Científicas. (Madrid 1998)




Página: 23

CCOOMMEERRCCIIOO EELLEECCTTRRÓÓNNIICCOO SSEEGGUURROO

Introducción

Son ya notables los cambios que se han producido en la nueva Era de la Información. Unode los mayores impactos de la Tecnología de la Información se verifica en el comercio y losservicios financieros. En efecto, el comercio electrónico ha modificado los hábitos de lasfinanzas, y ahora, el de los comerciantes y consumidores, a la vez que produce cambiossustanciales en los medios de pago tradicionales.

El tema de la seguridad merece especial atención: es un elemento clave en este tipo detransacciones en tanto el medio por donde transita la información es, en principio, inseguro.

Se analizan los cambios que se observan en el comercio y banca electrónicos, y en especial,la infraestructura desarrollada en los Estados Unidos para permitir el funcionamiento de lafirma digital, utilizada en la actualidad para otorgar seguridad a las transaccionescomerciales electrónicas y a la transferencia electrónica de datos.

Características del comercio electrónico [1]

Finanzas - perspectivas

En “Banca, Comercio, Moneda Electronica y la Firma Digital” Maurico Devoto y HoracioLynch dicen:

”Antes de avanzar e introducirnos en el análisis de los sistemas de pago, no podemos dejarde destacar la importancia que su implementación y desarrollo puede tener para la Bancatradicional. Miles de millones de dólares se encuentran en danza y a la espera de seraprovechados por los que primero o de mejor manera sepan advertir y manejar la situación.Si los bancos asumen una fuerte intervención en los pagos realizados a través de Internet,como lo hacen en los pagos tradicionales, pueden ganar mucho dinero transfiriendo fondosy emitiendo credenciales a consumidores y comerciantes. Por otro lado, si empresas de otrotipo advierten la lentitud con la que los bancos se mueven y organizan sus propios sistemasde pagos on line (en línea), serán ellas las que consigan los beneficios. “

Comercio electrónico: Transacciones entre desconocidos

Existen dos polos bien marcados dentro del espectro de las transacciones que tienen lugaren un sistema económico: por un lado, nos encontramos con transacciones en las que laspartes se conocen mutuamente; por el otro, transacciones que se realizan entredesconocidos. En las primeras, los costos de la transacción generalmente son bajos; en lassegundas, los costos son marcadamente más elevados. El comercio electrónico puede darsede diversas formas, mediante sistemas financieros, EDI (Electronic Data Interchange),servicios on line. Una de las formas donde tiende a intensificarse es a través de Internet.Mientras la popularidad de Internet sigue creciendo a pasos agigantados, muchas empresas


Página: 24

ya sienten la necesidad de sumergirse en esta nueva modalidad de comercio. Sin embargo,Internet continúa siendo un mundo sin reglas, un mercado en el que el comercio no puedeflorecer tranquilamente por carecer de normas que lo protejan. Para el funcionamiento delcomercio electrónico, fundamentalmente en Internet, hacen falta entonces tres requisitos.En primer lugar, se necesitan reglas relacionadas con la propiedad, a efectos de identificarlos objetos del intercambio. En segundo lugar, es indispensable un sistema de pago seguro,y finalmente, algún mecanismo que permita castigar las transgresiones a dichas reglas. Eneste trabajo analizaremos los dos primeros, especialmente el de la seguridad.

Limitaciones del comercio electrónico relacionadas con la propiedad

El comercio electrónico en general, e Internet en especial, fue ideado para el intercambio deinformación. Sin embargo, en la actualidad se los utiliza en gran medida para transaccionesque requieren el posterior transporte de la mercadería objeto de la transacción. En estecaso, Internet es una simple alternativa comparable al teléfono, que no agrega nada nuevo alcomercio. La tecnología base del comercio electrónico es solamente una parte de lastransacciones. La compra electrónica será la comercializadora inevitable de la Internet, perolos que la defienden fervorosamente deberían tener en cuenta que los hábitos de losconsumidores son difíciles de romper, ya que generalmente les gusta elegir y tocar lamercadería. Es razonable suponer que el comercio electrónico tendrá limitaciones evidentessi se lo compara con las formas tradicionales de compra de los consumidores actuales. Alrealizar una compra de mercadería o servicios en general, intervienen distintos factores:educación, interacción social, suerte para encontrar ofertas y posibilidad de probar lo que sequiere comprar. La compra electrónica no puede duplicar fácilmente estas experiencias. Siesto es así, conviene concentrarse en las excepciones, en aquellas situaciones en que no senecesita elegir o tocar la mercadería. Esto nos sugiere campos tales como: comercio sobredinero (finanzas); comercio sobre títulos y commodities (bolsa) y, fundamentalmente, elcomercio sobre información electrónica. Este último tendrá mucho futuro porque, enverdad, es el medio más apropiado para elegir, probar, sentir, enviar, y embalar losproductos electrónicos.

Áreas aptas para el comercio electrónico

La conclusión precedente indica que la verdadera promesa de Internet radica en la venta deinformación. El software, por ejemplo, que es en esencia pura información, es generalmentetransferido a un medio físico (el disquete), empacado, transportado y vendido en negocios.Esta cadena encarece enormemente el costo de la información. Mucho más barato yeficiente es adquirir esa información vía Internet y recibirla directamente en el lugar, entornoy destino natural: la computadora del comprador


Página: 25

Sistemas basados en tarjetas de crédito

SET [1],[2]

Secure Electronic Transactions (SET) es un conjunto de especificaciones desarrolladas porVISA y MasterCard, con el apoyo y asistencia de GTE, IBM, Microsoft, Netscape, SAIC,Terisa y Verisign, que permitirán el desarrollo del comercio electrónico en el seno deInternet y otras redes públicas, de forma segura para todos los participantes: usuario final,comerciante, entidades financieras, administradoras de tarjetas y propietarios de marcas detarjetas. Esta tecnología intenta superar cinco grandes desafíos:

• garantizar reserva en la información de pedidos y pagos., que se logra por laencriptación de los mensajes

• asegurar la integridad de todos los datos transmitidos, a través de la firma digital

• verificar que el titular de la tarjeta de crédito sea usuario legítimo de una cuenta,mediante la utilización de la firma digital y los certificados

• garantizar la autenticidad del comerciante para que pueda aceptar pagos con tarjetasbancarias a través de una institución financiera, mediante la firma digital y loscertificados

• facilitar y alentar la interoperatividad entre proveedores de redes y de software.

Los algoritmos criptográficos empleados en SET para los procesos de encriptación, emisiónde certificados y generación de firmas digitales son de doble naturaleza. Por un lado, sedefine un algoritmo de clave privada, de fortaleza contrastada y excelente rendimiento:DES (Data Encryption Standard), en uso desde 1977. Por otro lado, se hace imprescindiblecontar con un algoritmo que permita el intercambio de claves en una red pública, con totalseguridad, entre múltiples participantes sin ninguna relación previa; un algoritmo como eldescrito se define de clave pública, y el escogido para SET fue RSA.

SET define un tipo de certificados para los tres intervinientes en las transaccionescomerciales:

• el comprador (cardholder)

• el comerciante (merchant)

• la pasarela de pagos (payment gateway)

Separa la información de compra y la información de pago.

El comprador obtiene sus certificados de la entidad financiera que emite las tarjetas con lasque opera para realizar las transacciones de comercio electrónico. Para todos los efectos,una vez que la entidad financiera ha identificado debidamente al comprador potencial, loscertificados sustituyen, funcionalmente, a las tarjetas.

El comerciante obtiene sus certificados de la entidad financiera con la que firma contratosde adhesión para la aceptación de las diferentes tarjetas de crédito y débito emitidas pordicha entidad en nombre del propietario de la marca. Estos certificados sustituyenfuncionalmente a las calcomanías que exhiben actualmente las vidrieras de los comercios, y


Página: 26

que permiten identificar la existencia de una relación comercial con una entidad financieraque les permitirá aceptar pagos con diferentes marcas y tipos de tarjetas. Evidentemente, uncomerciante podrá disponer de más de un par de certificados, y tendrá tantos como marcasde tarjetas esté aceptando como medio de pago.

FV

La operación se realiza con la intervención de una tercera parte a quien previamente se le haenviado fuera de línea (off line) el número de tarjeta de crédito. Un ejemplo es THE FIRSTVIRTUAL INTERNET PAYMENT SYSTEM (FV) [3]. Para asociarse, se necesita unadirección de E-mail, dado que toda comunicación entre el usuario y FV se realizará a travésde ese medio, incluida la confirmación de la compra que deberá realizar el usuario y laautorización a FV para cargarla a su tarjeta de crédito. El sistema funcionaaproximadamente de esta forma: luego de llenar la aplicación se activa la cuenta enviandotelefónicamente a FV los datos de la tarjeta. FV confirma la apertura enviando un mensajevía E-mail conteniendo el Virtual PIN. Para realizar una compra, el usuario da el VPIN alvendedor, quien se comunica con FV. FV envía al comprador un E-mail para que confirmela operación. El costo de tener un VPIN es de U$S 2. Lamentablemente ninguna de lasgrandes compañías esta impulsando este sistema. Es un emprendimiento de una empresallamada First Virtual.

Cheques digitales

Este segundo sistema funciona como si se tratara de cheques reales, salvo que el usuarioutiliza una firma digital para firmar el cheque y luego transmitirlo en línea (on line)encriptado. Como ejemplo de empresas proveedoras de este servicio se puede citar aCHECK FREE [4] y NetCheque [5]

El usuario necesita una chequera electrónica, que actualmente consiste en una tarjeta deltamaño de una tarjeta de crédito que puede contener datos y se inserta en un slot en lamayoría de las computadoras portátiles (notebooks) que se venden en la actualidad. En elfuturo la chequera se llevará en una tarjeta inteligente (smart card), que cuenta con un chipy distintos tipos de memoria, que le permitirá generar cheques, llevar su registro de chequesy guardar claves públicas y privadas. Los pequeños comerciantes necesitarán una tarjeta dePC (PC card), mientras que los demás comerciantes tendrán que incluir un procesadorespecial en sus servidores. Los mensajes transmitidos entre clientes, comerciantes y bancoscontarán con la seguridad y confidencialidad que brinda la criptografía de clave pública y lafirma digital, que más adelante analizaremos. Las encuestas realizadas informan que siguesiendo importante el hecho de que el dinero no se ha debitado inmediatamente de lascuentas corrientes. Actualmente los débitos se realizan entre las 24 y 36 horas.

Electronic Money

La mayor parte de los productos ofrecidos en el mercado se encuentran implementados conun soporte en tarjeta (card-based) o en un software especial (software-based).


Página: 27

Los primeros proveen al consumidor una tarjeta denominada smart card. Esta tarjetainteligente consta de un chip que contiene un sistema operativo y aplicaciones de softwareque son insertados en la tarjeta en el proceso de su manufactura. La emisión de las tarjetas alos consumidores se realiza de diferentes formas: en algunos casos, la tarjeta involucra unacuenta bancaria perteneciente al usuario; alternativamente, las tarjetas pueden ser adquiridasanónimamente en máquinas expendedoras o mediante la utilización de tarjetas de crédito odébito. La institución emisora u operadora central del sistema provee a los comerciantes determinales u otros dispositivos que permiten realizar la operación. La carga de los valoresen las tarjetas se realiza generalmente a través de un cajero automático (ATM - AutomaticTeller Machine) o de un teléfono equipado especialmente.

En general, como expresamos anteriormente, de estas transacciones resulta un débito en lacuenta bancaria preexistente del consumidor que está ligada a la tarjeta. Para realizar unacompra, el usuario introduce su tarjeta en la terminal del vendedor e ingresa la suma apagar. La terminal verifica que el balance que surge de la tarjeta permita realizar latransacción e instruye para que debite la suma correspondiente al pago. Luego la tarjetainstruye a la terminal del vendedor para que incremente su balance en la misma suma. Porotro lado, los sistemas basados en software funcionan por medio de un programa instaladoen la computadora del usuario. Están diseñados para realizar pagos a través de redes,fundamentalmente Internet. El proceso de carga se realiza por el intercambio de mensajesentre los dispositivos del usuario y del emisor, mensajes que son trasmitidos por la red. Enla práctica, se tiende a involucrar, por razones de seguridad, la emisión de documentos ocheques firmados digitalmente.

El proceso de pago depende del diseño del producto de que se trate, así como del contextoen el que el pago se realiza. La determinación de la cantidad y características de lasentidades emisoras, cuyas obligaciones son electrónicamente transmitidas en un sistema dedinero electrónico, son críticas desde un punto de vista financiero, y afectan asimismo laimplementación técnica de dicho sistema. Los sistemas que se basan en un solo emisorpueden no necesitar un clearing de las transacciones realizadas, siempre y cuando otrainstitución no participe colectando o distribuyendo fondos. En sistemas con múltiplesemisores, el número de tarjeta o un certificado emitido por una autoridad certificante dentrode una infraestructura de firma digital, identifica al usuario, y las transacciones comercialesy demás operaciones son trasmitidas al ente emisor para su registro. Este registro puedeservir tanto para fines de clearing financiero como para brindar seguridad al sistema.

Entre otros, han desarrollado sistemas de dinero digital: DIGICASH [6], CYBERCASH [7]y MONDEX [8].

Referencias

1. "Banca, comercio, moneda electrónica y firma digital”. Estudio de Mauricio Devoto yHoracio M. Lynch originalmente publicado en la Revista Jurídica LA LEY, 21 de abrilde 1997.

2. “Criptonomicón”, por Gonzalo Alvarez Marañon. Instituto de Física Aplicada delConsejo Superior de Investigaciones Científicas. (Madrid 1998)


Página: 28

3. En Internet: http://www.fv.com/info/intro.html.

4. En Internet: http://www.checkfree.com/

5. En Internet: http://nii-server.isi.edu/info/NetCheque/

6. En Internet: http://www.digicash.com/....

7. En Internet: http://www.cybercash.com/

8. En Internet: http:www.co.uk/mondex.html


Página: 29

EEll PPrroottooccoolloo SSSSLL

Introducción

El Protocolo Secure Sockets Layer (SSL) es un protocolo de seguridad que proveeprivacidad en Internet. El protocolo permite a las aplicaciones cliente/servidor comunicarseen una manera que no pueda ser violada. El servidor siempre es autenticado y los clientespueden serlo ó no.

El protocolo SSL es un sistema diseñado y propuesto por Netscape CommunicationsCorporation. Se encuentra en la pila OSI entre los niveles de TCP/IP y de los protocolosHTTP, FTP, SMTP, etc. Proporciona sus servicios de seguridad cifrando los datosintercambiados entre el servidor y el cliente con un algoritmo de cifrado simétrico,típicamente el RC4 o IDEA, y cifrando la clave de sesión de RC4 o IDEA mediante unalgoritmo de cifrado de clave pública, típicamente el RSA. La clave de sesión es la que seutiliza para cifrar los datos que vienen y van al servidor seguro. Se genera una clave desesión distinta para cada transacción, lo cual permite que aunque sea descubierta por unatacante en una transacción dada, no sirva para descifrar futuras transacciones. MD5 se usacomo algoritmo de hash.

Proporciona cifrado de datos, autenticación de servidores, integridad de mensajes y,opcionalmente, autenticación de cliente para conexiones TCP/IP.

El protocolo está diseñado para soportar un rango de elecciones para algoritmos específicosusados para criptografía, resúmenes y firmas. Esto permite selección de algoritmos paraservicios específicos que pueden estar basados en intereses legales, de exportación o otros,y le permite al protocolo tomar ventaja de los nuevos algoritmos. Las elecciones sonnegociadas entre el cliente y el servidor al comienzo de la sesión.

Motivación

El protocolo está diseñado para proveer privacidad entre dos aplicaciones que se comunican(un esquema cliente servidor). Segundo, el protocolo está diseñado para autenticar elservidor y opcionalmente al cliente. El SSL requiere un protocolo confiable de transporte(ej. TCP) para la transmisión y recepción de los datos.

La ventaja del Protocolo SSL es que es un protocolo de aplicación independiente delprotocolo de comunicaciones. Un protocolo de aplicación de “alto nivel” (HTTP, FTP,TELNET, etc.) puede correr por encima de SSL transparentemente. El Protocolo SSL seencarga de negociar el algoritmo de encriptación y la clave de la sesión en formatransparente. El SSL puede negociar el algoritmo de encriptación y autenticar el servidorantes de que el protocolo de transmisión reciba o envíe datos. Todos los datos delprotocolo de la aplicación son transmitidos en forma encriptada para asegurar la privacidad.

El Protocolo SSL provee "un canal seguro" el cual tiene 3 propiedades básicas:


Página: 30

• El canal es privado. La encriptación se usa para todos los mensajes una vez que seestableció la clave secreta.

• El canal es autenticado. El lado del servidor de la conversación siempre es autenticado,mientas que el cliente se autentica opcionalmente.

• El canal es confiable. El transporte del mensaje incluye un chequeo de seguridad usandoel MAC.

Hay varias versiones del protocolo SSL como se ve en esta tabla:

Versión Origen Descripción Browser

SSL 2.0 Publicada porNetscape

Protocolo original Netscape 3.0, InternetExplorer 3.0

SSL 3.0 Expired InternetDraft

Revisiones para prevenirataques de seguridadespecíficos, se agregaroncifradores y cadenas decertificados

Netscape 3.0, InternetExplorer 3.0

TLS 2.0 Internet EngineeringTask Force (IETF)

Revisión de SSL 3.0

Cuando el cliente pide al servidor seguro una comunicación segura, el servidor abre un portcifrado, gestionado por un software llamado Protocolo SSL Record, situado encima deTCP. Será el software de alto nivel, Protocolo SSL Handshake, quien utilice el ProtocoloSSL Record y el port abierto para comunicarse de forma segura con el cliente.

Establecimiento de la sesión

La sesión SSL se establece mediante el intercambio entre el cliente y el servidor de una seriede mensajes para negociar las mejoras de seguridad (ver figura). Esta secuencia puedevariar, según si el servidor está configurado para proveer un certificado de servidor orequerir un certificado de cliente.

Una vez que se estableció la sesión SSL puede ser usada nuevamente, evitando la perdidade rendimiento de repetir los distintos pasos necesarios para comenzar la sesión.

Los elementos de la secuencia de handshake, usados por el cliente y le servidor son:

• Negociar el conjunto de cifradores (Cipher Suite) a usar durante la transferencia dedatos.

• Establecer y compartir una clave de sesión entre cliente y servidor.

• Opcionalmente autenticar el servidor para el cliente.

• Opcionalmente autenticar el cliente para el servidor.


Página: 31

El primer paso es la negociación del conjunto de cifradores (Cipher Suite Negotiation), quepermite al cliente y al servidor elegir los cifradores soportados por ambos. La especificacióndel protocolo SSL 3.0 define 31 conjuntos de cifradores. Un conjunto de cifradores estádefinida por:

• Método de intercambio de claves.

• Cifrado para transferencia de datos.

• Resumen del mensaje para crear el código de autenticación del mensaje (MAC).

Método de intercambio de claves

Este método define como se ponen de acuerdo el cliente y el servidor para intercambiar laclave simétrica compartida secreta usada para transferencia de los datos de la aplicación.

SSL 2.0 usa RSA, mientras que SSL 3.0 soporta algoritmos que incluyen intercambio RSAcon certificados y Diffie-Hellman sin certificados y sin comunicación previa entre el clientey el servidor.

Una variable en la elección de los métodos de intercambio de clave es la firma digital, si seusa o no, y si se usa, de que tipo. Firmar con una clave privada provee seguridad contraataques del tipo hombre en el medio durante el intercambio de información usado al generarla clave compartida.

Cifrado para transferencia de datos

SSL usa algoritmos convencionales de criptografía simétrica. Existen nueve opciones:

• No encriptar.

• Cifrados Stream.

• RC4 con claves de 40 bits.


Página: 32


• Cifrados de bloque CBC.


• DES40, DES, 3DES_EDE.

• Idea.

• Fortezza.

CBC significa Cipher Block Chaining, que significa que una porción del texto previamenteencriptado se usa para encriptar el bloque actual. DES es el Data Encryption Standard, queposee variantes como DES40 y 3DES_EDE. Idea es uno de los mejores y más segurosalgoritmos actuales, y RC2 es un algoritmo propietario de RSA.

Función de resumen

La elección de la función de resumen determina como un resumen se crea del registroactual. SSL soporta los siguientes:

• Sin resumen (NULL)

• MD5, un hash de 128 bits.

• SHA, Secure Hash Algorithm, un hash de 160 bits diseñado para el uso con el DSS(Digital Signature Standard).

El resumen de mensaje se usa para crear el código de autenticación de mensaje (MAC), quese encripta con el mensaje para prevenir ataques tipo replay.

El Protocolo SSL Handshake

La secuencia handshake usa tres protocolos:

• "SSL Handshake Protocol", para establecer la sesión SSL entre el cliente y el servidor.

• "SSL Change Cipher Spec protocol", para acordar el conjunto de cifradores de lasesión.

• "SSL Alert Protocol", para acordar mensajes de error entre el cliente y el servidor.

Estos protocolos, y los datos del protocolo de aplicación, son encapsulados en el "SSLRecord Protocol", como se ve en la figura.


Página: 33

Un protocolo encapsulado se transfiere como datos al protocolo inferior, que no examinalos datos, por lo que no tiene conocimiento del protocolo superior.

La encapsulación de los protocolos de control por el protocolo de registro significa que sise vuelve a negociar una sesión activa, el protocolo de control será transmitido en formasegura. Si no hubo sesión antes, se usa el cifrado NULL, que no encripta los mensajes y nogenera resúmenes de integridad hasta que no se establezca la sesión.

Transferencia de datos

El SSL Record Protocol, mostrado en la figura, se usa para transferir datos de la aplicacióny de control de SSL entre cliente y servidor, posiblemente fragmentando estos datos enunidades más pequeñas, o combinando múltiples mensajes de protocolos superiores enunidades simples. Estos pueden comprimir, agregar firmas o encriptar estas unidades antesde transmitirlos usando los protocolos de transporte.


Página: 34

Comunicaciones HTTP Web seguras

Uno de los usos más comunes de SSL es asegurar comunicaciones Web entre un browsercliente y un servidor Web. La versión segura usa URLs que comienzan con HTTPS en vezde HTTP, y un port diferente de servidor (por defecto 443). El browser mantendrá clavesprivadas certificadas del cliente cuando se generan, y mostrará un indicador de que se estáusando una comunicación segura.

Especificación del SSL Record Protocol

Formato del Header del SSL Record

En SSL, todos los datos enviados se encapsulan en un registro, un objeto compuesto de unencabezado (header) y una cantidad de datos distinta de cero. Cada encabezado contiene uncódigo de dos o tres bytes. Si el bit más significativo esta en “1”en el primer byte del códigodel largo del registro, entonces el registro no posee padding y el largo total del encabezadoserá de 2 bytes, de lo contrario el registro posee padding y el largo total del encabezadoserá de 3 bytes. El encabezado del registro se transmite antes que la parte del registro condatos.

En el caso del encabezado largo (3 bytes), el segundo bit más significativo en el primer bytetiene un significado especial. Cuando es “0”, el registro que se esta enviando es un registrode datos. Cuando es “1”, el registro que se esta enviando es un “security escape”(actualmente no hay ejemplos de “security escapes”; esto esta reservado para futurasversiones del protocolo). En ambos casos, el código de largo describe la cantidad de datosque hay en el registro.

El código de largo del registro no incluye la cantidad de bytes ocupados por el encabezadodel registro (2 o 3). En lo que sigue se utilizara una notación estilo “C” donde MSBsignifica byte más significativo, LSB es el byte más significativo y << 2 es un corrimientohacia la izquierda. Para el encabezado de 2 bytes, el largo del registro se calcula de lasiguiente forma:

RECORD-LENGTH = ((byte[0] & 0x7f) << 8)) | byte[1];

Donde byte[0] representa el primer byte recibido y byte[1] el segundo byte recibido.Cuando se usa el encabezado de 3 bytes, el largo del registro se calcula como:

RECORD-LENGTH = ((byte[0] & 0x3f) << 8)) | byte[1];

IS-ESCAPE = (byte[0] & 0x40) != 0;

PADDING = byte[2];

El encabezado del registro define un valor llamado PADDING. El valor de PADDING especificala cantidad de datos que el lado que envía el mensaje le agrego al mensaje original. El


Página: 35

padding se usa para que el largo del registro sea un múltiplo del tamaño del bloque delcifrador cuando se usa un cifrador por bloques para encriptar.

El que envía un registro con padding le agrega los datos de padding al final del mensaje yluego encripta el mensaje total (que ahora es un múltiplo del tamaño del bloque delcifrador). El valor actual de los datos de padding no es importante, pero el valor encriptadode él debe enviarse al receptor para poder desencriptar el registro. Una vez se conoce lacantidad total a transmitir, el encabezado puede ser construido con el valor de PADDINGfijado apropiadamente.

El receptor de un registro con padding desencripta el registro entero para obtener elmensaje de datos, luego resta el valor de PADDING del valor de RECORD-LENGTH paradeterminar el valor final de RECORD-LENGTH

Formato de los Datos del Registro SSL

La parte de datos de un registro SSL esta compuesta de tres componentes (transmitido yrecibido en el orden mostrado):

MAC-DATA[MAC-SIZE]

ACTUAL-DATA[N]

PADDING-DATA[PADDING]

ACTUAL-DATA es el mensaje que se esta transmitiendo. PADDING-DATA es la información depadding que se envía cuando se usa un cifrador de bloque y se necesita padding. Finalmente,MAC-DATA es el Message Authentication Code.

Cuando se envían registros SSL no cifrados, no se usa cifrador. Por lo tanto la cantidad dePADDING-DATA será cero y el valor de MAC-DATA será cero. Cuando se activa laencriptación, el valor de PADDING-DATA será una función del tamaño del bloque delcifrador. El valor de MAC-DATA es una función de CIPHER-CHOICE.

El valor de MAC-DATA se calcula de la siguiente forma:

MAC-DATA = HASH[ SECRET, ACTUAL-DATA, PADDING-DATA, SEQUENCE-NUMBER ]

Donde el valor de SECRET se le proporciona primero a la función de hash, seguido porACTUAL-DAT, al que le sigue PADDING-DATA, y finalmente se ingresa SEQUENCE-NUMBER.SEQUENCE-NUMBER es un numero de 32 bits que se le ingresan a la función de hash comocuatro bytes, siendo el primer byte el byte mas significativo del numero de secuencia, elsegundo byte el próximo byte mas significativo y así hasta el cuarto byte (esto es, ennetwork byte order o “big endian order”).

MAC-SIZE es una función del algoritmo usado. Para MD2 y MD5 el valor de MAC-SIZE seráde 16 bytes (128 bits).

El valor de SECRET es una función del lado que envía el mensaje. Si el cliente esta enviandoel mensaje entonces SECRET es CLIENT-WRITE-KEY (el servidor usará SERVER-READ-KEYpara verificar el MAC). Si el cliente esta recibiendo el mensaje entonces SECRET es CLIENT-READ-KEY (el servidor usará SERVER-WRITE-KEY para generar el MAC).


Página: 36

El SEQUENCE-NUMBER es un contador que es incrementado por el que envía y por que el querecibe. Por cada sentido de transmisión, se mantienen un par de contadores (uno por el queenvía y otro por el que recibe). Cada vez que se envía un mensaje se incrementa el contador.Los números de secuencia son números de 32 bit sin signo y vuelven a cero después depasar por 0xFFFFFFFF.

El receptor de un mensaje usa el valor esperado del numero de secuencia como entrada a lafunción de HASH del MAC (la función de HASH se elige del valor de CIPHER-CHOICE). Elvalor calculado de MAC-DATA debe coincidir bit a bit con el MAC-DATA transmitido. Si lacomparación no es idéntica entonces se considera dañado al registro, y se lo trata como sise hubiese producido un error de entrada/salida.

Se realiza una verificación de consistencia final cuando se usa un cifrador por bloque y elprotocolo esta utilizando encriptación. La cantidad total de información presente en unregistro (RECORD-LENGTH) debe ser un múltiplo del tamaño del bloque del cifrador. Si elregistro recibido no es un múltiplo del tamaño del bloque del cifrador entonces se consideraque el registro esta dañado, y se lo trata como si se hubiese producido un error deentrada/salida.

El Registro SSL se usa para todas las comunicaciones SSL, incluyendo los mensajes dehandshake, “security escapes” y transferencias de datos de aplicaciones. El Registro SSL seusa tanto por el cliente como por el servidor en todo momento.

Para el encabezado de dos bytes, el largo máximo del registro es 32767 bytes. Para el detres bytes, el largo máximo es de 16383 bytes. Los mensajes de handshake deben caber enun solo Registro SSL. Los mensajes de aplicaciones pueden ocupar varios Registros SSL.

Antes de enviar el primer registro usando SSL deben inicializarse todos los números desecuencia a cero. El número de secuencia transmitido se incrementa después de cadamensaje enviado, comenzando con los mensajes CLIENT-HELLO y SERVER-HELLO.

Especificación del SSL Handshake Protocol

Flujo del SSL Handshake Protocol

El SSL Handshake Protocol tiene dos fases principales. La primer fase se usa paraestablecer comunicaciones privadas. La segunda fase se utiliza para la autenticación de losclientes.

Fase 1

La primer parte es la fase de la conexión inicial donde ambas partes envían susmensajes de "hello". El cliente inicia la conversación enviando el mensaje CLIENT-HELLO. El servidor recibe el mensaje CLIENT-HELLO y lo procesa respondiendo conel mensaje SERVER-HELLO.

En este punto tanto el cliente como el servidor poseen suficiente información parasaber si necesitan una clave maestra nueva. Cuando no se necesita una clave maestranueva, tanto el cliente como el servidor siguen con la Fase 2.


Página: 37

Cuando se necesita una clave maestra nueva, el mensaje SERVER-HELLO poseesuficiente información como para que el cliente pueda generarla. Esto incluye elcertificado del servidor firmado, una lista de especificaciones del cifrador, y unconnection-id (un connection-id es un numero generado al azar por el servidor y queusan el cliente y el servidor durante una conexión). El cliente genera la clave maestray responde con un mensaje CLIENT-MASTER-KEY (o un mensaje ERROR si lainformación del servidor indica que el cliente y el servidor no pueden ponerse deacuerdo en el tipo de cifrador).

Cada lado usa un par de cifradores por conexión (lo que da un total de cuatrocifradores). En cada lado, un cifrador se usa por las comunicaciones salientes, y otrose usa para las comunicaciones entrantes. Cuando el cliente o servidor genera unaclave de sesión, en realidad generan dos claves, la SERVER-READ-KEY (tambiénconocida como CLIENT-WRITE-KEY) y la SERVER-WRITE-KEY (también conocidacomo CLIENT-READ-KEY). La clave maestra la usa el cliente y el servidor paragenerar las claves de sesión.

Finalmente, el servidor envía un mensaje de SERVER-VERIFY al cliente una vez quese determino la clave maestra. Este paso autentica al servidor, ya que solo unservidor que tenga la clave publica apropiada puede saber la clave maestra.

Fase 2

La segunda parte es la fase de autenticación. El servidor fue autenticado por elcliente en la primer fase, por lo que esta fase se usa básicamente para autenticar alcliente. En una situación típica, el servidor necesitará algo del cliente y enviará unpedido. El cliente responderá si tiene la información, o enviara un mensaje de ERRORde lo contrario. Esta especificación del protocolo no define la semántica de unarespuesta ERROR a un pedido del servidor (una implementación puede ignorar elerror, cerrar la conexión, etc. y aun respetar la especificación).

Cuando un lado termina de autenticar al otro, envía su mensaje de finalizado. Para elcliente el mensaje CLIENT-FINISHED contiene el CONNECTION-ID. Si la verificaciónfalla, el servidor envía un mensaje de ERROR.

Una vez que un lado envío su mensaje de finalización debe continuar escuchando losmensajes de su par hasta que este también reciba un mensaje de finalización. Cuandoun lado ha enviado un mensaje de finalización, y recibido un mensaje de finalizaciónde su par, el SSL Handshake Protocol esta listo. A partir de este instante comienza atrabajar el protocolo de aplicación (el protocolo de aplicación es una capa del SSLProtocol Record).

Secuencia típica de mensajes del protocolo

Las siguientes secuencias definen varias transacciones típicas del SSL Handshake Protocol.En estos ejemplos hay dos caracteres involucrados: el cliente y el servidor. Cuando algoesta entre llaves “{algo}clave" entonces el algo fue encriptado usando “clave”.


Página: 38

Asumiendo la falta de identificador de sesiónclient-hello C -> S: challenge, cipher_specs

server-hello S -> C: connection-id,server_certificate,

cipher_specs

client-master-key C -> S: {master_key}server_public_key

client-finish C -> S: {connection-id}client_write_key

server-verify S -> C: {challenge}server_write_key

server-finish S -> C: {new_session_id}server_write_key

Asumiendo que el cliente y el servidor encontraron un identificador desesión

client-hello C -> S: challenge, session_id, cipher_specs

server-hello S -> C: connection-id, session_id_hit



server-finish S -> C: {session_id}server_write_key

Asumiendo que se uso un identificador de sesión y autenticación de clienteserver-hello S -> C: connection-id, session_id_hit



request-certificate S -> C: {auth_type,challenge}server_write_key

client-certificate C -> S: {cert_type,client_cert,

response_data}client_write_key

server-finish S -> C: {session_id}server_write_key

Errores

El manejo de errores en el protocolo SSL es muy simple. Cuando se detecta un error, ellado que lo detecta le envía un mensaje a la otra parte. Los errores que no se puedenrecuperar hacen que el cliente y el servidor cancelen la conexión. El servidor y el clientedeben “olvidarse” de cualquier identificador de sesión asociado a una conexión perdida.

El SSL Handshake Protocol define los siguientes errores:

NO-CIPHER-ERROR

Este error es devuelto por el cliente cuando no puede encontrar un cifrador o tamaño declave que él y el servidor soporten. Es un error irrecuperable.


Página: 39

NO-CERTIFICATE-ERROR

Cuando se envía un mensaje REQUEST-CERTIFICATE, puede devolverse este error si elcliente no tiene un certificado con el cual contestar. Este error es recuperable (solo paraautenticación de clientes).

BAD-CERTIFICATE-ERROR

Este error se devuelve cuando un certificado es calificado como malo por la parte receptora.Malo significa que la firma del certificado es mala o que los valores en el certificado eraninapropiados (ej. un nombre en el certificado no se corresponde con el nombre esperado).Este error es recuperable (solo para la autenticación del cliente).

UNSUPPORTED-CERTIFICATE-TYPE-ERROR

Este error es devuelto cuando un cliente/servidor recibe un tipo de certificado que este nosoporta. Este error es recuperable (solo para la autenticación del cliente).

Mensajes del SSL Handshake Protocol

Los mensajes del SSL Handshake Protocol se encapsulan en el SSL Record Protocol y secomponen de dos partes: un código de tipo de mensaje de un byte, y algunos datos. Elcliente y el servidor intercambian mensajes hasta que ambos enviaron sus mensajes definalización. Mientras que un lado pudo haber terminado, la otra parte todavía puede estartrabajando, por lo tanto el lado que terminó debe seguir recibiendo los mensajes dehandshake del protocolo hasta que reciba un mensaje de finalización.

Después que cada parte determinó las claves de sesión, el cuerpo del mensaje se encriptausando esta. Para el cliente, esto sucede después que verifica el identificador de sesión ocrea una clave de sesión nueva y la haya enviado al servidor. Para el servidor, esto sucededespués que se corrobora el identificador de sesión, o el servidor recibe el mensaje de clavede sesión del cliente.

Mensajes del Cliente únicamente

Hay varios mensajes que solo pueden ser generados por clientes. Estos mensajes nunca songenerados por servidores que funcionan correctam9ente. Un cliente que reciba este tipo demensajes cierra la conexión con el servidor y devuelve un error a la aplicación.

CLIENT-HELLO

char MSG-CLIENT-HELLO

char CLIENT-VERSION-MSB

char CLIENT-VERSION-LSB

char CIPHER-SPECS-LENGTH-MSB

char CIPHER-SPECS-LENGTH-LSB

char SESSION-ID-LENGTH-MSB

char SESSION-ID-LENGTH-LSB

char CHALLENGE-LENGTH-MSB


Página: 40

char CHALLENGE-LENGTH-LSB

char CIPHER-SPECS-DATA[(MSB<<8)|LSB]

char SESSION-ID-DATA[(MSB<<8)|LSB]

char CHALLENGE-DATA[(MSB<<8)|LSB]

Cuando un cliente se conecta por primera vez con el servidor debe enviar el mensajeCLIENT-HELLO. El servidor espera este mensaje del cliente como su primer mensaje. Eserror enviar cualquier otra cosa como primer mensaje.

El cliente envía al servidor su versión de SSL, su especificación del cifrador, algunos datosy el identificador de sesión. El identificador de sesión solo se envía si el cliente encuentra ensu cache una identificación de sesión para ese servidor, y si el SESSION-ID-LENGTH no escero. Cuando no hay identificador de sesión para el servidor, SESSION-ID-LENGTH debe sercero. La porción de datos se usa para autenticar al servidor. Después que el cliente yservidor se ponen de acuerdo en un par de claves de sesión, el servidor devuelve un mensajede SERVER-VERIFY.

El servidor no enviara su mensaje de SERVER-HELLO hasta que no halla recibido el mensajeCLIENT-HELLO. Esto se hace así para que el servidor pueda indicarle al cliente el estado delidentificador de sesión del cliente en el primer mensaje del servidor (ej. para mejorar laeficiencia del protocolo y reducir el numero de mensajes de ida y vuelta necesarios).

El servidor examina el mensaje CLIENT-HELLO y verifica que pueda manejar la versión delcliente y una de las especificaciones del cifrador del cliente. El servidor puedeopcionalmente editar las especificaciones del cifrador, sacando las opciones que él nosoporta. La versión editada se devuelve en el mensaje SERVER-HELLO si el identificador desesión no esta en el cache del servidor.

CIPHER-SPECS-LENGTH debe ser mayor a cero y un múltiplo de tres. SESSION-ID-LENGTHdebe ser cero o 16. CHALLENGE-LENGTH debe ser mayor o igual que 16 y menor o igual que32.

Este mensaje debe ser el primer mensaje enviado por el cliente hacia el servidor. Despuésque se envía el mensaje el cliente espera por el mensaje SERVER-HELLO. Cualquier otromensaje del servidor es descartado (excepto ERROR).

CLIENT-MASTER-KEY

char MSG-CLIENT-MASTER-KEY

char CIPHER-KIND[3]

char CLEAR-KEY-LENGTH-MSB

char CLEAR-KEY-LENGTH-LSB

char ENCRYPTED-KEY-LENGTH-MSB

char ENCRYPTED-KEY-LENGTH-LSB

char KEY-ARG-LENGTH-MSB

char KEY-ARG-LENGTH-LSB

char CLEAR-KEY-DATA[MSB<<8|LSB]


Página: 41

char ENCRYPTED-KEY-DATA[MSB<<8|LSB]

char KEY-ARG-DATA[MSB<<8|LSB]

El cliente envía este mensaje cuando ha determinado una clave maestra que usa el servidor.Debe tenerse en cuenta que este mensaje no se envía cuando se había establecido unidentificador de sesión previamente.

El campo CIPHER-KIND indica que cifrador se eligió de las especificaciones enviadas por elservidor en CIPHER-SPECS.

CLEAR-KEY-DATA contiene la parte clara de la MASTER-KEY. El CLEAR-KEY-DATA secombina con SECRET-KEY-DATA para formar la MASTER-KEY, siendo SECRET-KEY-DATA losbytes menos significativos de la MASTER-KEY. ENCRYPTED-KEY-DATA contiene la partesecreta de la MASTER-KEY, encriptada usando la clave publica del servidor.

CLIENT-CERTIFICATE

char MSG-CLIENT-CERTIFICATE

char CERTIFICATE-TYPE

char CERTIFICATE-LENGTH-MSB

char CERTIFICATE-LENGTH-LSB

char RESPONSE-LENGTH-MSB

char RESPONSE-LENGTH-LSB

char CERTIFICATE-DATA[MSB<<8|LSB]

char RESPONSE-DATA[MSB<<8|LSB]

Este mensaje lo envía un cliente en respuesta a un mensaje REQUEST-CERTIFICATE delservidor. CERTIFICATE-DATA contiene información definida por el valor de CERTIFICATE-TYPE. Se envía un mensaje de ERROR con el código NO-CERTIFICATE-ERROR cuando no sepuede responder la solicitud adecuadamente (ej. el receptor del mensaje no poseecertificado registrado)

CERTIFICATE-TYPE es SSL_X509_CERTIFICATE

CERTIFICATE-DATA contiene un certificado firmado según X.509.

RESPONSE-DATA contiene la información de autenticación. Esta información es una funcióndel valor de AUTHENTICATION-TYPE enviado por el servidor.

Cuando AUTHENTICATION-TYPE es SSL_AT_MD5_WITH_RSA_ENCRYPTION la RESPONSE-DATA contiene una firma digital de los siguientes componentes:

• KEY-MATERIAL-0

• KEY-MATERIAL-1 (solo si esta definido por el tipo de cifrador)

• KEY-MATERIAL-2 (solo si esta definido por el tipo de cifrador)

• CERTIFICATE-CHALLENGE-DATA (del mensaje REQUEST-CERTIFICATE )

• El certificado del servidor firmado (del mensaje SERVER-HELLO)


Página: 42

La firma digital se construye usando MD5 y luego se encripta usando la clave privada delcliente. El servidor autentica al cliente verificando la firma digital mediante técnicasnormales. Se puede agregar un nuevo AUTHENTICATION-TYPE, o se puede cambiar el id delalgoritmo en la firma digital.

Un cliente solo debe enviar este mensaje en respuesta a un mensaje del tipo REQUEST-CERTIFICATE.

CLIENT-FINISHED

char MSG-CLIENT-FINISHED

char CONNECTION-ID[N-1]

El cliente envía este mensaje cuando esta conforme con el servidor. El cliente debecontinuar escuchando hasta que reciba el mensaje SERVER-FINISHED. El CONNECTION-ID esel identificador original que el servidor envío con su mensaje de SERVER-HELLO, encriptadousando la clave de sesión.

"N" es la cantidad de bytes que se enviaron en el mensaje, por lo tanto "N-1" es la cantidadde bytes en el mensaje sin el byte del encabezado.

Según la versión 2 del protocolo, el cliente debe enviar este mensaje después que recibió elmensaje de SERVER-HELLO. Si el flag SESSION-ID-HIT en el mensaje SERVER-HELLO esdistinto de cero, entonces se envía el mensaje CLIENT-FINISHED inmediatamente, de locontrario el mensaje CLIENT-FINISHED se envía después del mensaje CLIENT-MASTER-KEY.

Mensajes del Servidor únicamente

Hay varios mensajes que se generan únicamente en el servidor. Nunca son generados porcliente que funcionan correctamente.

SERVER-HELLO char MSG-SERVER-HELLO char SESSION-ID-HIT char CERTIFICATE-TYPE char SERVER-VERSION-MSB char SERVER-VERSION-LSB char CERTIFICATE-LENGTH-MSB char CERTIFICATE-LENGTH-LSB char CIPHER-SPECS-LENGTH-MSB char CIPHER-SPECS-LENGTH-LSB char CONNECTION-ID-LENGTH-MSB char CONNECTION-ID-LENGTH-LSB char CERTIFICATE-DATA[MSB<<8|LSB] char CIPHER-SPECS-DATA[MSB<<8|LSB] char CONNECTION-ID-DATA[MSB<<8|LSB]

El servidor envía este mensaje después de recibir el mensaje CLIENT-HELLO del cliente. Elservidor devuelve le flag de SESSION-ID-HIT indicando si conoce o no el identificador desesión recibido. El flag SESSION-ID-HIT será distinto de cero si el cliente envía al servidorun identificador de sesión (en el mensaje CLIENT-HELLO con SESSION-ID-LENGTH != 0) y el


Página: 43

servidor encuentra el identificador de sesión del cliente en su cache. Si el flag SESSION-ID-HIT es distinto de cero, entonces los campos CERTIFICATE-TYPE, CERTIFICATE-LENGTH yCIPHER-SPECS-LENGTH serán ceros.

El valor de CERTIFICATE-TYPE, si es distinto de cero, tiene el mismo valor que en elmensaje CLIENT-CERTIFICATE.

Cuando el flag SESSION-ID-HIT es cero, el servidor empaqueta su certificado, lasespecificaciones de su cifrador y un identificador de sesión para enviarle al cliente. Usandoesta información el cliente puede generar una clave de sesión y devolverla al servidor en elmensaje CLIENT-MASTER-KEY.

Cuando el flag SESSION-ID-HIT es distinto de cero, el servidor y el cliente calculan un parnuevo de claves de sesión para la sesión actual basándose en la MASTER-KEY queintercambiaron cuando se creó el SESSION-ID. La SERVER-READ-KEY y SERVER-WRITE-KEY se derivan de las claves MASTER-KEY originales de la misma manera que las CLIENT-READ-KEY y CLIENT-WRITE-KEY:

SERVER-READ-KEY = CLIENT-WRITE-KEYSERVER-WRITE-KEY = CLIENT-READ-KEY

Cuando se derivan claves y el flag SESSION-ID-HIT es uno y el servidor encuentra elidentificador de sesión del cliente en su cache, entonces se usa KEY-ARG-DATA

correspondiente al momento en que se estableció el SESSION-ID. Esto es así porque elcliente no envía nuevos KEY-ARG-DATA (KEY-ARG-DATA se envía solamente en el mensajeCLIENT-MASTER-KEY).

CONNECTION-ID-DATA es un conjunto de bytes generados al azar usado por el servidor y elcliente en varias partes del protocolo. El mensaje CLIENT-FINISHED contiene una versiónencriptada de CONNECTION-ID-DATA. El largo de CONNECTION-ID debe estar entre 16 y 32bytes.

CIPHER-SPECS-DATA define un tipo de cifrador y largo de clave (en bits) que el ladoreceptor soporta. Cada SESSION-CIPHER-SPEC tiene 3 bytes y el siguiente formato:

char CIPHER-KIND-0

char CIPHER-KIND-1

char CIPHER-KIND-2

Donde CIPHER-KIND es uno de:

• SSL_CK_RC4_128_WITH_MD5

• SSL_CK_RC4_128_EXPORT40_WITH_MD5

• SSL_CK_RC2_128_CBC_WITH_MD5

• SSL_CK_RC2_128_CBC_EXPORT40_WITH_MD5

• SSL_CK_IDEA_128_CBC_WITH_MD5

• SSL_CK_DES_64_CBC_WITH_MD5

• SSL_CK_DES_192_EDE3_CBC_WITH_MD5


Página: 44

Esta lista no es exhaustiva y puede cambiar en el futuro.

El cifrado SSL_CK_RC4_128_EXPORT40_WITH_MD5 es un cifrador RC4 donde partede la clave de sesión se envía encriptada (exactamente 40 bits) y otra parte no. La funciónde hash usada es MD5. Este tipo de cifrador esta para las versiones del protocolo quepueden distribuirse fuera de los Estados Unidos.

La versión 2 del SSL Handshake Protocol define que SSL_CK_RC4_128_WITH_MD5 tiene unlargo de clave de 128 bits. El SSL_CK_RC4_128_EXPORT40_WITH_MD5 también tiene unaclave de 128 bits. Sin embargo, solo 40 de los bits son secretos (los otros 88 bits se envíansin encriptar al servidor).

El mensaje SERVER-HELLO se envía después que el servidor recibe el mensaje CLIENT-HELLO, y antes que el servidor envíe el mensaje SERVER-VERIFY.

SERVER-VERIFYchar MSG-SERVER-VERIFYchar CHALLENGE-DATA[N-1]

El servidor envía este mensaje después que se estableció un par de claves de sesión(SERVER-READ-KEY y SERVER-WRITE-KEY) mediante un identificador de sesión o medianteun mensaje CLIENT-MASTER-KEY. El mensaje contiene una copia encriptada delCHALLENGE-DATA enviada por el cliente en el mensaje CLIENT-HELLO.

"N" es la cantidad de bytes en el mensaje que se envío, por lo tanto "N-1" es la cantidad debytes en CHALLENGE-DATA sin el byte de header del mensaje.

Este mensaje se usa para verificar un servidor. Un servidor legitimo poseerá la clave privadaque se corresponde con la clave publica incluida en el certificado del servidor que se envíoen el mensaje SERVER-HELLO. El servidor legitimo puede extraer y reconstruir el par declaves de sesión (SERVER-READ-KEY y SERVER-WRITE-KEY). Finalmente, solo el servidorque extrajo y desencriptó correctamente puede encriptar bien el CHALLENGE-DATA. Esto, enesencia, "prueba" que el servidor posee la clave privada que se corresponde con la clavepublica del certificado del servidor.

El CHALLENGE-DATA debe ser del mismo largo que el enviado originalmente por el cliente enel mensaje CLIENT-HELLO. Su valor debe coincidir exactamente con el valor enviado por elcliente en el mensaje CLIENT-HELLO. El cliente debe desencriptar este mensaje y compararel valor recibido con el valor enviado, y solo si son idénticos, considerar al servidor como“confiable”. Si el largo o valor no coincide entonces el cliente termina la conexión.

Este mensaje debe ser enviado por el servidor al cliente después de detectar un identificadorde sesión (y respondiendo con un mensaje SERVER-HELLO cuyo SESSION-ID-HIT seadistinto a cero) o cuando el servidor recibe el mensaje CLIENT-MASTER-KEY. Este mensajedebe enviarse antes de cualquier mensaje de fase 2 o mensaje SEVER-FINISHED.

SERVER-FINISHED

char MSG-SERVER-FINISHED

char SESSION-ID-DATA[N-1]


Página: 45

El servidor envía este mensaje cuando esta satisfecho con la seguridad del cliente y esta listopara transmitir/recibir datos de los protocolos de mas alto nivel. El cliente y el servidor usanel SESSION-ID-DATA para agregar entradas en sus respectivos caches de identificadores desesión. Los caches de identificadores de sesión deben contener una copia de la MASTER-KEYenviada en el mensaje CLIENT-MASTER-KEY ya que la clave maestra se utiliza para lageneración de las claves de sesión subsiguientes.

"N" es la cantidad de bytes en el mensaje que se envío, y "N-1" es la cantidad de bytes enSESSION-ID-DATA sin el byte del header del mensaje.

Este mensaje debe enviarse después del mensaje SERVER-VERIFY.

REQUEST-CERTIFICATE

char MSG-REQUEST-CERTIFICATE

char AUTHENTICATION-TYPE

char CERTIFICATE-CHALLENGE-DATA[N-2]

Un servidor puede hacer este pedido en cualquier momento durante la segunda fase de laconexión. El cliente responde con un mensaje CLIENT-CERTIFICATE inmediatamente siposee uno, o un mensaje ERROR (con un código de error NO-CERTIFICATE-ERROR) si no lotiene. CERTIFICATE-CHALLENGE-DATA es una cadena de bytes corta (cuya longitud esmayor o igual a 16 bytes y menor o igual a 32 bytes) que el cliente usará para responder aeste mensaje.

El valor AUTHENTICATION-TYPE se usa para elegir una forma particular de autenticar alcliente. Los tipos definidos son:

• SSL_AT_MD5_WITH_RSA_ENCRYPTION

El tipo SSL_AT_MD5_WITH_RSA_ENCRYPTION requiere que el cliente construya un resumenMD5 del mensaje usando la información como se describió para el mensaje CLIENT-CERTIFICATE. Cuando el resumen esta listo, el cliente lo encripta usando su claveprivada. El servidor autentica al cliente cuando recibe el mensaje CLIENT-CERTIFICATE.

Este mensaje puede ser enviado después de un mensaje SERVER-VERIFY y antes de unmensaje SERVER-FINISHED.

Mensajes del Cliente/Servidor

Estos mensajes se generan tanto en el cliente como en el servidor.

ERROR

char MSG-ERROR

char ERROR-CODE-MSB

char ERROR-CODE-LSB

Este mensaje se envía cuando se detecta un error. Después que se envía el mensaje, el ladoque lo envió cierra la conexión. La parte que lo recibe registra el error y luego cierra laconexión.


Página: 46

Este mensaje se envía sin encriptar si se detecta un error durante la negociación de la clavede sesión. Después que se estableció la clave de sesión, los errores se envían encriptadoscomo todos los otros mensajes.

Ataques

En esta sección se describen varios tipos de ataques que pueden usarse contra el protocoloSSL.

Romper los cifradores

SSL depende de varias tecnologías criptográficas. La encriptación de clave publica RSA seutiliza para el intercambio de la clave de sesión y la autenticación del cliente/servidor. Seutilizan varios algoritmos para el cifrador de sesión. Si se logran ataques criptograficamenteexitosos contra estas tecnologías entonces SSL no es seguro.

Se pueden hacer ataques contra una sesión especifica grabando la sesión, y luego descubrirla clave de sesión o la clave publica del RSA hasta ver la comunicación sin encriptarmediante el uso de los ataques de fuerza bruta. SSL intenta que el costo de tales ataques seamayor que los beneficios obtenidos en un ataque exitoso, haciendo que esto sea una perdidade tiempo y dinero.

Ataque de texto claro

Un ataque de texto claro se hace cuando el atacante tiene una idea del tipo de mensaje quese envía encriptado. El atacante puede generar una base de datos cuyas claves sean losvalores encriptados de texto conocido (texto claro), y cuyos valores son la clave delcifrador de sesión (a esto se lo llama "diccionario"). Una vez que esta base de datos estaconstruida, una simple función de búsqueda identifica la clave de sesión que se correspondecon un valor particular encriptado. Cuando se conoce la clave de sesión, se puededesencriptar el mensaje entero. Se puede utilizar hardware especializado para hacer estomuy rápido.

Debido a la naturaleza de SSL un ataque de texto claro es posible. Por ejemplo, la cadenade bytes mas común enviada por un cliente HTTP a un servidor HTTP es "GET". SSLintenta evitar este ataque usando claves de sesión del cifrador grandes. Primero, el clientegenera una clave que es más grande que lo permitido según las leyes de exportación delgobierno de Estados Unidos, y envía parte de esta sin encriptar al servidor. La parte clara dela clave se concatena con la parte secreta para lograr una clave muy larga (para RC4,exactamente 128 bits).

Esta forma de trabajar “vence” al ataque de texto claro ya que hace la cantidad de hardwareespecializado enorme. Cada bit agregado a la clave incrementa el tamaño del diccionariopor un factor de 2. Al usar una clave de 128 bits de largo el tamaño del diccionarionecesario es inmenso (para construirlo se necesitarían mas átomos de los que existen en eluniverso).


Página: 47

Replay

Este tipo de ataques es simple. Alguien graba una comunicación entre un servidor y uncliente. Mas tarde se conecta al servidor y vuelve a enviar los mensajes previamentegrabados.

SSL vence este ataque usando un identificador de sesión que es “único”. En teoría el intrusono puede predecir el identificador de sesión por adelantado ya que esta basado en unconjunto de eventos aleatorios fuera de su control, y por lo tanto el intruso no puederesponder adecuadamente a los pedidos del servidor.

Un intruso con gran capacidad puede grabar muchas sesiones entre un cliente y un servidor,e intentar elegir la sesión correcta basado en el identificador de sesión que el servidor envíainicialmente en su mensaje SERVER-HELLO. Sin embargo, los identificadores de sesión deSSL tienen por lo menos 128 bits, por lo tanto el intruso necesitaría grabaraproximadamente 264 identificadores de sesión para tener un chance del 50% de elegir lasesión correcta. Este numero es suficientemente grande como para que nadie puedaconstruir un dispositivo que grabe los 264 mensajes.

El hombre en el medio

El ataque conocido como hombre en el medio trabaja con tres personas en unacomunicación: el cliente, el servidor y el intruso. El intruso se coloca entre el cliente el yservidor en la red y intercepta el trafico que el cliente le envía al servidor, y el trafico que elservidor le envía al cliente.

El hombre en el medio pretende ser el servidor real. Con SSL este ataque es imposibledebido al uso de certificados. Durante el establecimiento de la conexión el servidor debeproveer un certificado firmado por una autoridad certificante. En el certificado esta la clavepublica del servidor, su nombre y el nombre del certificador. El cliente verifica el certificadousando la firma y luego verifica que el nombre del certificador sea alguien en quien el clienteconfía.

Además, el servidor debe encriptar algo con la clave privada que se corresponde con laclave publica mencionada en el certificado.

Si el hombre en el medio provee un certificado falso, no se verificará la firma. Si elcertificado es legitimo, pero es el del intruso en vez del servidor real, entonces la firma seráverificada pero fallará la verificación del nombre (el hombre en el medio no puede falsificarun certificado sin descubrir la clave privada de la autoridad certificante).

Finalmente, si el intruso envía el certificado del servidor real tanto la firma como laverificación del nombre serán correctas. Sin embargo, ya que el intruso no posee la claveprivada del servidor real, el intruso no puede responder el pedido del cliente.

En el raro caso en que el intruso adivine el código de la respuesta al pedido del cliente, elintruso no puede aun desencriptar la clave de la sesión y por lo tanto no puede examinar losdatos encriptados.


Página: 48

Referencias

1. “Introducing SSL and Certificates using SSLeay” Frederick J. Hirsch. Jun 4 1998World Wide Web Journal

2. SSL2.0, http://www.netscape.com/newsref/std/SSL_old.html

3. SSL3.0 Internet Draft, http://www.consensus.com/ietf-tls/tls-ssl-version3-00.txt

4. TLS Working Group (IETF), http://www.consensus.com/ietf-tls/

5. “The SSL Protocol” Kipp E.B. Hickman. Netscape Communications Corp.http://www.colossus.net/SSL.html

FACULTAD DE INGENIERIA - materias.fi.uba.armaterias.fi.uba.ar/6669/alumnos/1999/ssl.pdfSistemas...

Documents

Transcript of FACULTAD DE INGENIERIA - materias.fi.uba.armaterias.fi.uba.ar/6669/alumnos/1999/ssl.pdfSistemas...