Acceso a recursos mediante un módulo de seguridad.

Procedimiento para acceder a un recurso (18), realizándose dicho procedimiento mediante un módulo deseguridad portátil (14) configurado como una tarjeta chip o un módulo chip o un soporte de datos USB e incluyendoel procedimiento:

- recepción de una primera petición (42) procedente de un equipo terminal (10) que se halla situado en una redprivada con el módulo de seguridad (14), primera petición (42) que aborda el módulo de seguridad (14) como unservidor de origen y contiene un identificador (ID1) asignado al recurso (18),

- determinación de, al menos, una indicación de anfitrión (URL1,HOST) y una indicación de ruta (URL1,PATH, ID1,PATH)del recurso (18) en función del identificador (ID1) contenido en la primera petición (42),

- envío, mediante una red de ordenadores externa (20), de una segunda petición (44) que contiene, al menos, laindicación de ruta determinada (URL1,PATH, ID1,PATH) a un servidor (12) designado por la indicación de anfitrión(URL1,HOST) determinada,

- recepción de una primera respuesta (46) procedente del servidor (12) en respuesta a la segunda petición (44),primera respuesta (46) que contiene al menos una remisión con un URL (URL1, URL2),

- modificación del URL (URL1, URL2) de la primera respuesta (46) para obtener una segunda respuesta (48),presentando el URL modificado una dirección (HOSTSM) del módulo de seguridad (14) como indicación de anfitrión,y

- envío de la segunda respuesta (48) al equipo terminal (10).

Acceso a recursos mediante un módulo de seguridad

La invención se refiere en general al campo técnico de los módulos de seguridad y más en particular al campo de la conmutación de un acceso a un recurso mediante un módulo de seguridad. En la selección de palabras utilizada para el presente documento, un módulo de seguridad puede presentar por ejemplo la forma constructiva de una tarjeta chip o de un módulo chip compacto o de un soporte de datos USB.

Ya se conoce el método de utilizar un módulo de seguridad como proxy (estación intermedia) en la comunicación entre un equipo terminal y un servidor. El documento WO 2006/029758 A1, por ejemplo, muestra una tarjeta chip que se comunica por una parte con un equipo terminal y por otra parte – mediante el equipo terminal intercalado y una red de ordenadores – con un servidor. Un navegador ejecutado en el equipo terminal aborda la tarjeta chip como proxy para la comunicación con el servidor. La tarjeta chip hace aquí las veces de medio auxiliar del navegador. En concreto ejecuta de forma independiente un procedimiento de autentificación si éste resulta necesario.

Sin embargo, en el sistema conocido por el documento WO 2006/029758 A1 existe el problema de que el navegador debe configurarse adecuadamente para hacer posible un funcionamiento de la tarjeta chip como proxy. Con este fin puede ser necesario, por ejemplo, introducir una dirección IP de la tarjeta chip en un menú de configuración del navegador. En particular hay que cambiar una y otra vez la configuración del navegador si el equipo terminal se hace funcionar a veces con la tarjeta chip conectada y a veces sin conectar. Esto resulta engorroso y puede menoscabar la aceptación del sistema por parte de los usuarios técnicamente menos versados.

El aporte a conferencia "Internet-Sicherheit mit Security-Token" (seguridad en Internet con testigo de seguridad) de Stephan Spitz y Walter Hinz, D·A·CH Mobility, octubre de 2006, describe la utilización de una tarjeta chip de Internet como proxy de autentificación. Por ejemplo, un usuario puede establecer un enlace con un servidor de banca de manera indirecta a través de la tarjeta chip de Internet llamando en primer lugar una página web local en la tarjeta y activando a continuación en esta página web un hipervínculo al servidor de banca. Sin embargo, no se dan a conocer detalles con respecto al funcionamiento de esta solución.

