Int. Cl.: 74 Agente: Justo Vázquez, Jorge Miguel de

Loading....

Loading....

Loading....

Loading....

Loading....

Texto completo

(1)

PATENTES Y MARCAS ESPAÑA 51

Int. Cl.: H04L 29/06(2006.01) 12

TRADUCCIÓN DE PATENTE EUROPEA T3

86

Número de solicitud europea:04290996 .0 86

Fecha de presentación :14.04.2004 87

Número de publicación de la solicitud:1587273 87

Fecha de publicación de la solicitud:19.10.2005

54

Título:Procedimiento de establecimiento de sesiones protegidas.

45

Fecha de publicación de la mención BOPI: 16.04.2008

45

Fecha de la publicación del folleto de la patente: 16.04.2008

73

Titular/es:FRANCE TELECOM 6, place d’Alleray

75015 Paris, FR

72

Inventor/es:Frisch, Laurent y Ondet, Olivier

74

Agente:Justo Vázquez, Jorge Miguel de

Aviso: En el plazo de nueve meses a contar desde la fecha de publicación en el Boletín europeo de patentes, de la mención de concesión de la patente europea, cualquier persona podrá oponerse ante la Oficina Europea de Patentes a la patente concedida. La oposición deberá formularse por escrito y estar motivada; sólo se considerará como formulada una vez que se haya realizado el pago de la tasa de oposición (art. 99.1 del

2

295

796

(2)

5 10 15 20 25 30 35 40 45 50 55 60 65 DESCRIPCIÓN

Procedimiento de establecimiento de sesiones protegidas.

La presente invención concierne a las técnicas de intercambio protegido entre unidades de comunicación, y más particularmente al establecimiento de sesiones protegidas entre estas unidades.

Un contexto de aplicación representativo es aquel donde un internauta se conecta, por medio de un navegador web instalado en un terminal cliente, a un servidor que alberga un sitio web protegido apto para prestar un servicio en línea (banco en línea, comercio electrónico, etc.).

Las sesiones protegidas son comúnmente establecidas por medio de protocolos conocidos como por ejemplo:

• SSL (“Secure Sockets Layer”) definido por la sociedad Netscape Communications Corporation. Su ver-sión 3 (SSLv3) es descrita en “The SSL Protocol-Version 3.0”, Internet Draft, IETF, noviembre 1996. Este protocolo está destinado a proteger las comunicaciones entre dos aplicaciones, lo más frecuente un ser-vidor web y un navegador. El mismo está ampliamente extendido y es compatible con la mayoría de los navegadores web.

En la arquitectura en capas de la red, el protocolo SSL está por encima de la capa TCP/IP (“Transmisión Control Protocol/Internet Protocol”), y frecuentemente por debajo de un protocolo de capa superior tal como http (“Hypertext Transfer Protocol”).

El mismo permite garantizar la identidad del emisor y del receptor (autentificación), así como la confiden-cialidad y la integridad de las informaciones intercambiadas por un protocolo de capa superior;

• TLS (“Transport Layer Security”) que es un análogo de SSL normalizado por el IETF (“The TLS Protocol-Version 1.0”, RFC 2246, enero 1999). La versión 1.0 de TLS es sensiblemente equivalente a SSLv3;

• WTLS (“Wireless Transport Layer Security”), que es una adaptación de SSL/TLS al universo WAP (“Wi-reles Application Protocol”).

Los protocolos SSL, TLS, y WTLS, que funcionan esencialmente de la misma manera, serán designados en lo ade-lante por medio de la denominación genérica de “SSL”. Estos protocolos comprenden el uso de sistemas criptográficos que garantizan las condiciones de seguridad requeridas.

El objeto fundamental que permite tener confianza en la parte pública de una clave criptográfica (clave pública) es el certificado. El estándar de certificado utilizado en numerosas redes de Internet es X.509, versión 3. Una especificación de la misma es suministrada por el grupo de trabajo PKIX del IETF (“Internet Engineering Task Force”) en la Request For Comments (RFC) 3280. “Internet X.509 Public Key Infrastructure; Certificate and Certificate Revocation List (CRL) Profile” publicada en abril del 2002. El certificado es un objeto que comprende fundamentalmente:

• la clave pública a certificar;

• la identidad de su poseedor, por ejemplo el nombre del servidor que alberga un servicio en línea;

• un periodo de validez

• eventualmente extensiones, por ejemplo, informaciones que permiten el control de revocación;

• una firma criptográfica de esos datos por medio de la clave privada de una Autoridad de Certificación (AC) emisora del certificado.

Tener confianza en la clave pública asociada a una identidad garantiza la validez del certificado. Para PKIX, un certificado es válido en un instante T determinado (en términos de confianza):

• si es explícitamente declarado como “certificado de confianza”. En la práctica, los certificados de los usua-rios y de los servidores nunca son declarados confiables. Se declara más bien un número reducido de certificados, que consisten en los certificados de algunas AC;

• si verifica las condiciones siguientes:

la firma criptográfica del certificado es matemáticamente válida; el instante T forma parte del periodo de validez del certificado; el certificado no es revocado en el instante T;

(3)

5 10 15 20 25 30 35 40 45 50 55 60 65

la clave pública de la AC emisora está disponible mediante un certificado de la AC, y ese certificado de la AC es válido en el instante T.

Un certificado es revocado en un instante TR de su periodo de validez, si a partir de ese instante, la AC que lo ha emitido tiene dudas acerca del compromiso de la clave privada asociada al certificado. El objetivo es invalidar el certificado a partir de TR. En la práctica, este es el caso cuando el usuario del certificado declara la pérdida o el robo de su clave privada asociada a la clave pública certificada, cuando la AC no desea certificar más la clave del usuario (por ejemplo, cuando un empleado abandona una empresa), etc.

De acuerdo con el PKIX, un certificado revocado debe ser puesto en una lista de revocación (CRL, “Certification Revocation List”) que es una lista, firmada por una AC, de certificados emitidos y después revocados por esa AC. En teoría, una AC no debe nunca retirar un certificado de una CRL. Por ejemplo, si una firma es emitida en un instante T con un certificado revocado en T, es necesario poder controlar de manera permanente que el certificado sea bien revocado en T y por consiguiente la firma invalida. Sin embargo, para certificados que no sirven al no rechazo (por ejemplo codificación o autentificación), retirar un certificado de una CRL puede justificarse en general después de su expiración.

Existen dos medios comunes para controlar la no revocación de un certificado determinado:

el acceso a la CRL. El verificador del certificado carga a distancia la CRL a un servidor, verifica la firma de la CRL y posteriormente busca el certificado a verificar en la CRL;

el control de no revocación en línea. Con el fin de evitarle al verificador efectuar la carga a distancia de los CRL potencialmente voluminosos, se ha definido un protocolo para efectuar el control sobre solamente uno o varios certificados. Se trata del protocolo OCSP descrito en la RFC 2560, “Internet X.509 Public Key Infrastructure; Online Certificate Status Protocol-OCSP”, publicada en junio de 1999 por el IETF. De acuerdo con ese protocolo, el verificador del certificado dirige una petición OCSP a un servidor OCSP dependiendo de la AC emisora, recupera la respuesta OCSP firmada proveniente de ese servidor, verifica la firma de la respuesta OCSP y analiza dicha respuesta.

La utilización de OCSP es en línea. La utilización de los CRL se realiza, ya sea en línea, o fuera de línea pero con actualización regular de los CRL. Un certificado puede incluir medios para verificar en línea su propia validez. Estos medios consisten por ejemplo en la indicación de un punto de distribución de la CRL o de una dirección de un servidor OCSP.

En SSL, después de una fase de inicialización (“handshake”), el cliente y el servidor pueden intercambiar datos en una sesión SSL. El caso más común de utilización de SSL es el del protocolo https, que consiste en utilizar el protocolo del web (http) en una sesión SSL. En el curso del handshake, el servidor se autentifica ante el cliente utilizando la clave privada asociada a su certificado X.509. Si lo desea, el servidor puede solicitar al cliente autentificarse: en ese caso, este envía la lista de los AC que él reconoce como AC de confianza. Entonces, el cliente se autentifica utilizando la clave privada asociada a un certificado aceptado por ese servidor, y transmitiendo los eventuales certificados intermediarios para relacionarse con una de las AC de confianza.

Un inconveniente mayor en términos de ejecución es que el establecimiento de una sesión de un protocolo prote-gido con autentificaciones mediante certificados es prolongado, penalizando así a los usuarios de estos protocolos. De parte del cliente, esto es resultado en gran parte de la verificación del certificado del servidor.

Esta operación de verificación es prolongada. De acuerdo con el caso, la latencia principal tiene causas diferentes, fundamentalmente:

duración de las operaciones criptográficas de verificación. Esta duración es generalmente considerada como despreciable en una computadora personal (PC), aunque esta pueda resultar prolongada de acuerdo con el algoritmo utilizado. Pero la misma es mucho más sensible en entornos restringidos (PDA, teléfono móvil); duración del control de revocación. Esta duración sólo interviene cuando existe efectivamente un control de la revocación del certificado del servidor, incluso de las AC. Si esta operación es inducida a extenderse, no es actualmente muy utilizada, fundamentalmente a causa del costo de ejecución. De acuerdo con el modo de control de revocación utilizado, el costo es diferente. Con el uso de CRL, existe la latencia entre la petición de CRL y la respuesta (en particular en redes de bajo débito y con gran latencia, tipo GSM), la latencia vinculada a la carga de la red y al tamaño potencialmente importante de la CRL, el tiempo de verificación de la firma de la CRL y el tiempo de búsqueda de un certificado en la CRL. Si el control de revocación utiliza OCSP, existe la latencia entre la petición OCSP y la respuesta (generalmente más importante que para una petición de CRL ya que el servidor debe firmar su respuesta) y el tiempo de verificación de la firma de la respuesta OCSP.

En el caso de algunos entornos de baja potencia de cálculo (terminal móvil, PDA, tarjeta magnética potente, micro terminal inalámbrica como reloj, cámara de fotos digital, ...), una verificación de firma y/o de certificado, y/o de CRL y/o de respuesta OCSP puede ser demasiado larga de efectuar para tener una utilidad práctica.

(4)

5 10 15 20 25 30 35 40 45 50 55 60 65

La abreviatura aparecida en Patent Abstracts de Japón y correspondiente a la solicitud de patente JP 2001 237820 A se refiere a un sistema de reescritura de certificados en un contexto de autentificación, en el cual varios certificados que tienen fechas de expiración diferentes son almacenados en un terminal que procede a una selección de un certificado válido con ayuda de un reloj.

Uno de los objetivos de la presente invención es permitir que el usuario ahorre tiempo durante el establecimiento de una sesión protegida.

La invención propone así un procedimiento tal como el enunciado en la reivindicación 1. Los modos de realización de este procedimiento son indicados en las reivindicaciones 2 a 8.

El ahorro de tiempo para el usuario es resultado de la conservación en un marcador (“bookmark”) del certificado de un sitio protegido, así como de la ejecución de la verificación de ese certificado en un instante anterior a la conexión con el sitio.

Considerando el ejemplo elemental donde un usuario quiere conectarse en línea con su banco. El certificado del banco es recuperado primeramente y verificado, por ejemplo durante una primera conexión, siendo juzgada válida la verificación entre el instante actual T y algún instante ulterior T’ (por ejemplo un mes más tarde). Cuando el usuario registra el URL (“Uniform Resource Locator”) del sitio de su banco en un marcador, el navegador registra también datos que validan el certificado del banco entre los instantes T y T’, y eventualmente el propio certificado. Si el usuario se conecta con el servidor antes de T’, el navegador se contentará con consultar los datos del marcador sin tener que verificar de nuevo sistemáticamente el certificado del banco antes de autorizar la conexión.

Otro aspecto de la invención se refiere a una unidad de comunicación apta para establecer sesiones protegidas con una unidad remota e incorporando medios adaptados para la puesta en práctica del procedimiento referido anterior-mente.

Otro aspecto de la invención se refiere a un programa de computadora ejecutable por medio de un circuito de procesamiento de una unidad de comunicación, comprendiendo instrucciones para establecer sesiones protegidas con una unidad remota conforme al procedimiento anterior durante una ejecución del programa mediante el circuito de procesamiento.

Otras particularidades y ventajas de la presente invención aparecerán en la descripción a continuación de ejemplos de realización no limitativos, con referencia al dibujo anexado, en el cual la figura única es un diagrama que muestra el desarrollo de un procedimiento de acuerdo con la invención.

El procedimiento de acuerdo con la invención es ejecutado en una unidad de comunicación que consiste típicamen-te en un típicamen-terminal clientípicamen-te. Estípicamen-te típicamen-terminal U puede tomar diversas formas: típicamen-teléfono móvil dotado de un navegador WAP soportando WTLS, computadora personal fija o portátil o asistente digital personal (PDA) dotado de un navegador web soportando SSL/TLS, etc.

El terminal U tiene un circuito de procesamiento (CPU), “central processing unit”) capaz de ejecutar un software de navegación. Está además equipado de un programa que constituye un enriquecimiento del navegador destina-do a acelerar el establecimiento de sesiones protegidas con sitios favoritos del usuario. Este programa, ejecutable por el CPU, está escrito en un lenguaje informático conocido de manera de procurar las funcionalidades descritas a continuación.

