1. INTRODUCCIÓN A LA SEGURIDAD

Planteamiento inicial

En sus inicios, la red de Internet fue ideada como un medio de intercambio de información entre científicos e investigadores que fue acogida con gran éxito. Gracias a este nuevo medio de comunicación, los centros de investigación y las universidades tuvieron a su disposición ingentes cantidades de información organizada en la base de datos más potente que jamás pudieran imaginar. El principio de funcionamiento era simple. Su base fue la difusión de información de una manera gratuita y su planteamiento inicial permitía a todos los usuarios publicar sus artículos a la vez que accedían a toda la información enviada por el resto de los usuarios.

En esos momentos nadie pensó que aquella red pudiera llegar a transportar dinero por sus arterias y su planteamiento inicial no facilitó el desarrollo del Comercio Electrónico. La venta en Internet fue prohibida ya que existían impedimentos técnicos pero, a partir del año 90, estos problemas se fueron solucionando y surgieron las primeras operaciones comerciales en la Red de Redes.

Criminales en la Red

La verdad es que es difícil decir cada cuanto tiempo se comete un fraude en Internet, pero lo importante es que las operaciones fraudulentas son técnicamente posibles y existen. Además, a medida que Internet crece, este tipo de situaciones se da mucho más a menudo. Internet es el medio de comunicación del próximo siglo y beneficia a toda la sociedad. Pero también esconde acciones delictivas como cualquier otro medio de comunicación: las bandas terroristas, el tráfico de armas o pornografía infantil y el blanqueo de dinero son algunas de las acciones más fraudulentas que se han descubierto en la Red.

¿Por qué es Internet inseguro?

Internet funciona enviando datos de un lugar a otro a través de una inmenso red que la información debe atravesar para llegar a su destino. Los datos son fraccionados en pequeños paquetes que circulan de manera independiente siendo transportados de un lugar a otro por cientos de ordenadores. Cuando los paquetes llegan a su destino se recomponen para obtener la información completa. Todos los ordenadores que intervienen en este proceso tienen la oportunidad de acceder a los paquetes que transportan y si la información no está debidamente protegida contra los intrusos, estos podrán modificarla o copiarla con la intención de apoderarse de datos confidenciales, como el número de una tarjeta de crédito.

Criptografía

La única manera de proteger los datos para que viajen por Internet de una manera segura es la criptografía. Es curioso que una técnica que se remonta al antiguo Egipto sea hoy aplicada como solución a uno de los importantes retos de la Era Digital. Actualmente se dispone de una avanzada tecnología en métodos matemáticos que codifican los bits de tal forma que resulta imposible interpretarlos sin las fórmulas esenciales que los crearon, convirtiendo la información en algo inviolable. Básicamente existen dos tipos de codificación: los RSA de clave pública y los DES de clave secreta. Un sistema criptográfico basado en una clave pública utiliza dos claves relacionadas que se complementan. El usuario deberá distribuir la clave pública entre los amigos y personas que desee puedan leer sus datos. Pero tendrá que guardar celosamente la clave privada en un lugar secreto. Para codificar empleará la clave pública convirtiendo el mensaje en un texto inteligible a no ser que se disponga de la clave privada que permite descifrar el mensaje. Este método es utilizado en los mensajes de correo electrónico de carácter privado. En los sistemas criptográfico basados en clave privada se utiliza una única clave para codificar y descodificar el mensaje. De manera que el emisor y receptor deberán intercambiar previamente mediante un canal seguro la clave que desean utilizar. Posteriormente pueden enviar los mensajes codificados mediante un canal inseguro. El principal problema que surge con este método es que tanto el emisor como el destinatario deben disponer de la clave y por tanto se deben emplear tantas claves como destinatarios se quieran tener.

La firma digital

Habitualmente cuando realizamos un pago en algún comercio con una tarjeta de crédito, debemos firmar el resguardo que posteriormente se queda el comerciante. Esta operación de firma es extremadamente sencilla, ya que basta con utilizar un bolígrafo para escribir nuestro nombre. Pero en el mundo digital se convierte en una de las tareas más complicadas ya que los datos digitales pueden ser copiados y falsificados con extrema facilidad. Para evitarlo se emplean métodos que permiten realizar idénticas notificaciones en los documentos electrónicos a partir de una codificación que se suele llamar firma digital. El sistema se basa en dos claves, una pública y otra privada que se complementan. La clave privada es secreta y es la utilizada para autentificar el documento. La clave pública está disponible para cualquier persona y permite que todo el mundo pueda verificar la autenticidad del documento. En la actualidad la firma digital es un apoyo a la firma tradicional pero no puede suplantarla.

El rastro del dinero

Todas las operaciones realizadas con dinero digital son controladas por los bancos. Desde qué producto se compra, cuándo y cómo hasta dónde procede y adónde llega. Aunque este control pueda parecer abusivo, las entidades controladoras garantizan la completa intimidad del cliente. Este control es muy importante para evitar estafas de duplicación. Supongamos que Vd. realiza una compra en Internet enviando una orden de cobro contra su cuenta corriente. La empresa que recibe el dinero podría pasar por el banco la misma orden varias veces y hacer lo mismo con el resto de sus clientes. Pero este tipo de operaciones sospechosas son detectadas fácilmente ya que todas las compras realizadas quedan registradas de igual manera que ocurre cuando se paga en un restaurante o una gasolinera.

Sitios web seguros

Cualquiera con unos mínimos conocimientos del lenguaje HTML puede crear un sitio web dedicado al comercio electrónico. Sólo deberá ofrecer algún producto y solicitar al cliente el número su tarjeta en un formulario de compra, sin ningún tipo de protección. Pero la información puede ser interceptada por terceras personas. También es posible que la empresa no exista y se trate de una tapadera. El protocolo SSL (Línea de Servidor Seguro), desarrollado por Netscape, es utilizado por la mayoría de los navegadores y establece un canal de comunicación codificado. Identifica el servidor al que se desean enviar los datos, certificando que realmente pertenece a la empresa que afirma. La transmisión de la información se hace de una manera segura, ya que los datos están codificados. Cuando accedemos a un sitio web seguro aparece un mensaje de advertencia; además, la dirección URL comenzará por https:// en lugar de http://. En los navegadores Netscape y Explorer aparecerá el candado cerrado o la llave en la esquina inferior derecha de la pantalla. Si todas estas condiciones se cumplen, no debe tener temor a introducir sus datos. Todos los sitios web seguros obtienen un certificado de seguridad otorgado por entidades reconocidas. Para acceder a este certificado en Netscape, deberá seleccionar "Ver", "Información del documento" y "Seguridad". Con Explorer deberá pulsar sobre "Archivo", "Propiedades" y "Certificados". Aparecerá una ventana con información sobre la autenticidad del documento.

Conclusiones

En definitiva, podemos contemplar a Internet como un medio de comunicación seguro aplicado al Comercio Electrónico aunque está libre de problemas. Comprar en Internet es seguro pero resulta necesario tomar las precauciones adecuadas antes de aventurarse a utilizarlo como medio de pago. La Red de Redes nos ofrece la ventaja de comparar precios y productos desde nuestra propia casa. Además, al eliminar algunos puntos de la cadena de distribución los precios suelen ser más bajos. No debemos dejar pasar esta oportunidad que nos brinda el futuro de las Tecnologías de la Información por miedo a nuestra privacidad, pero debemos estar bien informados. Tal vez en un futuro próximo todos nosotros realicemos las compras a través del ciberespacio.

Información y consejos

  1. Desconfíe. No se fíe de todo lo que ve en Internet. Los sitios más sospechosos se dedican a ofrecer trabajo o vender lotería, pero en muchas ocasiones lo que realmente persiguen es su dinero.
  2. Verifique siempre la autenticidad del sitio. Utilice las opciones del navegador para obtener información sobre la identificación del documento. Compruebe los datos y si no está seguro, no compre.
  3. Nunca facilite sus datos bancarios a través de correo electrónico. Este método es el que se puede interceptar más fácilmente. Aunque existen métodos para codificar el correo electrónico de una manera segura, son muy poco empleados.
  4. Compre siempre en sitios seguros. Compruebe que cuando compra en Internet lo hace a través de un sitio web seguro. El candado de Netscape debe encontrarse cerrado y en Explorer debe aparecer el logotipo de seguridad. Comprar en sitios seguros impide que los delincuentes utilicen falsas identidades y codifica los datos.

Uno de los principales riesgos de comprar a través de Internet es la inseguridad en las formas de pago

En el nuevo mercado global que es el Comercio Electrónico, la mayor preocupación hoy en día de todos los agentes económicos que intervienen en él (entidades financieras, distribuidores, empresarios, gobiernos y consumidores finales) es la percepción de inseguridad en la realización de negocios mediante métodos electrónicos y más concretamente en la Red Internet.

Las transacciones. Como transacción de Comercio Electrónico entendemos todo el proceso de realización de un acuerdo comercial, incluyendo contacto entre las partes, negociación y medios de pagos seguros. Los aspectos principales que debe reunir toda tecnología y/o aplicación de transacciones seguras y/o medios de pago deben ser; en primer lugar, autenticación, lo que nos asegura que con quien nos comunicamos es realmente quien dice que es. Por otro lado, se encuentra la integridad, es decir, el contenido de la comunicación entre las partes no puede ser modificado. La confidencialidad consigue que nadie no autorizado pueda conocer el contenido de la comunicación. Por último, no repudiar el origen y destino: una vez aceptada la relación comercial, no podrá ser rechazada.

Modelo básico de transacción. Como ejemplo para ver más claramente el proceso de una transacción, suponemos una compraventa de un producto, por ejemplo, libros, a través de la Red Internet.

El proceso sería: primero el comprador (A) se conecta a Internet usando un navegador. Segundo, busca una tienda de libros y selecciona varios títulos. En tercer lugar, decide realizar a compra y, a través de un formulario en pantalla, solicita la compra de dichos libros. En cuarto lugar, el servidor de la compañía vendedora (B) le solicita datos personales, datos financieros (por ejemplo un número de tarjeta de crédito) y datos para el envío. Después, el comprador introduce los datos solicitados y los envía a través de la Red. Luego, el vendedor solicita confirmación de pago a una entidad financiera con los datos suministrados por el comprador. Y por último, una vez recibida la confirmación de pago, envía la mercancía mediante un operador logístico al comprador. Esta transacción es muy similar a cualquier compra de crédito que se hace en la vida real. Y en la vida real se plantean los siguientes problemas: ¿es realmente esta persona propietaria de la tarjeta de crédito?, ¿es quien dice ser?, ¿es este negocio un distribuidor de libros real? (Autenticación), ¿me habrán modificado los datos del pedido? (Integridad), ¿se habrán quedado con el número de mi tarjeta?, ¿alguien habrá interceptado en el envío de mis datos personales? (Confidencialidad), ¿rechazará el banco el pago de este cliente? (No repudio).