El documento EP 1021020 B1 da a conocer un ordenador personal que ejecuta un navegador y un proxy y está conectado a una tarjeta chip. El proxy analiza las peticiones HTTP entrantes. Si una de tales peticiones HTTP define un acceso a la tarjeta chip, el proxy ejecuta el acceso a la tarjeta chip y dispone al mismo tiempo todas las conversiones de formato necesarias. El proxy permite así un acceso remoto a una tarjeta chip 'normal'.

El documento WO 99/56210 A1 muestra un sistema en el que, en una red de comunicación móvil, la funcionalidad de un navegador está repartida entre un cliente y un componente estacionario. El componente estacionario analiza los documentos pedidos por el cliente y sustituye los elementos de datos a recargar por caracteres de sustitución. A continuación, el componente estacionario recarga automáticamente dichos elementos de datos y los transmite al cliente.

El documento JP 2002-312325 A da a conocer una tarjeta chip capaz de autentificarse en varios servicios distintos.

El documento normativo "Hypertext Transfer Protocol - HTTP/1.1" de R. Fielding et al., publicado por World Wide Web Consortium, RFC 2616, define peticiones y respuestas según el protocolo HTTP y explica, entre otras cosas, los términos URL, servidor de origen, pasarela, túnel y proxy, que en parte se utilizan también en el presente documento.

Por el documento "Traditional IP Network Adress Translator (Traditional NAP) " de P. Srisuresh et al., enero de 2001, disponible el 15.1.2008 en http://tools.ietf.org/html/rfc3022, se conoce el concepto NAT, utilizado también en el presente documento, para la conmutación entre direcciones IP externas e internas.

La invención tiene el objetivo de poner a disposición una técnica segura y/o de fácil utilización para el acceso a un recurso mediante un módulo de seguridad.

Según la invención, este objetivo se logra mediante un procedimiento con las características de la reivindicación 1, un módulo de seguridad según la reivindicación 16 y un producto de programa informático según la reivindicación 17. Las reivindicaciones dependientes se refieren a características opcionales de algunas configuraciones de la invención.

La invención parte de la idea fundamental de abordar el módulo de seguridad no como un proxy, sino como un servidor de origen. Esto puede lograrse, por ejemplo, introduciendo en un navegador de un equipo terminal externo un URL que contenga como indicación de anfitrión una dirección del módulo de seguridad. El URL contiene además un identificador. El módulo de seguridad analiza el URL y determina de este modo tanto una indicación de anfitrión como una indicación de ruta del recurso. A continuación, el módulo de seguridad accede al recurso mediante estas indicaciones de anfitrión y de ruta.

La invención ofrece la considerable ventaja de no resultar necesario configurar el navegador para la utilización de un módulo de seguridad configurado como proxy. Esto es importante especialmente si el módulo de seguridad ha de ser utilizado por un usuario inexperto o si el navegador se hace funcionar a veces con y a veces sin módulo de seguridad conectado. Además, el módulo de seguridad puede determinar todos los ajustes de seguridad al acceder al recurso y evitar así posibles problemas en caso de una configuración no óptima del navegador.

En algunas formas de realización, el módulo de seguridad presenta una tabla de conversión, a la que se recurre, al menos, para determinar la indicación de anfitrión del recurso. El usuario puede entonces acceder cómodamente al servidor y/o los recursos admisibles según la tabla de conversión. Con esta medida se evitan además ataques basados en indicaciones de anfitrión escritas incorrectamente. En algunas configuraciones, la indicación de ruta del recurso se determina también mediante un acceso a la tabla de conversión, mientras que en otras formas de realización la indicación de ruta forma parte del identificador o puede deducirse esquemáticamente a partir del mismo.

En una configuración preferida está previsto que el módulo de seguridad analice también respuestas entrantes procedentes de un recurso y sustituya, al menos, algunos de los URL contenidos en las mismas por URL modificados. Los URL modificados presentan como indicación de anfitrión una dirección del módulo de seguridad. Esta medida hace que un siguiente acceso al recurso, en el que el usuario siga una remisión contenida en la respuesta, se conduzca también a través del módulo de seguridad.