El servidor S con el cual el usuario podrá conectarse utilizando su terminal U alberga un sitio SSL protegido por un certificado C, típicamente un sitio de banco en línea, de comercio electrónico, de mensajería electrónica por el web, etc. Será frecuentemente un servidor con el cual el usuario se conecta regularmente. El protocolo protegido empleado es por ejemplo https.

Para acelerar esta conexión, el terminal opera una verificación anticipada del certificado C del servidor S, cuyo resultado es almacenado con el marcador B (o “bookmark”) de S. De acuerdo con el navegador con el que está equipado el Terminal U, un marcador puede consistir en un fichero autónomo, en un registro dentro de un fichero grande agrupando todos los marcadores, etc.

En una primera etapa, el terminal U obtiene el certificado del servidor S. El mismo registra preferentemente el certificado obtenido C en el marcador B del sitio, con los datos de localización A del sitio consistiendo típicamente en su URL (https://www.s.com en el ejemplo diseñado).

La recuperación de este certificado en el terminal cliente puede efectuarse durante una conexión efectiva con el servidor, como en la realización ilustrada en la figura. En una variante, el terminal U puede recuperar el certificado C por anticipación, independientemente de una conexión explícita con S, por ejemplo en el momento de registrar el marcador para S, o también fuera de la conexión mediante otro medio tal como la inscripción de oficio antes de la entrega del terminal, la lectura en un soporte de datos tal como un disquete, un dispositivo de seguridad, el intercambio con otro terminal (por ejemplo, infrarrojo), etc.

(5)

5 10 15 20 25 30 35 40 45 50 55 60 65

La recuperación del certificado C puede ser renovada periódicamente, en fecha fija, con expiración del certificado precedente, etc.

En una segunda etapa, el terminal U procede a la verificación del certificado C del servidor S, y si esta verificación es positiva, este registra datos de validación D en el marcador B, con el URL y el certificado del sitio.

La verificación efectuada incluye el control de revocación. La misma es efectiva en un instante T, y válida en un periodo llegando hasta un instante T’. Esto significa que con las informaciones que posee, el terminal cliente U estima que la verificación que éste efectúa en el instante T será también válida en todos los instantes al menos hasta T’. Típicamente, el control de revocación garantiza la no revocación del certificado hasta un cierto instante, que puede ser considerado como el instante T’ por el cliente. Este puede ser operado con ayuda de un servidor de verificación de certificados V, por ejemplo un servidor teniendo al día los CRL, o como es ilustrado por la figura, un servidor OCSP.

Los instantes T y T’ forman parte de los datos de validación D registrados en el marcador B. En una realización típica, el instante T es el de la recuperación del certificado.

En numerosos casos de aplicación práctica, U recupera C en la primera conexión del usuario con el sitio S, y verifica con ello inmediatamente la validez de T (=instante de recuperación) a T’. Si el usuario decide poner un marcador sobre S, el navegador almacena con este marcador B las informaciones C, T y T’.

Posteriormente, cuando el marcador B es utilizado para un nuevo acceso al sitio S, el programa examina los datos de validación D de este marcador y las fechas y horas comunes para determinar si la conexión es solicitada en un instante comprendido entre T y T’. En caso afirmativo, la conexión es establecida sin que se proceda a una nueva verificación del certificado durante el “handshake” SSL, lo que permite ahorrar tiempo al usuario.

Si la conexión es solicitada en un instante T” posterior a T’, el terminal procede a una verificación del certificado, con control de revocación por CRL u OCSP. Una nueva verificación es así efectuada en la primera conexión con el sitio posterior al instante T’. Si esta verificación confirma la validez del certificado hasta T”’, el marcador B puede ser actualizado remplazando los datos de validación T, T’ mediante T”, T”’,

En una variante de realización, una nueva verificación del certificado C es efectuada automáticamente por el pro-grama en el instante T’. La verificación también puede ser efectuada cíclicamente, por ejemplo una vez por día en periodo de poca actividad de la red. La primera verificación puede ser efectuada también en el instante de recupera-ción del certificado C, o en el instante previsto por adelantado.

Puede resultar interesante prever que la nueva verificación del certificado C tenga lugar automáticamente en un instante anterior a T’ pero relativamente próximo a T’, con una anticipación programable por el usuario. Ello permite parametrizar una nueva verificación de C antes de finalizar la validación de la verificación precedente, y seleccionar un instante apropiado para efectuar conexiones en red, por ejemplo a una hora de poco tráfico.

(6)

5 10 15 20 25 30 35 40 45 50 55 60 65 REIVINDICACIONES

1. Procedimiento para establecer sesiones protegidas con una unidad de comunicación remota (S),caracterizado

porque se obtiene un certificado (C) de la unidad remota, se verifica el certificado, y después de una verificación positiva para un próximo periodo, se registra un marcador (B) incluyendo datos (A) de localización de la unidad remota y datos (D) de validación del certificado para dicho periodo, y porque el establecimiento, en un instante de conexión ulterior, de una sesión protegida con la unidad remota mediante el dicho marcador comprende una consulta de los datos de validación para verificar si el instante de conexión se encuentra en el interior de dicho periodo.

2. Procedimiento de acuerdo con la reivindicación 1, en el cual el marcador registrado (B) incluye además el certificado (C) de la unidad remota (S).

3. Procedimiento de acuerdo con la reivindicación 1 o 2, en el cual el certificado (C) es cargado a distancia durante una conexión precedente con la unidad remota (S).

4. Procedimiento de acuerdo con la reivindicación 1 o 2, en el cual el certificado (C) es obtenido por anticipación independientemente de una conexión con la unida remota (S).

5. Procedimiento de acuerdo con cualquiera de las reivindicaciones precedentes, en el cual la verificación del certificado (C) es efectuada de forma cíclica.

6. Procedimiento de acuerdo con cualquiera de las reivindicaciones precedentes, en el cual una nueva verificación del certificado (C) es efectuada al final de dicho periodo.

7. Procedimiento de acuerdo con cualquiera de las reivindicaciones 1 a 5, en el cual una nueva verificación del certificado (C) es efectuada durante la primera conexión con la unidad remota (S) posterior al final de dicho periodo.

8. Procedimiento de acuerdo con cualquiera de las reivindicaciones 1 a 5, en el cual una nueva verificación del certificado (C) es efectuada en un instante programable antes del final de dicho periodo.

9. Unidad de comunicación (U) apta para establecer sesiones protegidas con una unidad de comunicación remota (S) e incorporando medios adaptados a la puesta en práctica de un procedimiento de acuerdo con cualquiera de las reivindicaciones precedentes.

10. Programa de computadora ejecutable por medio de un circuito de procesamiento de una unidad de comunica-ción (U), comprendiendo instrucciones para establecer sesiones protegidas con una unidad de comunicacomunica-ción remota (S) conforme a un procedimiento de acuerdo con cualquiera de las reivindicaciones 1 a la 8 durante una ejecución del programa por medio del circuito de procesamiento.

(7)

Figure

Actualización...

Referencias

Actualización...

Related subjects :