La autenticación se resuelve mediante las firmas digitales y/o expedición de certificados por autoridades legalmente reconocidas para ello. Estos certificados son la prueba de identidad de cada uno de los agentes que intervienen en el proceso. La integridad se resuelve mediante la incorporación de firmas digitales que impiden la modificación de los datos enviados. La confidencialidad mediante sistemas de encriptación. Los sistemas más aceptados hoy en día son los que funcionan mediante el esquema de clave asimétrica (pública/privada). Los mecanismos de no repudio consisten en la existencia de validez legal de la firma digital (lo mismo que en la vida real) y en la existencia de registros de transacciones.

2. INTRODUCCIÓN A LOS PROTOCOLOS SEGUROS EN LA RED

En Internet, estamos expuestos a los 4 tipos de ataques fundamentales:


- Interrupción

- Intercepción

- Modificación

- Generación

Internet funciona enviando datos de un lugar a otro a través de una inmensa red que la información debe atravesar para llegar a su destino. Los datos son fraccionados en pequeños paquetes que circulan de manera independiente siendo transportados de un lugar a otro por cientos de ordenadores. Cuando los paquetes llegan a su destino se recomponen para obtener la información completa. Todos los ordenadores que intervienen en este proceso tienen la oportunidad de acceder a los paquetes que transportan y si la información no está debidamente protegida contra los intrusos, estos podrán modificarla, destruirla o copiarla con la intención de apoderarse de datos confidenciales, como el número de una tarjeta de crédito

¿ Que se puede hacer en el caso de que se necesite enviar datos confidenciales ?

Soluciones:

Se han desarrollado protocolos y aplicaciones de seguridad

para el modelo TCP/IP:

                                    - Autentificación <®X.509, Kerberos (sobre UDP) ...

                                    - Correo Electrónico <® S/MIME, PGP, PEM...

                                    - Acceso WWW ® S-HTTP, SSL, TLS, PCT, SET ...

                                    - Envio de paquetes ® Seguridad IP.

Comentaremos muy brevemente estos y otros protocolos:


             - X.509 es un formato estándar de certificado digital. Actualmente está en su tercera versión (X.509v3). Es utilizado en otros protocolos y aplicaciones de seguridad como S/MIME, SSL, SET ...


            -Kerberos : Es un aplicación utillizada para asegurar la autentificación en comunicaciones Cliente / Servidor. No trabaja sobre TCP, sino sobre UDP, (user datagram protocol, es decir, protocolo de datagrama de usuario), [que es un protocolo que sin conexión, no confiable, para aplicaciones que no necesitan la asignación de secuencia ni el control de flujo del TCP, sino que quieran utilizar su propio protocolo para la asignación de secuencia y control de flujo].


            - S/MIME : S/MIME es un protocolo que añade firmas digitales y cifrado a los mensajes . Secure / Multipurpose Internet Mail Extension, permite autentificación, firma, etc... en el correo electrónico. S/MIME trabaja sobre MIME, el cual es un protocolo de intercambio de objetos a través de Internet.


            - El PGP = Pretty Good Privacy ó "Encriptación bastante buena" es unsistema de encriptación por llave pública escrito por Philip Zimmermann, y sirve para que nadie salvo uno mismo y el destinatario o destinatarios a los que vaya dirigido el mensaje puedan leerlo, al ir los mensajes codificados, y también puede usarse para comprobar la autenticidad del mensaje asegurándonos que lo ha escrito el remitente en realidad. Realmente es muy bueno y es prácticamente indescifrable.


                 - Los protocolos SSL y S-HTTP surgieron durante la segunda mitad de 1995 para dar respuesta a las necesidades de seguridad en el intercambio de información en Internet .

            · SSL no esta asociado a ningún servicio de la capa de aplicación, sino que en si misma es una capa de seguridad añadida entre la capa TCP y la de aplicación. SSL puede utilizarse para cualquier servicio a nivel de aplicación, aparte de HTTP (acceso web), como SMTP (correo), FTP (acceso remoto), etc...

Actualmente, esta en su tercera versión.

· La siguiente fase a SSL y S-HTTP fue la constitución de dos consorcios para la extensión de estos protocolos al comercio electrónico. El primer consorcio formado por IBM, Netscape, GTE, CyberCash y MasterCard desarrolló una extensión denominada Secure Electronic Payment Process (SEPP). Por otra parte, Visa y Microsoft definieron Secure Transaction Technology (STT). Microsoft también introdujo el protocolo Private Communication Technology (PCT).

                - PCT = Privaty Communicator TTechnology, protocolo desarrollado por Microsoft, mucho más seguro que SSL 2.0, pero no es un estándar como SSL 2.0 (no todos los servidores disponen de este protocolo). Los avances de PCT se incorporaron en SSL 3.0. [Después de que SSL 2.0 fue publicada, Microsoft creo un procolo de enlace seguro similar denominado PCT que solventaba algunos de los errores de la versión 2.0 del SSL].


                - El protocolo SSL 3.0 es la base del TLS (Transport Layer Security) desarrollado por el IETF (Internet Engineering Task Force). Se podría decir que es SSLv3.1 ya que es compatible hacia atrás con todas las versiones de SSL y es SSL 3 pero mejorado. La implementación del protocolo HTTP usando TLS o SSL como protocolo de transporte, mejor conocido como HTTPS.

-Fortezza: Especificación de cifrado basado en hardware para conexiones seguras. Se utiliza tarjeta Fortezza Crypto y controladores de software (Utilizado en el Departamento de Defensa de los EEUU ).

       - Podríamos decir que tanto SSl, TLS, y otros estándar son utilizados para establecer un canal seguro, en principio, independiente del servicio de la aplicación utilizado.


                    - SET : Secure Electronic Transactions. Protocolo criptográfico desarrollado por Visa, Mastercard, Netscape y Microsoft. A diferencia de SSL, SET es altamente específico. Puede usarse sólo para transacciones seguras de tarjetas de crédito y débito entre clientes y comerciantes.
Sirve para: Pedidos de compra, Autorización de pago, Créditos...


        - IP Security (Seguridad IP) : Para autentificación y confidencialidad:

3.S-HTTP

- S-HTTP son Siglas de Secure HyperText Transfer Protocol. El protocolo S-HTTP fue desarrollado por Enterprise Integration Technologies (EIT) y desarrollado en la actualidad por Terisa Systems.

S-HTTP es una capa de extensión sobre el estándar HTTP para la transferencia Web, con el propósito de encriptar la información durante una sesión HTTP. Al igual que SSL, permite tanto el cifrado como la autentificación digital. Sin embargo, a diferencia de SSL, S-HTTP es un protocolo de nivel de aplicación, es decir, que extiende el protocolo HTTP por debajo. incorporando cabeceras MIME para aportar confidencialidad, autenticación, integridad e irrenunciabilidad de las transacciones. Utiliza un sistema inspirado en PEM, añadiendo suficientes cabeceras a cada transacción para lograr cada uno de los objetivos propuestos.

Como funciona ?

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


Las negociaciones entre el cliente y el servidor tienen lugar intercambiando datos formateados. Estos datos incluyen una variedad de opciones de seguridad y algoritmos a utilizar. Las líneas usadas en las cabeceras incluyen:

· Dominios privados S-HTTP, que especifica la clase de algoritmos de cifrado así como la forma de encapsulamiento de los datos (PEM o PKCS-7).

· 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 se usará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 para proporcionar 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étrico decifrado en bloque usado para cifrar los datos:


            · Ventajas :

-Las principales ventajas de S-HTTP son su flexibilidad y su  integración dentro de HTML (extensiones al lenguaje similares a las introducidas periódicamente por Netscape Company en sus navegadores).

            · Desventajas :

- Entre sus debilidades podemos señalar los efectos derivado de mantener la compatibilidad hacia atrás y la necesidad de implementar servidores que soporten las extensiones a HTML aportadaspor el protocolo S-HTTP.

 

4. SSL (Secure Socket Layer)

- SSL 3.0 es la versión actual de este protocolo . En su estado actual, SSL proporciona :

- Cifrado de datos: Encriptación de datos de extremo a extremo

- Autenticación de servidores: De manera que el cliente pueda estar seguro de que la información que recibe proviene del servidor que supuestamente se la esta enviando.

- Integridad de los mensajes : Detección de manipulación de comentarios

- Autenticación de clientes (Opcionalmente) : Autenticación opcional del cliente, para que el servidor pueda estar seguro de que el cliente que accede a la información contenida en sus sedes es quien dice ser, o para la autentificación en comunicaciones entre usuarios

® Viene soportado por los dos principales navegadores:

- Netscape Navigator 3.0 o superior

- Internet Explorer 3.0 o superior

Desgraciadamente, no todos los servidores aceptan SSL 3.0, aunque los servidores seguros están obligados a aceptar el estándar SSL 2.0


Descripción de SSL

[SSL implementa la seguridad en la comunicación entre cliente y servidor en el nivel de sesión, por tanto, implica un número reducido de decisiones, es independiente del protocolo de aplicación y resulta fácil de establecer.]

[La única cosa que no puede ser ocultada por SSL es que un browser está hablando con un servidor en particular. Para evitar esto, se puede usar SSL junto con un proxy anónimo.]

El protocolo SSL esta formado a su vez por cuatro protocolos:
 

1) El Record Protocol se dedica a codificar y decodificar los mensajes que se trasmiten y reciben. Se encuentra a un nivel más bajo sobre un protocolo de transporte fiable (por ejemplo : TCP), proporcionando una conexión segura y privada.

2) El HandShake Protocol consiste de un conjunto de subprotocolos que se usan para permitir a las partes de la comunicación estar de acuerdo respecto de parámetros de seguridad, autentificación y condiciones de informes de error.