Además, en muchas configuraciones se sustituyen, al menos, algunas indicaciones de anfitrión y/o de ruta, contenidas en remisiones de una respuesta entrante en el módulo de seguridad, por identificadores según la tabla de conversión. Esta sustitución constituye en muchas formas de realización la pareja de las modificaciones efectuadas durante el procesamiento de peticiones, de modo que al usuario se le presentan identificadores de manera consistente y al servidor se le presentan las correspondientes indicaciones de anfitrión y/o de ruta de manera consistente.

Si una respuesta contiene remisiones con indicaciones de anfitrión y/o de ruta aún desconocidas para el módulo de seguridad, en algunas configuraciones la tabla de conversión se completa de forma dinámica, mientras que en otras configuraciones se sustituyen remisiones con indicaciones de anfitrión y/o de ruta desconocidas por remisiones o instrucciones de seguridad predefinidas.

En algunas formas de realización, el módulo de seguridad presenta una función para la introducción automática de datos de formulario y/o una función de registro.

En algunas configuraciones, el módulo de seguridad es un aparato compacto y protegido contra manipulaciones (tamperproof device) .

El producto de programa informático puede presentar instrucciones de programa en un soporte de datos físico o no físico, que puede utilizarse por ejemplo en la fabricación o inicialización de un módulo de seguridad según la invención. Un soporte de datos de este tipo puede ser, por ejemplo, un CD-ROM o una memoria de semiconductores o una señal transmitida a través de una red de ordenadores.

De la descripción detallada siguiente de varios ejemplos de realización se desprenden otras características,... [Seguir leyendo]

1. Procedimiento para acceder a un recurso (18) , realizándose dicho procedimiento mediante un módulo de seguridad portátil (14) configurado como una tarjeta chip o un módulo chip o un soporte de datos USB e incluyendo el procedimiento:

- recepción de una primera petición (42) procedente de un equipo terminal (10) que se halla situado en una red privada con el módulo de seguridad (14) , primera petición (42) que aborda el módulo de seguridad (14) como un servidor de origen y contiene un identificador (ID1) asignado al recurso (18) ,

- determinación de, al menos, una indicación de anfitrión (URL1, HOST) y una indicación de ruta (URL1, PATH, ID1, PATH) del recurso (18) en función del identificador (ID1) contenido en la primera petición (42) ,

- envío, mediante una red de ordenadores externa (20) , de una segunda petición (44) que contiene, al menos, la indicación de ruta determinada (URL1, PATH, ID1, PATH) a un servidor (12) designado por la indicación de anfitrión (URL1, HOST) determinada,

- recepción de una primera respuesta (46) procedente del servidor (12) en respuesta a la segunda petición (44) , primera respuesta (46) que contiene al menos una remisión con un URL (URL1, URL2) ,

- modificación del URL (URL1, URL2) de la primera respuesta (46) para obtener una segunda respuesta (48) , presentando el URL modificado una dirección (HOSTSM) del módulo de seguridad (14) como indicación de anfitrión, y

- envío de la segunda respuesta (48) al equipo terminal (10) .

2. Procedimiento según la reivindicación 1, caracterizado porque el módulo de seguridad (14) determina, al menos, la indicación de anfitrión (URL1, HOST) a partir de una tabla de conversión (36) almacenada en el módulo de seguridad (14) .

3. Procedimiento según la reivindicación 2, caracterizado porque el módulo de seguridad (14) también determina la indicación de ruta (URL1, PATH) a partir de la tabla de conversión (36) .

4. Procedimiento según la reivindicación 2, caracterizado porque el módulo de seguridad (14) determina la indicación de ruta (ID1, PATH) a partir del identificador (ID1) independientemente de la tabla de conversión (36) .