3) El Change Cipher Spec Protocol sirve para enviar los mensajes "Change Cipher Spec" entre el cliente y servidor, los cuales notificaran que la política de registros según el CipherSpec y las claves negociadas esta lista.

4) El SSL Alert Protocol para el envio de mensajes de alerta.

Record Protocol

La porción de datos del protocolo tiene tres componentes:

                                            · MAC-DATA, el código de autentificación del mensaje.

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

                                            · PADDING-DATA, los datos requeridos para rellenar el mensaje cuando se usa cifrado en bloque.

Handshake Protocol

· El HandShake Protocol consiste en un conjunto de subprotocolos que se usan para permitir a las partes de la comunicación (cliente y servidor ) estar de acuerdo respecto a los parámetros de seguridad, autentificación y condiciones de informes de error. Durante el protocolo SSL Handshake, el cliente y el servidor intercambian una serie de mensajes para negociar las mejoras de seguridad. Este protocolo sigue las siguientes fases (de manera resumida):

· La fase "Hola", usada para ponerse de acuerdo sobre el conjunto de algoritmos para mantener la intimidad y para la autentificación.         Normalmente se utilizarán los más fuertes que se puedan acordar entre las dos partes. En función de las posibilidades criptográficas del navegador, el servidor elegirá un conjunto u otro de algoritmos con una cierta longitud de claves.(Los datos intercambiados entre el servidor y el cliente se cifran con un algoritmo de cifrado simétrico que  puede elegirse entre DES, tripleDES, RC2, RC4 o IDEA y la clave de sesión se cifra mediante un algoritmo de cifrado de clave pública, típicamente el RSA). Durante la fase de acuerdo o "handshaking", se utiliza RSA (clave pública).

· La fase de autentificación en la que el servidor:

· Envía al navegador su certificado x.509v3 que contiene su clave pública.
· Solicita a su vez al cliente su certificado x.509v3 (opcionalmente si la aplicación exige la autentificación de cliente)

· La fase de creación de clave de sesión:

El cliente envía al servidor una clave maestra, la cual enviará cifrada (usando la clave pública del servidor que obtuvo en la fase anterior ).

· A partir de la clave maestra enviada por el cliente, el servidor generará la clave de sesión (Se
genera una clave de sesión distinta para cada transacción) para cifrar los datos que vienen del y
van al servidor haciendo uso del algoritmo de cifrado simétrico que se acordó en la fase "Hello".

· La fase de finalización :

                            · En esta fase, se verifica mutuamente la autenticidad de las partes implicadas y que el canal  seguro ha sido correctamente
                             establecido.

            Una vez finalizada esta fase, ya se puede comenzar la sesión segura.

Descripción de la fase "Handshake" de manera de más detallada:


 
 

Paso 1: "client_hello". El cliente (browser) abre una conexión con el puerto del servidor y envía un mensaje "ClientHello", listando las capacidades del cliente (versión SSL, cipher suites (opciones de criptografia ) que soporta, y métodos de compresión de datos que soporta).

Paso 2: "server hello". El servidor responde con mensaje "ServerHello", listando los cipher suite (lista de las opciones de criptografía soportadas por el cliente en su orden de preferencia (la opción favorita primero) ) y métodos de compresión que eligió junto con una Id de sesión que identifica la conexión (El server seleccionará un cipher suite o, si ninguna opción aceptable se presenta, devuelva un alerta de fracaso "handshake failure" y cierra la conexión).

Paso 3: "certificate". El servidor envía su certificado X.509. Si está firmado por una autoridad no-raíz, también envía la cadena de certificados hasta llegar al CA primario. A partir de este certificado, se recupera la clave pública RSA del servidor ( "server key exchange").

Paso 4 (opcional): "certificate request". Si el server está prestando un servicio que requiera autentificación del cliente, le pide (al cliente) su certificado X.509.

Paso 5: "server_hello_done". Este mensaje es enviado por el server para indicar la finalización de los mensajes ServerHello y sus asociados. Después de enviarlo el server esperará una respuesta del cliente. Se envía para significar que el server a terminado con los mensajes para soportar el intercambio de claves, y que el cliente puede proceder con su parte.

Paso 6: "certificate". El cliente usa el parte de la información enviada por el server para autentificarlo. A su vez, si al cliente si se pidió su autentificación, manda en esta paso su certificado.

Paso 7: "ClientKeyExchange". Usando todos los datos generados en el handshake hasta ahora, el cliente (con la cooperación del server, y dependiendo del cipher que siendo usado) crea el premaster secret para esta sesión, lo encripta con la clave pública RSA del server (la cual se obtuvo del certificado del server que éste mandó en el Paso 2), y envía el premaster secret encriptado hacia el server (creación de sobre digital).

Paso 8: "Certificate Verify". Si el server requirió la autentificación del cliente, el cliente entonces deberá autentificarse con el servidor diciendo que conoce la clave privada RSA correcta. Para ello firmará el sobre digital del paso 7 (antes de haberlo mandado).

Paso 9: "Change_Cipher_Spec". Si el server requirió la autentificación del cliente, el server intenta autentificar el cliente (ver Autenticación del Cliente para conocer detalles). Si el cliente no puede ser autentificado, la sesión es terminada. En caso afirmativo, el server usa su clave privada para desencriptar el premaster secret, luego lleva a cabo una serie de cálculos (los cuales el cliente también ejecuta, empezando por el premaster secret) para generar el master secret.

Ambas partes (cliente y server) usan el master secret para generar session keys (las claves de la sesión), las cuales son claves simétricas usadas para encriptar y desencriptar la información intercambiada durante la sesión SSL y para verificar su integridad. El cliente envía un mensaje "Change_Cipher_Spec", que confirma que está listo para empezar la comunicación usando la misma clave simétrica

Paso 10: "Finished". El cliente envía un mensaje "finished", con hashes MD5 y SHA de toda la conversación, lo que permite confirmar que sus mensajes fueron recibidos intactos.

Paso 11: "Change_Cipher_Spec". El servidor envía un mensaje "Change_Cipher_Spec", que confirma que está listo para empezar la comunicación usando la misma clave simétrica.

Paso 12: "Finished". El servidor envía un mensaje "finished", con hashes MD5 y SHA de toda la conversación, lo que permite confirmar que sus mensajes fueron recibidos intactos.

- En este momento, el handshake SSL está completo, y la sesión SSL ha empezado. El cliente y el server usan las session keys para encriptar y desencriptar los datos que se mandan uno con otro y para validar su integridad. -

Alert Protocol

Se encarga de transmitir los mensajes de alerta con la correspondiente descripción del alerta. Los mensajes con un nivel fatal dan como resultado la terminación inmediata de la conexión. Igual que otros mensajes, los mensajes de alerta son encriptados y comprimidos.

Change cipher spec Protocol

Este protocolo consiste en un simple mensaje, que es encriptado y comprimido bajo el estado de conexión corriente (no pendiente) .El mensaje consiste en un solo byte con valor 1.

El mensaje Change Cipher Spec es enviado por ambos, el cliente y servidor para notificar la política (party) de recepción de los subsiguientes registros, los cuales estarán protegidos bajo la nueva negociación del ChiperSpec y las claves.

El mensaje Change Cipher Spec es enviado durante el Handshake después que los parámetros de seguridad hayan sido agregados, y justo antes del mensaje "finished" sea enviado.

Algoritmos utilizados

Una gran variedad de algoritmos criptográficos son soportados por SSL. Durante la fase de acuerdo o "handshaking", se utiliza RSA (clave pública). Después del intercambio de claves, se usan unos cuantos algoritmos, entre los que se incluyen RC2, RC4, IDEA, DES y Triple-DES. Como función resumen se usa MD5 o SHA-1. Los certificados siguen el formato X.509.

Implementación

Los diferentes protocolos que utilizan los servicios de SSL usan puertos diferentes a los que les correspondería si no fuesen sobre SSL. La IANA ha reservado los siguientes puertos para su uso por SSL:

433: HTTP sobre SSL (https)
465: SMTP (correo electrónico) sobre SSL (ssmtp), no confirmado.
563: NNTP (servicio de noticias, News) sobre SSL (snntp), no confirmado.


PRÁCTICO

Si SSL parece seguro, pero como se que estoy conectando a un servidor seguro ?

- Para saberlo, hay que verificar los siguientes puntos:

1. Comprobar que SSL esta activado:






2. Verificar la dirección URL:

La presencia de https:// en la barra de direcciones URL de un servidor indica se trata de un servidor "seguro" y que debe utilizarse SSL en la comunicación entre dicho servidor y cliente (navegador).

3. Comprobar el certificado digital :

Los navegadores más extendidos (Netscape Navigator y Microsoft Internet Explorer) son capaces de "hablar" SSL. Esto queda indicado (en el caso de Netscape Navigator) de la siguiente forma:

La llave de la parte inferior izquierda del navegador aparece completa, no partida como habitualmente En el caso de Netscape aparece un candado localizado en la parte inferior izquierda de la barra de estado, mientras que en Internet Explorer aparecerá abajo, en el centro de la barra de estado. Pinchando sobre el candado (O también: En Netscape, deberá seleccionar Ver, Información del documento, y Seguridad.

Con Explorer deberá pulsar sobre Archivo, Propiedades y Certificados) aparecerá una información sobre el sitio web y su certificado : Compruebe que la dirección que aparece en el certificado es la misma que aparece en la ventana de dirección.

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

SEGURIDAD DE SSL

Primeras desventajas (a la vista):

- SSL autentifica al servidor durante la fase en que se establece el protocolo de seguridad. La autentificación del cliente es opcional y no se utiliza firma digital durante el intercambio de mensajes. Por tanto, no es posible implementar funciones de no repudio, hecho que representa una limitación importante del SSL.

- También debe tenerse especial cuidado en decidir qué autoridades de certificación y qué certificados son fiables.

¿Usar SSL en Comercio Electrónico?

SSL constituye la solución de seguridad implantada en la mayoría de los servidores web que ofrecen servicios de comercio electrónico. Su mayor mérito radica en ofrecer respuesta al principal problema que afronta el comercio en línea : La renuncia de los usuarios a enviar su número de tarjeta de crédito [a lo que se suma en España la falta de costumbre de compra por catálogo].

Existe una serie de desventajas al utilizar exclusivamente SSL para llevar adelante ventas por Internet:

· Verificar la validez del número de tarjeta recibido

· Autorizar la transacción con el banco cliente

· Procesar el resto de la operación con el banco adquiriente y emisor.

Lo que el servidor haga con ellos está ya más allá de la competencia de este protocolo. Los datos podrían ser manipulados irresponsablemente o caer en manos de un atacante que servidores comerciales almacenaban los números de tarjeta de crédito entregados por los compradores en ficheros accesibles vía web por cualquier navegador). (SET evita esto con un sistema integrado que cubre toda la transacción, incluyendo autorización de tarjeta y finalización de venta. Para prevenir el robo de números de tarjeta, el protocolo nunca da al comerciante acceso directo al número del cliente; sólo notifica si la compra fue aprobada.)

Todos estos inconvenientes convierten a SSL en una solución deficiente desde el punto de vista del pago electrónico, lo cual no significa que no se deba utilizar ni que no sea útil en otras muchas facetas.

Se hace necesaria la existencia de un protocolo específico para el pago:

                                Este existe y se conoce como SET.

SSL mientras puede usarse como canal seguro para transmitir la información de pago de SET

No puede hablarse en absoluto de SSL como un protocolo de pago seguro, ya que se trata en realidad de un protocolo para comunicaciones seguras de propósito general, en absoluto ideado originalmente para el comercio electrónico.

  • Afortunadamente, al menos con Netscape, es posible soslayar esta grave limitación, ya que se puede adquirir gratuitamente un producto desarrollado en Australia que le permitirá fortificar su navegador, pudiendo usar claves de 128 bits, aunque se trate de una versión de exportación. El programa se llama Fortify y se puede descargar desde http://www.fortify.net

·  Una vez descargado, debe seguir las instrucciones de instalación, y su navegador quedará blindado. La próxima vez que visite un sitio web usando un canal cifrado con SSL, podrá comprobar cómo la conexión se ha establecido utilizando algoritmos de cifrado con claves de 128 bits.

·  Puede comprobar en todo momento la seguridad que incorpora su navegador (tanto en Iexplorer como Netscape) visitando la página de Fortify, que le informará sobre el grado de robustez en el cifrado de su navegador, en www.fortify.net/sslcheck.html

SSL versus S-HTTP

SSL se integra en la capa de sockets, también permite ser usado por otros protocolos  además del HTTP, mientras que el S-HTTP está concebido para ser usado exclusivamente en comunicaciones HTTP. Los servicios de seguridad se negocian a través de las cabeceras y atributos de la página. Por lo tanto, los servicios de S-HTTP están disponibles sólo para las conexiones de HTTP.

A diferencia de S-HTTP, que es un protocolo substitutivo de HTTP, SSL extiende su soporte a otros protocolos habituales en Internet. Esta es una de las principales ventajas que aporta este último. Mientras que S-HTTP proporciona cifrado en el nivel de aplicación (en este caso WWW), SSL lo hace en el nivel de conexión, proporcionando un canal seguro en el nivel de red. Por lo demás, S-HTTP y SSL pueden convivir, utilizándose uno u otro en diferentes instantes de una transacción comercial

 

5. CERTIFICADOS

La criptografía de clave pública trabaja bien sólo si se conoce la clave pública del destinatario de antemano. Pero no se puede guardar la clave pública de todos en una base de datos en el disco duro, ni preguntar al destinatario por su clave pública antes de enviarle un mensaje seguro, porque no hay seguridad de que la persona al otro lado sea quien dice ser.

Aunque nuestros datos viajen cifrados por la Red, si los estamos enviando a (los recibimos de) un impostor, no saldremos mucho mejor parados. Se hace imprescindible el contar con un mecanismo que dé fe de si un servidor seguro es quien creemos que es y podemos confiar en él a la hora de transmitirle nuestra información. La forma como se hace es mediante las Autoridades de Certificación (CA), conocidas informalmente como notarios electrónicos, encargadas de autenticar a los participantes en transacciones y comunicaciones a través de la Red. Su función es emitir certificados a los usuarios, de manera que se pueda estar seguro de que el interlocutor (cliente o servidor) es quien pretende ser, garantizando así la seguridad de las transacciones.

El certificado de seguridad se concede a una entidad después de comprobar una serie de referencias, para asegurar la identidad del receptor de los datos cifrados. Se construye a partir de la clave pública del servidor solicitante, junto con algunos datos básicos del mismo y es firmado por la autoridad de certificación correspondiente con su clave privada. Para aprender más sobre certificados y autoridades de certificación, visitar la página de Verisign: http://www.verisign.com

(Verisign Inc. es líder en el negocio de certificación digital y está reaccionando rápidamente estableciendo relaciones de colaboración, para no perder su liderazgo en el nuevo escenario de servicios electrónicos donde la certificación desempeña un papel fundamental. Verisign, Inc. se creó hace más de un año a partir de RSA Data Securities, aunque su experiencia en el negocio de los certificados digitales es de dos años y medio. Los accionistas de Verisign son: Visa Internacional, Ameritech Corp., Mitsubishi Corporation, Fischer International Systems, Security Dynamics, Bessemer Venture Partners y RSA Data Security, Inc.), En España esta la ACE como autoridad certificadora formada por Telefónica, SERMEPTA, CECA y Sistema 4B, que ofrece entre otros certificación SET).

De esta forma, antes de enviar un mensaje a alguien, se le pide que presente su "certificado digital" que ha sido firmado por uno de estos CAs. Desde el certificado se puede verificar la identidad del destinatario y recuperar su clave pública. Certificados Digitales son inmanipulables e infalsificables.

PASOS A SEGUIR PARA OBTENER UN CERTIFICADO DIGITAL:

1.Generar un par de claves pública/privada.

2.Guardar la clave privada, y enviar la clave pública a un CA, junto con información de identificación, en la forma de un "request de certificado".

3.Pagar la cuota del CA

4.El CA ahora verificará que se es quien dice ser. La verificación puede ser completa o superficial,  dependiendo de las políticas del CA y del tamaño de la cuota.

5.Si todo se comprueba, el CA creará un certificado que contiene la clave pública, junto con información de identificación.

Si es un certificado para usarlo en un Web browser, debe contener el nombre y el e-mail. Un certificado pensado para usarse en un servidor Web, contendrá el URL home del sitio Web.

Por tanto, antes de enviarle a alguien un mensaje seguro, se le pedirá que presente su certificado firmado. Se desencripta el hash firmado con la clave pública del CA para verificar que la clave pública, el nombre, etc. no ha sido alterado desde que fue firmado el certificado. Ahora se puede usar la clave pública para enviar el mensaje sabiendo que es la persona correcta.


Tipos de Certificados

Certificados para autentificar servidores Web son "certificados de sitios";
Certificados para autentificar usuarios individuales se usan "certificados personales"
Certificados como los usados por compañías de software para firmar ejecutables son "certificados de editor de software".
Hay certificados que poseen la clave pública propia del CA, la que es conocida como "certificado de autoridad certificante".

Aunque son usados para diferentes propósitos, todos comparten un formato común conocido como X.509v3 (versión 3 del formato X.509).


CAs Raíz y Cadenas de Certificados.

Web browsers y otros softwares encriptantes son entregados con los certificados firmados preinstalados de una docena de autoridades certificantes bien conocidas , llamados "CAs raíz" y dan certificados que son firmados por ellos mismos.

Además de firmar certificados de usuario final, un CA raíz puede firmar las claves públicas de otros CAs, concediéndoles autoridad para firmar.
Cuando un usuario final presenta un certificado firmado por un CA no-raíz, presenta los certificados de todos los CAs en la cadena firmante.
Esto se llama una "jerarquía de confianza"


Expiración de Certificados y Revocación de Listas.

Claves públicas no son eternas. Eventos que invalidan un par de claves pública/privada, son la pérdida o corrupción de una clave privada, su robo, cambios en la información de identificación contenida dentro del certificado, y el compromiso de la clave privada del CA mismo. Cuando pasa esto, el certificado afectado se revoca y no podrá usarse.

Una parte esencial de la infraestructura de clave pública es la idea de una "lista de certificados revocados" (CRL), una base de datos que guarda los IDs de todos los certificados que se han vuelto inválidos. En teoría, todos los que deseen enviar un mensaje deberían chequear la clave pública del destinatario contra la CRL antes de enviarlo.

En la práctica, esto no pasa en Internet por lo poco práctico de mantener una base de datos CRL maestra. Con la excepción de los certificados de editores de software y algunas intranets, nadie mantiene una CRL accesible en red. En cambio, todos los certificados tienen una fecha de expiración, típicamente un año desde que fueron emitidos. Si alguien presenta un certificado que ha expirado, el software que chequea la validez lo notará. Hay problemas obvios con esperar un año para que el certificado expire, ya que una persona o un sitio Web fraudulento puede continuar usando un certificado revocado sin que nadie lo sepa.

Criptografía de clave pública usualmente va de la mano con autentificación. Sin embargo, es posible para las dos partes establecer sesiones de comunicación encriptada sin usar certificados firmados en absoluto. Por ejemplo, el intercambio de claves Diffie-Hellman permite a las dos partes negociar una clave de sesión sin enviar nunca la propia clave a través de la red.


El formato X.509

En este apartado se describirá brevemente la estructura de los certificados X.509 versión 3 (X509v3). La estructura de certificación propuesta por se basó en la especificación de los certificados X.509 versión 1 (X509), los cuales son deficientes en varios aspectos. Con la versión 3, no hace falta aplicar restricciones sobre la estructura de las CAs gracias a la definición de las extensiones de certificados. Se permite que una organización pueda definir sus propias extensiones para contener información específica dentro de su entorno de operación. Este tipo de certificados es el que usa los protocolos SSL, SET...

·Versión. Indica si la versión del certificado X.509 es la 1 (por defecto), 2 ó 3.

·Número de serie. Es un entero asignado por la CA emisora y que identifica unívocamente al certificado dentro del conjunto de certificados emitidos por la CA en cuestión.

·Firma. Identifica al algoritmo utilizado por la CA para firmar el certificado.

·Emisor. El nombre del emisor identifica a la entidad que ha firmado el certificado y sigue la nomenclatura de nombres distinguibles (DNs, Distinguished Names) de X.500 [X500].