5. Procedimiento según la reivindicación 4, caracterizado porque el módulo de seguridad (14) determina la indicación de ruta (ID1, PATH) como parte del identificador (ID1) .

6. Procedimiento según la reivindicación 5, caracterizado porque, en función de, al menos, una parte (URL1, URL2, URL1, HOST) del URL (URL1, URL2) contenido en la primera respuesta (46) , se determina un identificador (ID1, ID2, ID1, HOST) que constituye, al menos, una parte de una indicación de ruta del URL modificado.

7. Procedimiento según la reivindicación 6 en combinación con una de las reivindicaciones 2 a 5, caracterizado porque el identificador (ID1, ID2, ID1, HOST) se determina a partir de la tabla de conversión (36) .

8. Procedimiento según la reivindicación 7, caracterizado porque se determina una entrada de la tabla de conversión

(36) que presenta el URL (URL1, URL2) contenido en la primera respuesta (46) y presenta también el identificador (ID1, ID2) y porque la indicación de ruta del URL modificado está formada por el identificador (ID1, ID2) .

9. Procedimiento según la reivindicación 7, caracterizado porque se determina una entrada de la tabla de conversión (36) que presenta una indicación de anfitrión (URL1, HOST) del URL (URL1) contenido en la primera respuesta (46) y presenta también el identificador en forma de un identificador de anfitrión (ID1, HOST) y porque la indicación de ruta del URL modificado está formada por el identificador de anfitrión (ID1, HOST) y una indicación de ruta (URL1, PATH) del URL (URL1) contenido en la primera respuesta (46) .

10. Procedimiento según una de las reivindicaciones 7 a 9, caracterizado porque la tabla de conversión (36) se amplía dinámicamente con identificadores recién determinados (ID2, ID2, HOST) .

11. Procedimiento según una de las reivindicaciones 1 y 6 a 10, caracterizado porque la primera respuesta (46) contiene al menos una remisión con un URL (URL2) que, al crearse la segunda respuesta (48) , se incluye sin cambios en la segunda respuesta (48) o se sustituye por una remisión con un URL predeterminado o se borra o se sustituye por una instrucción de seguridad.

12. Procedimiento según una de las reivindicaciones 1 a 11, caracterizado porque el módulo de seguridad (14) presenta además una función para la introducción automática de datos de formulario y/o una función de registro.

13. Módulo de seguridad portátil (14) con un procesador (22) y al menos una memoria (24) , caracterizado porque el módulo de seguridad (14) está preparado para ejecutar un procedimiento según una de las reivindicaciones 1 a 12.

14. Producto de programa informático que presenta instrucciones de programa para un procesador (22) de un módulo de seguridad (14) , produciendo las instrucciones de programa al procesador (22) del módulo de seguridad

(14) la ejecución de un procedimiento según una de las reivindicaciones 1 a 12.

Fig. 1

Fig. 2 Fig. 3

Fig. 4 Fig. 5

Fig. 6 Fig. 7

REFERENCIAS CITADAS EN LA DESCRIPCIÓN

La lista de referencias citada por el solicitante lo es solamente para utilidad del lector, no formando parte de los documentos de patente europeos. Aún cuando las referencias han sido cuidadosamente recopiladas, no pueden excluirse errores u omisiones y la OEP rechaza toda responsabilidad a este respecto.

Documentos de patente citado en la descripción

•WO 2006029758 A1 [0002] [0003] • WO 9956210 A1 [0006]

•EP 1021020 B1 [0005] • JP 2002312325 A [0007]

Bibliografía de patentes citada en la descripción

• STEPHAN SPITZ ; WALTER HINZ. Internet-• P. SRISURESH et al. Traditional IP Network Sicherheit mit Security-Token. D·A·CH Mobility, Adress Translator (Traditional NAP, Januar Oktober 2006 [0004] 2001, http:// tools.ietf.org/html/rfc3022 [0009]

• R. FIELDING et al. Hypertext Transfer Protocol

-HTTP/1.1 [0008]