·Validez. Indica el intervalo de tiempo en el que el certificado es válido.

·Usuario o sujeto. Es un nombre distinguible X.500 que identifica de forma unívoca al poseedor del certificado.

·Información de clave pública del usuario. Contiene la clave pública del usuario junto con el identificador del algoritmo con el que se ha de utilizar.

·Identificadores únicos de emisor y de usuario. Es una cadena de bits opcional que identifica al emisor o al usuario en el caso de que su DN sea reutilizado con el paso del tiempo.

·Campos de extensión. Permiten la adición de nuevos campos a la estructura sin que por ello se tenga que modificar la definición ASN.1 del certificado. Cada uno de estos campos consiste en:

- un identificador de extensión,
- un valor que indica si es o no crítico, y
- una codificación canónica de un valor de un tipo ASN.1 asociado con la extensión identificada.

ISO/IEC, ITU y ANSI han definido un conjunto de extensiones estándares para ser utilizadas en los certificados X.509v3:

- Las extensiones estándares pueden dividirse en varios grupos según el aspecto con el que están relacionadas:

6.SET

Transacciones Electrónicas Seguras (Secure Electronic Transaction o SET) es un protocolo estandarizado y respaldado por la industria, diseñado para salvaguardar las compras pagadas con tarjeta a través de redes abiertas, incluyendo Internet. El estándar SET fue desarrollado en 1995 por Visa y MasterCard, con la colaboración de otras compañías lideres en el mercado de las tecnologías de la información, como Microsoft, IBM, Netscape, RSA, VeriSign y otras.

En cuanto el protocolo SET 1.0 estuvo listo, comenzó a emerger una infraestructura basada en el mismo para soportar su uso a gran escala. Ya existen numerosos fabricantes de software que han empezado a crear productos para consumidores y comerciantes que deseen realizar sus compras de manera segura disfrutando de las ventajas ofrecidas por SET.

La Agencia de Certificación Española (ACE) formada por Telefónica, SERMEPA, CECA y Sistema 4B, viene ofreciendo el servicio de certificación SET desde finales de 1998 en España, www.ace.es.


Qué servicios ofrece SET


Quiénes participan en SET

El pago mediante tarjeta es un proceso complejo en el cual se ven implicadas varias entidades:






El funcionamiento de SET en 10 pasos

Una transacción SET típica funciona de forma muy parecida a una convencional con tarjeta de crédito y consta de:

         1. Decisión de compra. El cliente está navegando por la web del comerciante y decide comprar un artículo. Rellenará
            algún formulario y posiblemente hará uso de alguna aplicación tipo carrito de la compra, para ir almacenando diversos
            artículos y pagarlos todos al final. El protocolo SET se indica cuando se pulsa el botón de Pagar.

        2. Arranque del monedero. El servidor del comerciante envía una descripción del pedido que despierta a la aplicación
            monedero del cliente (por ejemplo, Microsoft Wallet).

        3. El cliente comprueba el pedido y transmite una orden de pago de vuelta al comerciante. La aplicación
           monedero crea dos mensajes que envía al comerciante. El primero, la información del pedido, contiene los datos del
          pedido, mientras que el segundo contiene las instrucciones de pago del cliente (número de tarjeta de crédito, banco
         emisor,etc.) para el banco adquiriente. En este momento, el software monedero del cliente genera una firma dual, que
         importa juntar la información del pedido y las instrucciones de pago, de manera que el comerciante puede acceder a la
         información del pedido, pero no a las instrucciones de pago, mientras que el banco puede acceder a éstas, pero no a la
         información del pedido. Este mecanismo reduce el riesgo de fraude, ya que ni el comerciante llega a conocer el número
        de tarjeta, ni el banco sabe los hábitos de compra del cliente.

        4. El comerciante envía la petición de pago a su banco. El software SET en el servidor del comerciante crea una
           petición de autorización que envía a la pasarela de pagos, incluyendo el importe a ser autorizado, el identificador de la
           transacción y otra información relevante acerca de la misma, todo ello convenientemente cifrado y firmado. Entonces se
          envían al banco adquiriente la petición de autorización junto con las instrucciones de pago (que el comerciante no puede
          examinar, ya que van cifradas con la clave pública del adquiriente).

       5. El banco adquiriente valida al cliente y al comerciante y obtiene una autorización del emisor del cliente. El
          del comerciante descifra y verifica la petición de autorización. Si el proceso tiene éxito, obtiene a continuación las
          instrucciones de pago del cliente, que verifica a su vez, para asegurarse de la identidad del titular de la tarjeta y de la
          integridad de los datos.

       6. El emisor autoriza el pago. El banco emisor verifica todos los datos de la petición y si todo está en orden y el titular
          de la tarjeta posee crédito, autoriza la transacción.

       7. El adquiriente envía al comerciante un testigo de transferencia de fondos. En cuanto el banco del comerciante
          recibe una respuesta de autorización del emisor, genera y firma digitalmente un mensaje de respuesta de autorización
         que envía a la pasarela de pagos, convenientemente cifrada, que se hace llegar al comerciante.

       8. Éste envía un recibo al monedero del cliente. Cuando el comerciante recibe la respuesta de autorización de su
        banco, verifica las firmas digitales y la información para asegurarse de que todo está en orden. El software del servidor
        almacena la autorización y el testigo de la transferencia de fondos. A continuación completa el procesamiento del pedido
        del titular de la tarjeta, enviando la mercancía o suministrando los servicios pagados.

    9. Más adelante, el comerciante usa el testigo de transferencia de fondos para cobrar el importe de la
        transacción. Después de haber completado el procesamiento del pedido del titular de la tarjeta, el software del
        comerciante genera una petición de transferencia a su banco, confirmando la realización con éxito de la venta. Como
        consecuencia, se produce el abono en la cuenta del comerciante.

   10. A su debido tiempo, el dinero se descuenta de la cuenta del cliente (cargo).

El protocolo definido por SET especifica el formato de los mensajes, las codificaciones y las operaciones criptográficas que deben usarse. No requiere un método particular de transporte, de manera que los mensajes SET pueden transportarse sobre HTTP en aplicaciones web, sobre correo electrónico o cualquier otro método. Como los mensajes no necesitan transmitirse en tiempo presente, son posibles implantaciones de SET eficientes basadas en correo electrónico u otros sistemas asíncronos.

En su estado actual, SET solamente soporta transacciones con tarjeta de crédito/débito, y no con tarjetas monedero. Se está trabajando en esta línea para extender el estándar de manera que acepte nuevas formas de pago. Al mismo tiempo se están desarrollando proyectos para incluir los certificados SET en las tarjetas inteligentes, de tal forma que el futuro cambio de tarjetas de crédito a tarjetas inteligentes pueda incorporar el estándar SET.


Cómo comprar en Internet de forma inteligente

Nunca debería suministrar información confidencial por Internet sin ningún tipo de protección, especialmente en lo que se refiere a datos financieros. Si está pensando en comprar vía web, pero duda a la hora de suministrar su número de tarjeta de crédito, sepa cuáles son las opciones que se le presentan para hacerlo de forma segura.

Qué se necesita para comprar con SET

El pago mediante el protocolo SET es la opción recomendada por su mayor fiabilidad. Tiene el inconveniente de que en España su implantación es todavía muy limitada, por lo que encontrará pocas entidades financieras que emitan certificados y aún menos comercios que ofrezcan la posibilidad de pago mediante SET, necesitará antes hacerse con dos elementos:


Algunos consejos prácticos

Exija imágenes del producto que piensa adquirir, al menos cuando sea relevante.

Exija información detallada y clara sobre los precios y sobre la forma de envío y coste adicional.

Exija que le expliquen las condiciones de garantía y devolución.


Qué se necesita para vender con SET

Si tiene una tienda virtual en Internet y le gustaría que sus clientes pudieran pagarle utilizando el protocolo SET, necesitará hacerse a su vez con certificados digitales y con software especial:

Dado que SET sólo protege la información de pago de sus clientes, no el resto de la información que envían a su servidor, es altamente recomendable que ofrezca transacciones seguras a través de un canal cifrado con SSL, en la medida en que este servicio resultará cada vez más demandado por los clientes. De esta manera, el resto del proceso de compra (como qué artículos compran, información demográfica, etc.) se mantendrán a salvo de miradas indiscretas.


Algunos consejos prácticos


Comparación entre SSL y SET
 

 

SSL

SET

Pros

Fácil: incluido en la práctica totalidad de servidores y navegadores del mercado

General: sin restricciones en cuanto a los datos que puede mantener privados

Validación mutua entre el comerciante y el comprador

Menor riesgo de fraude por parte del comerciante, con la consiguiente reducción de costes asociados.

Potencialmente menores cargos a los comerciantes (Visa)

Ahorro en los costes de papeleo y gestión de cobros

Contras

Limitado a 40 bits para la mayoría de usuarios fuera de USA y Canadá

No existen mecanismos de no repudio

Se considera forma de pago de riesgo y se carga más

Requiere software especial tanto en servidores como navegadores

Hacen falta certificados independientes para cada tarjeta de crédito


Objetivos y requisitos de SET
 

 

Objetivos

Requisitos

Cliente

Proporcionar confidencialidad de los datos de pago

Autenticar al comerciante para garantizar su identidad

Aumentar la sensación de seguridad de las compras electrónicas

Instalar una aplicación de monedero electrónico

Obtener un certificado SET de cliente

Comerciante

Fácil integración

Aumentar el volumen de comercio electrónico

Reducir los costes de las transacciones

Instalar software SET en el servidor

Obtener certificados SET de comerciante

Banco

Reducir el fraude por los comerciantes

Aumentar el volumen de comercio electrónico

Implantar una jerarquía de certificación

Implantar sistemas de certificados para los titulares de tarjetas

Microsoft Wallet


¿Qué es Microsoft Wallet?

Con Microsoft Wallet 3.0 puede almacenar en su PC información sobre la dirección y el método de pago que utilizará en las transacciones de compra en línea. Puede considerar Microsoft Wallet como el equivalente electrónico de la tarjeta que lleva consigo para las tarjetas de crédito y su identificación. Facilita las compras en Internet al permitirle especificar la dirección y el método de pago una única vez. A partir de entonces, esa información queda almacenada en el equipo y podrá transmitirla a tiendas de Internet compatibles con Wallet cuando se le solicite la dirección de envío o los datos de la tarjeta de crédito al realizar alguna compra. Para enviar o cargar compras a diferentes ubicaciones (por ejemplo, a casa o a la oficina), puede almacenar fácilmente estas direcciones diferentes en Wallet y seleccionar una de ellas durante el proceso de compra utilizando un nombre sencillo, como "Casa de Juan". Si dispone de varias tarjetas de crédito, puede introducirlas y almacenarlas con un nombre descriptivo, como "Visa de María".

Además de comodidad, Wallet proporciona seguridad para proteger la información de pago. La información especificada (como los tipos, números y fechas de expiración de las tarjetas de crédito) se almacena de forma segura en el equipo. Es posible definir una contraseña exclusiva para cada método de pago almacenado, de modo que sólo usted pueda utilizarlo. A continuación, cuando realice compras en un sitio compatible con Wallet, lo único que tendrá que hacer es seleccionar la tarjeta apropiada y escribir la contraseña para pagar.

Wallet consta de dos interfaces diferentes: Address Manager y Payment Manager. Utilice Address Manager para introducir, almacenar y tener acceso a direcciones a las que enviar y facturar un pedido en línea. Los nombres, direcciones de correo electrónico y números de teléfono de los usuarios de Wallet pueden verse en la Libreta de direcciones.

Utilice Payment Manager para introducir, almacenar de forma segura y tener acceso a diversos métodos de pago para abonar las compras en línea. Esta información está protegida por una contraseña definida por el usuario. Al comprar en una tienda de Internet compatible con Microsoft Wallet, el sitio puede pedirle que seleccione los métodos de pago almacenados en Wallet y que autorice el pago mediante la introducción de la contraseña.

Trabajar con Microsoft Wallet

Para tener acceso a Address Manager y a Payment Manager de Microsoft Wallet, siga estos pasos:

        · En Internet Explorer, haga clic en el menú Ver.

        · En el menú Ver, haga clic en el comando Opciones de Internet.

        ·En la ficha Contenido, haga clic en el botón Direcciones para trabajar con la información de direcciones o bien haga clic
          e el botón Pagos para trabajar con métodos de pago e información relacionada.

        · En el cuadro de diálogo que aparecerá, haga clic en Agregar para crear una entrada nueva, haga clic en Editar para
          cambiar una entrada existente o haga clic en Eliminar para quitar una entrada.

Una vez almacenada le información de pago y las direcciones en Wallet, esa información podrá transmitirse durante el proceso de compra en línea a cualquier sitio web de compras que sea compatible con Wallet.

La seguridad en Microsoft Wallet

Toda la información privada contenida en Microsoft Wallet, como números de tarjeta de crédito, está almacenada en su propio ordenador de forma cifrada. Cada tarjeta de crédito que guarde en Wallet está protegida con su propia contraseña separada. Sin ella, alguien que utilice su ordenador sin autorización no podrá obtener la información de su tarjeta de crédito ni podrá usarla para efectuar compras por Internet. De hecho, si pierde u olvida su contraseña, deberá introducir de nuevo toda la información de la tarjeta.

La seguridad mientras transmite la información de Wallet al comerciante en función del protocolo que éste utilice. La mayoría de los comercios en línea confían en SSL para comunicarse con los clientes. En este caso, el número de tarjeta de crédito se extrae en claro de Wallet (sin cifrar) y es cifrado por el navegador utilizando cifrado del canal con SSL. Desgraciadamente, fuera de Norteamérica, se utiliza SSL con 40 bits de longitud de clave, claramente insuficiente para ofrecer garantías de seguridad.

Algunos comerciantes están empezando a utilizar el protocolo SET para procesar de forma integrada el pago. En este caso, la información de pago se cifra antes de ser enviada, de manera que sólo el banco del comerciante puede leerla, quedando inaccesible incluso para el propio comerciante. Microsoft se encuentra actualmente desarrollando una extensión para Microsoft Wallet que soporte el protocolo SET.


Glosario de términos SET


Reflexiones en torno a la seguridad

No debe confundirse SET y SSL, ya que nacen con vocaciones diversas. SSL es un protocolo de propósito general, apto para cifrar cualquier tipo de comunicaciones entre un cliente y un servidor, desde el envío de formularios y páginas web, hasta la transmisión de ficheros y correos electrónicos. Su capacidad para establecer un canal seguro entre dos máquinas ha motivado que sea adoptado para la compra por Internet, principalmente para obtener el número de tarjeta de crédito de los clientes de forma segura. Sin embargo, el uso exclusivo de SSL para aplicaciones comerciales no ofrece todas las garantías exigibles, ya que sólo protege los datos mientras viajan por la red, no una vez en el servidor de destino. Por consiguiente, cómo se gestione la información confidencial almacenada en el servidor es responsabilidad directa del comerciante. Bien por su negligencia, bien por su comportamiento deshonesto, puede darse la situación en que estos datos sean utilizados ilícitamente.

Han saltado a la prensa historias en las que se descubrió que servidores comerciales almacenaban los números de tarjetas de crédito entregados por los compradores en ficheros ¡accesibles vía web por cualquier navegador! Afortunadamente, en nuestros días, la seguridad se ha robustecido considerablemente y no cabe esperar incidentes semejantes. No obstante, incluso el tránsito de los datos está amenazado en España debido a la restricción de exportación sobre la criptografía en productos de propósito general, que obliga a la utilización de navegadores con claves cortas de 40 bits para cifrado y certificados de 512 bits (excepto en aplicaciones financieras de banca electrónica). En estas condiciones, resulta relativamente sencillo reventar una clave y hacerse con la información que protegía.

Por su parte, SET carece de estos inconvenientes citados para SSL. En primer lugar, la firma dual, que vincula el pedido con las instrucciones de pago, impide que el comercio acceda a las instrucciones de pago del cliente (eliminando el riesgo de fraude por cargos indebidos) y que los bancos obtengan información acerca de lo que compra el cliente. Por otro lado, dado que SET está específicamente orientado al pago, no se le aplica la restricción de exportación criptográfica, con lo que sus algoritmos utilizan claves fuertes (o al menos relativamente fuertes: 56 bits para DES y 1024 para los certificados), asegurando ahora sí la invulnerabilidad de los cifrados. SET se centra en el pago, por lo que otros aspectos quedan al descubierto. En este escenario cabe considerar la sabiduría de conciliar SSL y SET en una misma aplicación comercial. En primer lugar, la cooperación más inmediata consistiría en utilizar SSL como canal seguro para transmitir la información de pago de SET.

De esta manera se estaría añadiendo doble protección al sistema de pago. En segundo lugar, se han resaltado algunas carencias de SET a la hora de ofrecer una solución integral a la relación comercial entre el cliente y el vendedor, ya que se centra exclusivamente en el proceso de pago.

Es muy aconsejable que cualquier información confidencial intercambiada entre clientes y comerciantes se haga a través de canales seguros. De hecho, nunca debería transmitir datos privados si no es a través de un canal seguro. Píenselo la próxima vez que rellene un formulario, lo haga si no es en una página segura. Comience a pedir SSL y SET en sus transacciones por Internet.

¿Cuáles son los principales retos a los que se está enfrentado a la actualidad y qué están frenando su adopción como estándar generalizado de pago?

En primer lugar, su despliegue está siendo muy lento. SET exige software especial, tanto para el comprador (aplicación de cartera electrónica, como por ejemplo Microsoft Wallet, con el que los usuarios de Internet Explorer pueden estar ya familiarizados) como para el comerciante (aplicación POST o terminal punto de venta). La creación y comercialización o distribución gratuita, según el caso, de estos productos software se está desarrollando con lentitud, no existe suficiente información al respecto y en general la situación es cuando menos confusa.

En segundo lugar, aunque los productos anteriores cumplan con el estándar SET, esto no implica necesariamente que sean compatibles. Este es un problema que exige mayores esfuerzos de coordinación y más pruebas a escala mundial para asegurar la interoperabilidad. Hoy en día es difícil encontrar una aplicación cartera que pueda comprar con cualquier terminal POST, y viceversa (un terminal de punto de venta que acepte pagos de cualquier otra aplicación cartera). Estas barreras constituyen un obstáculo importante que seguirán retrayendo el despliegue de SET en tanto no se alcance la convergencia de aplicaciones.

Sus puntos fuertes son también su talón de Aquiles: la autenticación de todas las partes exige rígidas jerarquías de certificación, ya que tanto los clientes como comerciantes deben adquirir certificados distintos para cada tipo de tarjeta de crédito, trámites que resultan engorrosos, cuando no esotéricos, para la mayoría de los usuarios. Se añade el problema de la revocación de certificados, la difícil portabilidad de los mismos cuando el usuario trabaja en distintas máquinas y las cadenas de certificación. En definitiva, SET descansa sobre una infraestructura de clave pública (PKI) que en la actualidad dista mucho de ser perfecta.

Sin embargo, SSL y SET no son las únicas formas de pagar mediante tarjeta de crédito hoy en día, existen otras como CyberCash.

7. IPSEC: Protocolo de seguridad IP (Aplicación de seguridad en el nivel de Red).


7.1.1 Introducción

IPSEC es una extensión del existente protocolo de red IP para proteger paquetes IP de modificaciones y cortes. Para operar en la capa de red, la protección de IPSEC no interfiere con las existentes aplicaciones software o protocolos, y los paquetes protegidos por IPSEC pueden ser manejados por los existentes routers y encaminadores.

IPSEC es diseñado para proveer protección de privacidad y confidencialidad en cualquier de los tipos de tráfico de Internet. IPSEC define dos opcionales cabeceras de paquetes, uno para cada tipo de protección. Ambas cabeceras contienen un valor numerico llamado el indice de parametro de seguridad (security parameter index SPI). Cuando el host procesa una cabecera IPSEC usa el SPI para identificar la cripto llave y el procedimiento usado con ella. Un paquete puede contener uno o ambas cabaceras. Dependiendo de cuales son los servicios de seguridad que son añadidos. En la practica la mayoria de los paquetes usan ambos.

Como el ESP, el Authentication Header (AH) provee información de autentificación e integridad así que nosotros detectamos si el contenido de los paquetes son falsificados o modificados a través de la red.

A excepción del ESP, el AH no provee privacidad. El no provee encriptación.

¿Por qué renunciar a la encriptación?. La privacidad, también llamada confidencialidad, es de extrema importancia. Se argumenta para esto el que el AH evite el tener problemas con las restricciones de los Estados Unidos en lo referente a mensajes enviados y recibidos fuera y dentro de los Estados Unidos y en hardware y software vendido a otros paises.

El AH contiene un checksum criptográfico para comprobar si en realidad los paquetes no son cambiados. Si los contenidos de los paquetes fueron en efecto cambiados, la computación del checksum fallaría. El checksum criptográfico incorpora información de llaves secretas así que el atacante no puede computar un checksum alterno que se chequee correctamente.
 
 

Añadido después de la principal cabecera IP, esta cabecera provee autentificación, integridad (ser capaz de detectar si el paquete IP ha cambiado), y privacidad(inhabilita a otros para leer el mensajes porque ellos han sido encriptados).

En el lugar de requerir algoritmos específicos para alcanzar estos objetivos (firmas digitales deberían ser usadas y dar alguna otra dirección general), la cabecera ESP puede usar cualquier de varios aceptables protocolos. Por supuesto, esto significa que cuando dos sistemas comiencen la comunicación, ellos deben negociar cuales algoritmos de ellos serán usados para diferentes propósitos. Nosotros describiremos el proceso abajo.

El formato del ESP varía acorde al tipo y modo de la encriptación que está siendo usada. En todos los casos la llave asociada con la encriptación es seleccionada usando el SPI.
 
 

7.1.2  Modo de Operación.

Tanto el ESP como el AH pueden ser usados en dos modos: Tunneling, Transport Mode.

En el tunneling, el paquete IP entero es encriptado y entonces siguado dentro de otro paquete IP. Mirandolo de otro modo, el paquete entero IP es encriptado y una nueva cabecra IP es añadida.

La dirección de destino de internet en la añadida cabecera IP debe ser un host, pero puede ser una entrada de seguridad (security gateway), tal como un cortafuegos o un router habilitado. De esta manera, incluso si un paquete es capturado, el interceptor no leerá mucho por examinación de la dirección de destino. El interceptor no será capaz de decir cual host detrás de la entrada de seguridad (security gateway) recibirá el paquete IP.
 
 

En el modo de transporte, el paquete IP es enviado directamente a destino sin ser encapsulado. La cabecera principal IP es seguida por el ESP o la cabecera AH y entonces por el resto del paquete IP (encriptado en el caso de ESP).

7.1.3 Negociación.

Cuando dos hosts empiezan a comunicarse, o si un host conecta a una entrada de seguridad (security gateway) tal como un router o un cortafuegos, las dos dispositivos deben establecer una asociación de seguridad. Una asociación de seguridad es una relación que describe como dos partes usarán los servicios de seguridad. Es decir se establecerá el que y el cómo de la protección IPSEC: que tipo de protección a aplicar, como hacer la encriptación o autentificación, cuales llaves necesitan ser usadas, el algoritmo de autentificación que será usado.

La asociación de seguridad es un concepto en una dirección. Si hay dos dispositivos, A y B, dos asociaciones de seguridad deben establecerse. Una gobernará como A transmite a B. La otra gobernará como B transmite a A. Estos usualmente son lo mismo, pero ellos pueden ser diferentes.

La asociación de seguridad que se aplica a una cabecera dada IPSEC es determinada por la dirección IP del destino del paquete y el SPI en la cabecera del paquete. El software IPSEC debe mantener la siguiente información de cada SPI:
 
 

  1. Especificación de los métodos criptográficos a ser usados por ese SPI.
  2. Llaves para ser usadas por cada método criptográfico cuan se procesa el tráfico para esa SPI.
  3. El host otras entidades asociadas con este tráfico. Esta información ayuda a distinguir asociaciones de seguridad si sucede que dos o más host asignan un idéntico SPI.

Para la administración de la asociación de seguridad, IPSEC usa ISAKMP (Internet Security Association Key Management Protocol). Como el nombre sugiere, este estándar gobierna como la asociación de seguridad será administrada.

Dando la pasada historia de algoritmos que han fallado a ser seguros como originalmente prometieron, ISAKMP evita especificación de estandar y es un general modo para dos dispositivos para negociar los parámetros de la asociación de seguridad. ISAKMP provee un general mecanismo para establecer asociaciones de seguridad, modificarlas, y borrarlas.

ISAKMP describe como un dispositivo puede decir al otro dispositivo que alternativas de seguridad puede soportar y preferir. Por intercambio de tal información, los dos lados pueden rápidamente ponerse de acuerdo sobre cuales servicios ellos usarán y que algoritmos usarán para cada servicio.
 
 

Aunque ISAKMP administra la mayoría de los aspectos del inicial intercambio entre dos dispositivos, este no administra el intercambio de llaves – el establecimiento de llaves especificas para algoritmos de seguridad que la pareja en comunicación han seleccionado. Se llama al OAKLEY para tal propósito. Porque ISAKMP y OAKLEY son tan cercanamente relacionados, ellos son usualmente referidos como ISAKMP/OAKLEY.

Aunque OAKLEY puede soportar múltiples aproximaciones de intercambio de llaves, la mayoría de las firmas usan del protocolo de acuerdo de Diffie-Hellman.
 
 

La característica innovadora del acuerdo de llaves de Diffie-Hellman es que incluso si un interceptor interrumpe el intercambio de comunicación entre dos parejas comunicantes, el interceptor no puede hacer nada malo. El intercambio de llaves no es suficiente para reconstruir las llaves comunes.

Para ver como Diffie-Hellman trabaja, supón que hay dos partes que desean comunicarse. Nosotros las llamaremos Parte 1 y Parte 2.

Primero, usando el algoritmo Diffie-Hellman, cada parte genera una cadena que tiene dos partes- una parte secreta y una parte publica. La Parte 1 genera la parte secreta a y la publica A. La Parte 2 entonces genera la parte secreta b y la parte publica B. Las dos partes intercambian sus partes públicas. Parte 1 transmite A a la Parte 2, y la Parte 2 transmite B a la Parte 1.

Como su nombre indica, A y B son públicas, como llaves publicas. No hay necesidad de encriptarlas. Interceptandolas no se hace ningún mal porque el conocimiento de A y B no es suficiente para generar la firma secreta, x, la cual será usada para encriptar las subsiguientes transacciones.

No obstante gracias a un ingenioso algoritmo, es posible generar la llave secreta x de a y B. La Parte 1 genera la parte secreta a, y la Parte 2 envía la parte pública B, así la Parte1 puede determinar x. Es también posible generar la llave secreta x de b y A. La Parte 2 tiene esta información y así puede generar x. De esta forma mediante el intercambio de información publica. Los dos lados pueden ponerse de acuerdo sobre una secreta llave de sesión x. Esto es por lo que se llama acuerdo de llaves.
 

7.1.4.    Un Producto Ejemplo: IPSEC Cliente.:

 

Un IPSEC Cliente es un paquete que provee protección IPSEC para el trafico en una red TCP/IP en una estación de trabajo o en un ordenador portatil. Este producto proporcionará protección sin afectar al comportamiento de aplicaciones esistentes o

drivers de dispositivos. La protección es aplicada de acuerdo a las asociaciones de seguridad establecidas por las estaciones de trabajo operadoras. Por ejemplo productos que IPSEC Cliente incluyen son Secure Computing’s NetCourier y FTP Software’s Vip Secure Client.

Alicia produce un mensaje para Bob usando una aplicación TCP/IP. La aplicación pasa el mensaje a una pila TCP/IP. Como los paquetes individualmente pasan a través del procesamiento IPSEC, ellos son protegidos si es requerido por la asociación de seguridad establecida. La capa de enlace de datos recibe los paquetes protegidos para transmitirlos al receptor del mensaje, Bob. La capa de enlace de datos en la maquina de Bob pasa los paquetes arriba a lo largo de las capas del protocolo, hasta que ellos alcanzan le procesamiento IPSEC, donde las cabeceras IPSEC son procesadas, validadas y eliminadas. La aplicación software de la maquina de Bob recibe los datos de Alicia.

También se pueden observar diferentes aproximaciones para construir e integrar IPSEC en el software de las estaciones de trabajo. En la aproximación "upper stack" (pila de más arriba), IPSEC es integrada directamente en la pila TCP/IP, mientras en la aproximación "lower stack" (pila de más abajo) es un separado paquete entre la pila TCP/IP y los drivers de los dispositivos de la red. Mientras que cualquiera de los paquetes (de las dos aproximaciones) deberían ser capaces de interoperar con cualquiera de las otras partes del diseño, estas diferentes aproximaciones tienen diferentes beneficios.

La aproximación upper stack es mejor para sofisticados sistemas como Unix o Windows NT, desde que ellos pueden permitir software con diferentes atributos de seguridad para usar separadamente en asociaciones de seguridad. Por ejemplo, un operador de una estación de trabajo podría querer ejecutar sin una protección IPSEC en la mayoría de los casos, pero requiere encriptación IPSEC cuando opera en un role administrativo como un root. La asociación entre los datos de la red y el usuario que los creo son mejor preservados en niveles más alto de los protocolos de pila. No obstante, en la implementación upper stack debe ser integrado dentro del mismo software del protocolo TCP/IP. Esto produce una mayor complejidad y fuerza a los usuarios a reemplzar la pila TCP/IP que ellos actualmente usan. Esto no es siempre una alternativa realista.

En la aproximación "lower stack", IPSEC aparece en el punto más bajo en la pila de protocolo, típicamente entre los drivers de los dispositivos de enlace de datos y una existente pila de red TCP/IP. Esta aproximación a menudo se refiere a ella como una capa. David Wagner y Steve Bellovin usaron la frase "bump in the stack" ("trompazo en la pila") para describir una implementación piloto que ellos desarrollaron usando esta aproximación. Esta capa usa la interfaz de los driver de dispositivos entre la existente pila TCP/IP y los drivers de dispositivos. Esto generalmente es una muy bien definida interfaz. Al contrario que la implementación upper stack, la capa no reemplaza la existente pila TCP/IP. Esto salva al usuario del dilema de elegir entre los beneficios de seguridad de IPSEC y los beneficios operacionales de otras implementaciones TCP/IP. También la capa es generalmente un componente software más simple para construir y mantener que un paquete incluyendo el soporte completo TCP/IP.

Balanceando en contra de estos beneficios, la capa fuerza a un manejo muchos más rígido de las asociaciones de seguridad. La capa puede forzar solamente asociaciones de seguridad en los niveles de dirección IP de host, ya que esta es la única información que tiene para hacer sus decisiones. La identidad de un usuario no puede ser asociada con los datos de la red ya que tal información es perdida en esos niveles más bajos de la pila TCP/IP.

El empaquetamiento de un IPSEC client no es realmente indicativo si la implementación es un upper stack o lower stack. Mientras que una capa siempre estará en las implementaciones más bajas de la pila, IPSEC integrado en la pila de red TCP/IP no siempre provee una implementación upper stack. Algunos vendedores han usado como referencia la implementación lower stack para añadir IPSEC a un existente pila TCP/IP. El producto resultante es empaquetado como una implementación upper stack pero comportándose como una implementación lower stack. Dado este estado de cosas, es más seguro asumir que los típicos productos IPSEC provean capacidades lower stack y, en lo mejor, soporte de asociaciones de seguridad basadas en host.

7.1.5. IPSEC como forma de seguridad en la WEB:

La seguridad en el nivel de red, como IPSEC, es a menudo vista como un general antídoto a los defectos de seguridad de passwords. IPSEC puede bloquear una variedad de importantes amenazas en el tráfico de Internet como el secuestro, robo y la inundación. No obstante su tendencia a proveer seguridad en todo o nada, provee un número de defectos prácticos cuando se usa IPSEC para proteger transacciones Web. Así, mientras provee la protección comentada anteriormente, él también bloquea accesos a hosts que no soportan o no tienen una asociación de seguridad con tu propio host. IPSEC puede ser instalado debajo del software Web así que la protección no requiere cambios en el servidor Web o el paquete software del cliente. No obstante, la protección de IPSEC en la capa de red es generalmente aplicada a todo el tráfico entre el cliente y el servidor, y no solamente a transacciones. Esto tiene dos problemas. Primero, es ineficiente aplicar criptografía a todo el tráfico Web entre el cliente y el servidor. El tráfico Web tiende a llevar muchos datos y no requiere protección. El procesamiento criptográfico tiende a relentizar cosas y la efectividad generalmente depende en la rapidez de los tiempos de respuesta. El segundo problema es que nosotros incrementamos el riesgo de falsas transacciones si nosotros encriptamos cada cosa. Si todo el tráfico es tratado como una transacción, entonces es más fácil confundir un error o una transacción falsa por una legitima.

Otro defecto de IPSEC esta en el mantenimiento de las llaves. El común denominador de la mayoría de las implementaciones IPSEC es todavía el de llaves secretas. Esto no es una practica técnica para proteger transacciones entre arbitrarios clientes y vendedores. Incluso entre los más sofisticados protocolos de mantenimiento de llaves todavía esperamos que ambos cliente y servidor tengan su propio material de llaves y que hayan sido validadas por una tercera parte. Esto excede la sofisticación de la mayoría de usuarios de Internet.

7.1.6. Perspectivas de IPSEC.

Dado la creciente importancia de la seguridad en Internet, especialmente en redes virtuales privadas y extranets, el desarrollo de IPSEC ha sido seguido con ansiosa anticipación. Incluso antes de que el estándar fuera completamente especificado, hubo una demostración de la interoperatibidad de los productos IPSEC en la Automove Network Exchange(ANX), que era un proyecto de demostración diseñado par mostrar como 8.000 suministradores podían comunicarse con los constructores de coches.

En general, donde IPSEC ofrece opciones, él presenta lo que es generalmente considerado ser una aceptable lista de estándares de los cuales seleccionar.

Una debilidad de IPSEC es que solamente focaliza en la seguridad de la capa de red. Una brillante mancha es que el estándar ISAKMP no es limitado a la capa de red. Este establece un método para mantenimiento de asociaciones de seguridad y llaves en cualquier capa.

Otra conocida debilidad es que requiere certificados digitales. No obstante, al contrario de SET, nosotros carecemos de una buena arquitectura de certificados digitales que controle los certificados de autorización y sus relaciones mutuas.

Una debilidad final es que IPSEC es diseñado para redes TCP/IP. Otros protocolos de internet, tales como IPX, pueden ser encapsulados dentro del diagrama IP, pero esta en un área de desarrollo inferior. No obstante IPSEC ofrece una comprension limpia y muy estandarizada del modo de mantenimiento de seguridad en redes virtuales privadas sobre Internet en entornos de redes TCP/IP.

8. Otros Protocolos de Seguridad.(Otros Protocolos de Seguridad de redes TCP/IP).

Aquí esta un resumen de otros protocolos de seguridad desarrollados para TCP/IP para ser integrados en protocolos de red. Estas técnicas son generalmente aplicadas por encima de interface de driver de dispositivos o debajo de interfaces de socket. Algunos incluso no implican el uso de criptografía. Proveen seguridad sin afectar al comportamiento del software de las aplicaciones. El software existente y los procedimientos de las operaciones permaneceran sin ser afectadas, excepto las interacciones que no seguras pudiendo ser bloqueadas.

8.2.1 IPSO: IP SECURITY OPTION.

El IP security option (IPSO) es una evolución de una serie de protocolos que insertan "etiquetas sensitivas" en los paquetes IP. Estas etiquetas trabajan en conjunción con construciones especiales, router de gran confianza y otros componentes de la red que previenen a la información sensitiva de alcanzar destinos con no mucha confianza (no muy seguros). Estos protocolos no protegen la información en si misma mientras esta en transito, es decir, desde IPSO no se incorpora cualquier forma de protección criptográfica. IPSO simplemente pone marcas en los paquetes para prevenir a la información sensitiva de alcanzar una localización peligrosa. No provee ninguna protección si los datos sensitivos en realidad se encuentran con la menos confiable red o host. Los protocolos relacionados con IPSO incluyen Commercial IPSO (CIPSO), revised (RIPSO), y DNSIX (usado en operaciones militares).
 
 

8.2.2 SDNS: Secure Data Network System.

El Secure Data Network System es una familia de protocolos desarollatos para proveer de protección criptográfica al tráfico de redes en una variedad de protocolos de capas. Trabaja en protocolos de nivel de aplicación produciendo el Message Security Protocol (MSP), el cual evoluciono del PEM (Privacy Enhanced Mail: un protocolo de criptación de e-mail publicado por el IETF y proveído por algunos productos commerciales). Los protocolos fueron propuestos para trabajar con los protocolos de internet, pero el principal objetivo durante el desarrollo fue proveer una seguridad fuerte para los protocolos de red ISO (International Standars Organizzation).

El proceso de desarrollo del protocolo SDNS fue largamente patrocinados por la NSA con el objetivo de proteger las comunicaciones sensibles del gobierno los Estados Unidos y las cumunicaciones militares. Un puñado de productos de seguridad de propósito especifico fueron desarrollados usando los protocolos. Unas adicionales implementaciónes base en host fueron desarrolladas durante una serie de demostraciones de proyectos de tecnológicos en los 80’s. Hoy, el protocolo HannaH de SecureWare es uno de los pocos de los productos restantes basados en protocolos SDNS de más bajo nivel.

El protocolo SP3 (protocolo de seguridad SDNS en el nivel 3, nivel de red) fue diseñado para proveer similar protección a los protocolos IPSEC. Ciertamente las características del formato ESP son muy similares a las de SP3. Sin embargo SP3 no provee una cabecera separada de autentificación.

El protocolo SP4 (protocolo de seguridad SDNS en el nivel 4, nivel de transporte) fue diseñado para proveer seguridad en la capa de transporte, En efecto, aplica servicios criptográficos sockets en lugar de paquetes. Esto lo hace similar en diseño y aplicación al protocolo SSL.

Quizas desde la perspectiva de hoy los protocolos SDNS deberían haber apelado a los vendedores y haber sido incorporados en productos antes de que el IPSEC apareciera. Dos factores probablemente contribuyeron a su fracaso comercial. Primero, había relativamente poco potencial para el uso del comercio en Internet cuando el protocolo SDNS evolucionó. Algunas redes incorporaron Internet prohibiendo explicitamente el uso comercial. Ningún usuario no comercial de Internet tenía poco para proteger, asi los vendedores tenían poco mercado para asegurar productos. Segundo, el protocolo legado con la NSA de los ochenta hacía difícil el despliegue comercial. Aunque el protocolo fue en realidad publicado por el National Intstitute of Standars and Technology (NIST), como un protocolo estándar del gobierno de los Estados Unidos, muchos de los trabajos técnicos fueron cercanamente sostenidos por la NSA.

8.2.3 Network Layer Security Protocol (NLSP)

ISO combino esta variante del protocolo SP3 en su juego de protocolos OSI. Desfortunadamente, este protocolo sufrío de lo que un observador antipatico podría llamar la enfermedad de OSI de dar desarrollo a demasiadas opciones. Sin un centrado, bien definido conjunto de necesarios servicios intimidaba demasiado para vendedores para diseñar y construir productos compatibles.

8.2.4 Point-To-Point Tunneling Protocol (PPTP).

Este protocolo es una extensión del protocolo Point-to-Point Protocol (PPP), el cual es un protocolo de elección cuando se conectan modems series al ISPs. (Proveedor de Servicios de Internet). PPTP intenta actuar como un simple, coherente protocolo de enlace. Esto le permite llevar una variedad de protocolos de redes de Internet y no Internet entre los dispositivos que los soportan.

PPTP y PPP no proveen por ellos mismos servicios de criptografía. Tales protecciones son definidas por extensión de protocolos. Se puede combinar un protocolo de tunneling y servicios criptográficos para proteger el trafico entre sites. Esto provee los esenciales bloques de construcción para un VPN (una red privada construida sobre un red publica. Los hosts dentro de la red usan encriptación para hablar a otros hosts. La encriptacion excluye hosts de fueras de la red privada incluso si ellos estan en la red publica). Varios vendedores, incluyendo Microsoft, han formado un grupo llamado PPTP Forum que esta desarollando un perfil de un protocolo estandar que incluya protección criptográfica. En la actualidad, Microsoft esta recomendado PPTP como una general solución para la construcción de VPNs y ha anunciado planes para integrarlo en futuros productos.

 

 

Hosted by www.Geocities.ws

1