ES2603585T3 - Sistema y procedimiento de transacción segura en línea - Google Patents

Abstract

Lector (1) de tarjeta chip para transacciones seguras en línea, a través de al menos una red (RC) de comunicación, por el intercambio de datos representativos de transacciones con al menos un equipo (4) de un proveedor de servicios que comprende al menos un servidor (40) dispuesto para gestionar las transacciones en línea y al menos un módulo de seguridad (41) que asegura estas transacciones en cooperación con el lector (1), caracterizado por que comprende medios (12) de procesamiento que están adaptados para: - intercambiar, antes de cualquier transacción, los datos con al menos un chip (20) de al menos una tarjeta (2) segura, con el fin de obtener, del chip (20), y transmitir, al módulo de seguridad (41), los datos (D_chip), denominados públicos, representativos de al menos una información vinculada a la tarjeta (2), - gestionar, antes de cualquier transacción, en cooperación con dicho chip (20), al menos una clave de sesión (Kses), y transmitir al módulo de seguridad (41) los datos encriptadas utilizando esta clave de sesión (Kses), con el fin de que el módulo de seguridad (41) puede calcular dicha clave de sesión (Kses), a partir de dichos datos públicos (D_chip) recibidos y de al menos una clave de encriptado (CF), - intercambiar los datos representativos de la transacción con el módulo de seguridad (41), en forma encriptada por dicha clave de sesión (Kses), formando de este modo un canal (CS) de comunicación seguro para la transacción.

Description

5

10

15

20

25

30

35

40

45

50

55

60

DESCRIPCION

Sistema y procedimiento de transaccion segura en lmea

La presente invencion se refiere al campo de las transmisiones seguras de datos a traves de al menos una red de comunicacion como, por ejemplo, la red Internet. Las transmisiones permiten, por ejemplo, llevar a cabo operaciones "en lmea" (u "on line", segun la terminologfa en ingles), conectandose al menos a un servidor por medio de al menos un terminal adecuado, a traves de al menos una red de comunicacion.

La presente invencion se aprovecha de las tarjetas chip seguras como, por ejemplo, las "tarjetas bancarias" o las "tarjetas de pago con chip", especialmente las conocidas con el nombre de EMV (para “Europay MasterCard Visa"), que permiten proteger los pagos realizados por medio del chip (por ejemplo, del tipo ISO 7816) de la tarjeta que comprende al menos una clave de encriptacion y, en su caso, por medio del codigo de identificacion asociado (numero de identificacion personal, PIN para "Personal Identification Number" segun la terminologfa en ingles). Cabe senalar que la presente invencion se adapta particularmente para llevar a cabo transacciones en lmea, pero tambien puede ser utilizada para diversos tipos de intercambio seguro de informacion. De este modo, por ejemplo, la presente invencion esta adaptada para el uso de otras tarjetas como, por ejemplo, las tarjetas sanitarias, las tarjetas de los profesionales de la salud (CPS) o cualquier otro tipo de tarjeta cuyo chip almacene al menos una clave encriptada, con el fin de proteger los intercambios de datos de cualquier tipo (estando estos intercambios reagrupados aqu bajo el termino "transaccion"). De hecho, la invencion puede, en su caso, evolucionar segun el cambio de las normas de las tarjetas, especialmente las tarjetas EMV, y se hablara en la presente solicitud en general de "tarjeta segura" para referirse a este tipo de tarjetas chip que contienen al menos una clave simetrica de encriptacion almacenada en el chip y provistas con capacidades criptograficas por clave simetrica, En cambio con las tarjetas de tipo PKI (“Public Key Infrastructure", segun la terminologfa en ingles, que se refiere a una infraestructura que permite la gestion y uso de certificados digitales que vinculan las claves publicas con la identidad de un usuario) conocidas de la tecnica anterior que utilizan claves asimetricas y tienen los inconvenientes mencionados mas adelante.

Un problema en el ambito de las transacciones seguras se refiere a los ataques posibles, por ejemplo, por piratas informaticos, para obtener los datos sensibles de las transacciones, como las informaciones bancarias, etc. Muchos de los ataques informaticos se basan en la ingeniena social (es decir, la falta de conocimientos tecnicos por parte del publico, que no conoce los mecanismos de seguridad y puede, por consiguiente, utilizar los mecanismos de forma que corran el riesgo de dejarlos vulnerables). En particular, se conocen los virus informaticos, que son programas informaticos escritos con el fin de propagarse a otros ordenadores insertandose en programas legttimos llamados "anfitriones". Tambien pueden tener el efecto, buscado o no, de danar perturbando mas o menos seriamente el funcionamiento del ordenador infectado. Se pueden propagar a traves de cualquier medio de intercambio de datos digitales como Internet, pero tambien disquetes, CD-ROM, dispositivos USB, etc. Existen, tambien, los ataques conocidos con el nombre de "suplantacion de la identidad" o "cebo" ("phishing”, segun la terminologfa en ingles) utilizados por los estafadores para obtener informaciones personales con el fin de cometer una usurpacion de la identidad. La tecnica consiste en hacer creer a la vmtima que se esta dirigiendo a un tercero de confianza (banco, administracion, etc.) con el fin de sonsacarle informaciones personales (contrasena, numero de tarjeta de credito, fecha de nacimiento, etc.). La suplantacion de la identidad puede hacerse por correo electronico, por sitios webs falsificados o por otros medios electronicos. Se conocen tambien los ataques llamados de “redireccionamiento malicioso” ("pharming" en ingles), que explotan las vulnerabilidades del DNS ("Domain Name System", segun la terminologfa en ingles) para recuperar los datos de una vmtima. Se trata de un tipo de suplantacion de la personalidad que permite robar informaciones despues de haber atrafdo a la vmtima a un sitio web camuflado, incluso aunque el nombre del dominio este escrito correctamente. Los piratas informaticos habran cambiado previamente la correspondencia entre el nombre del dominio y la direccion IP. De ese modo, por ejemplo,
www.mabanque.fr no apuntara ya hacia la direccion IP del servidor de "Mi Banco", sino a otro servidor fraudulento. Otros tipos de ataques son conocidos con el nombre de “registrador de pulsaciones en el teclado” ("keylogger", segun la terminologfa en ingles) por los cuales el equipo o software espfa registra las pulsaciones en el teclado de un ordenador en ciertas condiciones y las transmite, en especial para permitir un uso fraudulento. Tambien, se sabe de los ataques conocidos como el "intermediario" (“hombre en el medio”, HDM, en frances) (o "man in the middle attack", MITM, segun la terminologfa en ingles) que tiene como fin interceptar las comunicaciones entre dos partes sin que ni una ni otra puedan dudar de que el canal de comunicacion (CS) entre ellas se ha visto comprometido. El atacante debe, en primer lugar, ser capaz de observar e interceptar los mensajes de una vmtima con la otra. El ataque "intermediario" es particularmente aplicable en el protocolo original de intercambio de las claves Diffie- Hellman, cuando se utiliza sin autenticacion. Tambien se sabe de los ataques conocidos con el nombre de "el hombre del navegador" (o "man in the browser", segun la terminologfa en ingles), que es una forma reciente de amenazas vinculadas a los ataques de intermediario (hombre del medio), y se basan en un troyano (software malicioso aparentemente legttimo disenado para ejecutar acciones sin el conocimiento del usuario, utilizando por lo general derechos que pertenecen a su entorno para desviar, difundir o destruir las informaciones, o incluso para abrir una puerta trasera que permita a un atacante tomar el control remoto de un ordenador). Estos ataques infectan, por ejemplo, un navegador de internet y permiten modificar paginas, modificando el contenido o las transacciones o insertar otras transacciones, todo ello de un modo totalmente invisible para el usuario y la aplicacion anfitriona. Estos ataques son particularmente peligrosos porque generalmente tienen exito, incluso cuando se utilizan mecanismos de seguridad como SSL, PKI ("Public Key Infrastructure", segun la terminologfa en ingles que se refiere a una

5

10

15

20

25

30

35

40

45

50

55

infraestructura que permite la gestion y utilizacion de certificados digitales que vinculan las claves publicas con la identidad de un usuario) y/o el uso de autenticacion de dos o tres factores.

Se conocen en la tecnica anterior diversas soluciones para realizar transacciones seguras por internet. Sin embargo, la mayor parte de las soluciones conocidas son vulnerables a al menos uno de los ataques conocidos. Se conocen, por ejemplo, las soluciones que utilizan "clave de proteccion" (material informatico, como una clave para conectarse a un ordenador, por ejemplo de USB, "Universal Serial Bus") u objetos portatiles o tarjetas chip y/o lectores de tarjetas chip dispuestos para proteger las operaciones. Sin embargo, este tipo de solucion tiene el inconveniente de utilizar certificados, tales como protocolos SSL/TLS, por ejemplo, cuyo usuario no puede generalmente verificar la autenticidad y que son, por consiguiente, vulnerables a algunos de los ataques descritos. Ademas, estas soluciones tienen el inconveniente de requerir el despliegue de una infraestructura de red que soporte el uso de estos dispositivos para la autenticacion (gestion de los certificados distribuidos, etc.). En efecto, diversos protocolos relativamente seguros, como SSL/TLS, se abandonan debido a los problemas de ingeniena social antes mencionados, porque los usuarios aceptan cualquier certificado que se les presente.

Tambien se conocen soluciones que consisten en la creacion de un canal seguro (o "tunel" seguro), es decir, un canal (CS) de comunicacion encriptada, entre las 2 entidades relacionadas en el momento de la transaccion (por ejemplo, banco-usuario). Sin embargo, este tipo de solucion tiene tambien el inconveniente de quedar vulnerable a ciertos ataques porque el canal seguro se basa en el uso de certificados tales como los protocolos SSL/TLS.

Por ultimo, se conocen, en especial de los documentos WO 2005/001618, EP 1850297 y WO 01/82246, soluciones conocidas que son compatibles con el Programa de Autenticacion por Tarjeta (PAC, o CAP para "Chip Authentication Program" segun la terminologfa en ingles) y que usan un lector de tarjeta bancaria conectado al terminal (ordenador, por ejemplo) del usuario y en el que este ultimo inserta una tarjeta bancaria para permitir la firma de las transacciones por el chip de esta tarjeta. Sin embargo, este tipo de solucion tiene el inconveniente de ser vulnerable a ciertos ataques ya que las informaciones sensibles circulan por el terminal que pide al lector la firma de la transaccion por la tarjeta. Por ejemplo, un problema con esta solucion esta vinculado a la ingeniena social, ya que es debido al hecho de que el usuario no verifica generalmente las informaciones en el lector y se conforma con validar la transaccion fiandose de lo que se visualiza en su terminal, cuando un ataque, por ejemplo, del tipo hombre del navegador, haya podido desviar las informaciones a validar en el lector a la vez que se visualizan informaciones normales en el terminal.

En este contexto, existe la necesidad de soluciones sencillas, economicas y faciles de utilizar, especialmente por el publico en general, lo que permite proteger las transacciones en lmea, a diferencia de las soluciones conocidas a menudo demasiado caras, demasiado complejas de utilizar y de ejecutar por el publico en general, sobre todo a causa de los problemas vinculados a la ingeniena social.

Un objetivo de la presente invencion es, por consiguiente, superar al menos algunos inconvenientes de la tecnica anterior proporcionando un sistema que permita inicializar transacciones seguras en lmea.

Este objetivo se logra mediante un sistema de inicializacion de transaccion segura en lmea, a traves de al menos una red de comunicacion, conteniendo el sistema al menos un equipo de un proveedor de servicios que comprende al menos un servidor dispuesto para gestionar transacciones en lmea, por el intercambio de datos representativos de las transacciones, comprendiendo dicho equipo tambien al menos un modulo de seguridad dispuesto para proteger esas transacciones, caracterizado porque:

- dicho sistema contiene al menos un lector de tarjeta chip que accede al equipo proveedor a traves de dicha red de comunicacion y que comprende medios de procesamiento dispuestos para, por una parte, intercambiar datos con al menos un chip de al menos una tarjeta segura, con el fin de obtener del chip, y transmitir al modulo de seguridad los datos, denominados publicos, representativos de al menos una informacion vinculada a la tarjeta y, por otra parte, para generar, en cooperacion con dicho chip, al menos una clave de sesion, y transmitir al modulo de seguridad los datos encriptados utilizando esta clave de sesion,

- el modulo de seguridad esta dispuesto para calcular dicha clave de sesion a partir de dichos datos publicos recibidos y al menos una clave de encriptado,

- el calculo de la clave de sesion por el lector y el modulo de seguridad que permite la inicializacion de la transaccion mediante el establecimiento de un canal de comunicacion seguro en el que los datos representativos de la transaccion podran circular en forma encriptada por dicha clave de sesion.

Segun otra caractenstica, el chip de la tarjeta esta dispuesto para generar, a partir de al menos una clave de encriptado almacenada en el chip, al menos un criptograma utilizado por los medios de procesamiento del lector dispuestos para generar la clave de sesion utilizada en el establecimiento del canal seguro.

Segun otra caractenstica:

- el modulo de seguridad utiliza al menos una clave, denominada clave madre utilizada para la generacion de las claves de las tarjetas seguras suministradas por el proveedor de servicios, denominadas claves hijas, siendo cada una de las tarjetas suministradas identificable a partir de al menos una informacion contenida en los datos publicos,

- los medios de procesamiento del lector transmiten al modulo de seguridad los datos publicos que le permiten hallar la clave de encriptado a utilizar para el calculo de la clave de sesion.

5

10

15

20

25

30

35

40

45

50

55

Segun otra caractenstica, el equipo del proveedor de servicio contiene al menos una base de datos que almacenan las claves de encriptado de las tarjetas seguras suministradas por el proveedor de servicio, el modulo de seguridad que accede a esta base de datos para encontrar, en funcion de los datos publicos recibidos del lector de la tarjeta chip, la clave de encriptado a utilizar para el calculo de la clave de sesion.

Segun otra caractenstica, el lector y el equipo proveedor estan conectados a traves de una comunicacion segura segun un protocolo de tipo SSL/TLS dentro de la cual quedara establecido el canal seguro.

Segun otra caractenstica, los medios de procesamiento del lector estan dispuestos para recibir del modulo de seguridad y tratar al menos una peticion de inicializacion del canal seguro que comprende un numero impredecible y que provoca la consulta del chip por el lector, para obtener al menos un criptograma y los datos representativos de las informaciones vinculadas a la tarjeta, lo que permite a los medios de procesamiento del lector generar la clave de sesion que sirve para establecer el canal de comunicacion seguro y transmitir al modulo de seguridad, por una parte, los datos representativos de informaciones vinculadas a la tarjeta y, por otra parte, dichos datos encriptadas con esta clave de sesion, que contienen los datos relativos al numero impredecible.

Segun otra caractenstica, la inicializacion de la transaccion responde a una transmision al servidor del equipo proveedor de al menos una parte de los datos representativos de la transaccion, por un servidor de terceros que gestiona un sitio internet al que el usuario se ha conectado.

Segun otra caractenstica, el servidor del equipo proveedor esta dispuesto para gestionar el establecimiento y la utilizacion del canal seguro tratando y conservando un numero impredecible, la clave de sesion, un numero de sesion generado en el establecimiento del canal seguro y que esta vinculado al numero impredecible y a un contador de transaccion de la tarjeta, asf como un numero de secuencia incrementado en cada peticion enviada al lector durante cada sesion.

Segun otra caractenstica, el modulo de seguridad del equipo proveedor esta dispuesto para almacenar la clave de sesion en los medios de memorizacion y/o para encriptar la clave de sesion utilizando una clave, denominada clave maestra, y transmitirla al servidor para el almacenamiento en forma encriptada en los medios de memorizacion.

Otro objetivo de la presente invencion es superar al menos algunos inconvenientes de la tecnica anterior proponiendo un sistema que permita proteger las transacciones en lmea.

Este objetivo se consigue mediante un sistema de transaccion segura, que contiene un sistema de inicializacion segun la invencion, en el que el lector y el modulo de seguridad estan dispuestos para encriptar y desencriptar, mediante dicha clave de sesion, los datos representativos de la transaccion que se intercambian durante la transaccion, circulando entonces estos datos por el canal de comunicacion seguro con estos encriptados/desencriptados.

Segun otra caractenstica, el servidor esta dispuesto para requerir del modulo de seguridad, en cada transmision de datos con el lector, un encriptado/desencriptado por dicha clave de sesion de los datos transmitidos, estando el lector dispuesto para encriptar/desencriptar tambien los datos intercambiados durante la transaccion.

Otro objetivo de la presente invencion es superar al menos algunos inconvenientes de la tecnica anterior proponiendo un procedimiento que permita la inicializacion de transacciones seguras en lmea.

Este objetivo se consigue mediante un procedimiento de inicializacion de transaccion segura en lmea, a traves de al menos una red de comunicacion, ejecutada por un sistema de inicializacion de transaccion segura segun la invencion, caracterizado porque contiene al menos una etapa de establecimiento de al menos un canal de comunicacion segura entre el modulo de seguridad y el lector que se ejecuta por medio de las siguientes etapas:

- generacion de al menos una clave de sesion, mediante los medios de procesamiento del lector, en cooperacion con la tarjeta, despues del encriptado de los datos utilizando esta clave de sesion,

- obtencion, por el lector, a partir del chip de la tarjeta, de los datos representativos de las informaciones vinculadas a la tarjeta,

- transmision, del lector al modulo de seguridad, de los datos representativos de las informaciones vinculadas a la tarjeta y de los datos encriptados utilizando la clave de sesion,

- generacion, mediante el modulo de seguridad, de la clave de sesion a partir de al menos una clave de encriptado del modulo de seguridad y de los datos recibidos.

Segun otra caractenstica, la etapa de generacion de al menos una clave de sesion, mediante los medios de procesamiento del lector esta precedida por una etapa de generacion (51), por el chip de la tarjeta, de al menos un criptograma a partir de la clave de encriptado almacenada en el chip y de la transmision de este (estos) criptograma (criptogramas) al lector generando la clave de sesion a partir de este (estos) criptograma (criptogramas).

Segun otra caractenstica, el procedimiento contiene al menos una etapa de entrada, por el usuario de la tarjeta, de al menos un codigo de identificacion personal de usuario, y de autenticacion de ese codigo por el chip de la tarjeta, permitiendo esta etapa de entrada/autenticacion al menos una etapa de firma de datos por el chip.

5

10

15

20

25

30

35

40

45

50

55

60

Segun otra caractenstica, el procedimiento contiene al menos una etapa de recepcion y procesamiento, por los medios de procesamiento del lector, de al menos una peticion de inicializacion del canal seguro enviada por el modulo de seguridad, que comprende un numero impredecible y provocando la consulta del chip por el lector, para obtener al menos un criptograma y los datos representativos de las informaciones vinculadas a la tarjeta, permitiendo esta etapa la etapa de generacion de la clave de sesion que se utiliza para establecer el canal de comunicacion seguro y la transmision al modulo de seguridad, por una parte, de los datos representativos de las informaciones vinculadas a la tarjeta y, por otra parte, dichos datos encriptados utilizando esta clave de sesion, que contiene datos relativos al numero impredecible.

Otro objetivo de la presente invencion es superar al menos algunos inconvenientes de la tecnica anterior proporcionando un procedimiento que permita proteger las transacciones en lmea.

Este objetivo se consigue mediante un procedimiento de transaccion segura, caracterizado porque contiene las etapas del procedimiento de inicializacion segun la invencion y al menos una etapa de transmision de datos entre el modulo de seguridad y el lector, en forma encriptada utilizando dicha clave de sesion, ejecutada en un sistema de transaccion segura segun la invencion.

Segun otra caractenstica, el servidor esta dispuesto para requerir del modulo de seguridad, en cada etapa de transmision de datos con el lector, un encriptado/desencriptado por dicha clave de sesion de los datos transmitidos, estando el lector dispuesto para encriptar/desencriptar tambien los datos intercambiados durante la transaccion.

Otras caractensticas y ventajas de la presente invencion apareceran mas claramente de la lectura de la siguiente descripcion, hecha con referencia a los dibujos adjuntos, en los que:

- la figura 1 muestra una realizacion del sistema segun la invencion,

- la figura 2 muestra una realizacion del procedimiento segun la invencion,

- la figura 3 muestra una realizacion del procedimiento segun la invencion, hasta el establecimiento del canal seguro,

- la figura 4 muestra la continuacion de la realizacion del procedimiento de la figura 3, a partir del establecimiento del canal seguro.

La presente invencion se refiere, por una parte, a un sistema y a un procedimiento de inicializacion de transaccion segura en lmea, por medio del establecimiento de un canal seguro descrito a continuacion. La presente invencion se refiere, por otra parte, a un sistema y a un procedimiento de transaccion segura en lmea, es decir, transmisiones de datos seguras, que se basan en dicho canal seguro. Como ejemplos ilustrativos y no limitantes, los datos transmitidos podran referirse a operaciones que permitan la consulta y gestion de operaciones bancarias corrientes en lmea ("e-banking (banca electronica)") y/o que permitan la suscripcion a productos financieros en lmea ("e- subscription (suscripcion electronica)") y/o que permitan la validacion de solicitudes de retencion ante un destinatario autorizado como, por ejemplo, con los tftulos interbancarios de pago, TIP ("e-billing", “facturacion electronica” en ingles) o y/o que permitan el pago de compras en lmea ("e-commerce (comercio electronico)"), utilizando por ejemplo un protocolo de pago seguro en Internet tal como el protocolo de "3D-securo". La invencion es particularmente ventajosa porque se propone proteger las transacciones mediante un mecanismo resistente a la mayor parte de los ataques conocidos y que permiten atenerse a los problemas de ingeniena social. El termino "transaccion" se refiere, en la presente solicitud, cualquier tipo de transmision de datos a traves de al menos una red de comunicacion, siendo estas transmisiones seguras por medio de la presente invencion. De este modo, el termino "transaccion" podra referirse a una transaccion, por ejemplo, de tipo bancario (por ejemplo, un pago en lmea, etc.), pero la verdad es que podra referirse a otros tipos de transmisiones de datos (por ejemplo, en el caso de envm de informaciones personales, en particular durante el uso de una tarjeta sanitaria u otra). Estas "transacciones" se designan en el presente documento de ser efectuadas entre al menos un usuario y al menos una entidad designada por el termino "proveedor de servicio" (por ejemplo, un establecimiento bancario, una organizacion privada o publica, etc.), que posee un equipo (un conjunto de dispositivos, por ejemplo) espedfico para la ejecucion de la invencion, designado con el termino "equipo (4) proveedor" (o "equipo (4) del proveedor de servicio"), como se detalla a continuacion. El proveedor del servicio habra proporcionado a los usuarios de la presente invencion una tarjeta (2) denominada "segura" (como se explica mas adelante) y un lector (1) de tarjeta espedfico, para permitirle realizar las transacciones en lmea. La tarjeta (2) y el lector (1) se disenan como de ser "suministrados" por el proveedor de servicio pero se mostrara de la lectura de la presente solicitud que la invencion no se limita a la forma en la que los usuarios los han obtenido, siendo este termino utilizado para explicar que el proveedor de servicio conoce las tarjetas de los usuarios (por ejemplo por medio de al menos una base de datos que almacenan identificadores de usuario y de tarjetas), como se explica en detalle a continuacion y posee un equipo (4) proveedor dispuesto para cooperar con los lectores (1) de tarjeta durante las transacciones, como se explica a continuacion.

Como se menciono anteriormente, la presente invencion permite varios tipos de transacciones tales como, a modo de ejemplos ilustrativos y no limitativos, los conocidos con los nombres de "banca electronica", "suscripcion electronica", "facturacion electronica" o "comercio electronico". El comercio electronico utiliza, por ejemplo, el protocolo "3D-seguro" que permite una autenticacion del tenedor de una tarjeta de pago de las compras realizadas en los sitios web, y consiste en asociar el procedimiento de autorizacion financiera con una autenticacion en lmea basada en un modelo que contiene 3 ambitos (el ambito del comprador, es decir, en general, el ambito del comerciante y de la sociedad que le afilio a la red de pago; el ambito del emisor, es decir, en general, el ambito del

5

10

15

20

25

30

35

40

45

50

55

60

titular de la tarjeta y de la sociedad (a menudo su banco) que emitio la tarjeta, el ambito de la interoperabilidad, es decir, en general, el del operador de la red de pago que asegura la interoperabilidad entre los dos primeros ambitos y se asegura de que los flujos financieros desembocan alla donde deben desembocar). Este protocolo se basa en los mensajes enviados a traves de comunicaciones seguras, por ejemplo, por medio de protocolos de tipo SSL ("Secure Sockets Layer", segun la terminologfa en ingles) o TLS ("Transport Layer Security", segun la terminolog^a de ingles) que garantizan la autenticacion del servidor y del cliente por certificados digitales. Cabe senalar que la presente invencion puede ser compatible con la Programa de Autenticacion por Tarjeta (PAC, o CAP para el "Chip Authentication Program ", segun la terminologfa en ingles), que proporciona las especificaciones tecnicas relativas a la utilizacion de tarjetas chip bancarias para la autenticacion de los usuarios y de las transacciones bancarias en lmea y por telefono. Tambien se adopto como contrasena de autenticacion dinamica (DPA). Los clientes de los bancos que recibieron un lector CAP de su banco pueden insertar su tarjeta bancaria en el lector CAP, con el fin de participar en uno de los protocolos de autenticacion respaldados por estas especificaciones. El CAP es una forma de autenticacion que utiliza dos factores a la vez, porque deben ser presentados tarjeta chip y un PIN valido para que una transaccion de resultado, segun varios procedimientos admitidos. Sin embargo, como se ha mencionado en el preambulo de la presente solicitud, los procedimientos admitidos por las especificaciones CAP tienen el inconveniente de quedar vulnerables a algunos ataques mientras que la presente invencion cumple con los requisitos de seguridad CAP pero permite proteger todavfa mas las transacciones.

Ademas, como se menciono anteriormente, la presente invencion se aprovecha de las tarjetas chip designadas aqrn con el termino "tarjeta chip segura" que almacenan al menos una clave simetrica de encriptado e contienen un chip provisto de capacidades criptograficas que utiliza claves simetricas. Podra tratarse, en particular, de tarjetas bancarias, es decir, tarjetas chip de pago tal como las conocidas con el nombre de EMV (para "Europay MasterCard Visa") que permiten proteger los pagos realizados por medio del chip (por ejemplo, del tipo ISO 7816) de la tarjeta que contiene al menos una clave de encriptado simetrico. Sin embargo, la invencion no se limita a las tarjetas bancarias (o tarjeta sanitaria u otras) citadas aqrn como ejemplo ilustrativo y no limitativo pues la invencion solo necesita, en lo que se refiere a la tarjeta, que el chip almacene una clave simetrica de encriptado y los datos relativos a la tarjeta, y que posea al menos capacidad de encriptado simetrico (como por ejemplo, con al menos una aplicacion espedfica implantada en el chip de la tarjeta) que se ejecutan en respuesta a las ordenes recibidas de un lector que acceda a la tarjeta. Cabe senalar que como alternativa, es posible que el lector y la tarjeta interactuen a traves de una comunicacion sin contacto (sin estar la tarjeta, necesariamente, insertada en el lector, pero que este ultimo pueda acceder a ella). El termino "tarjeta segura" se utilizara en la presente descripcion para designar este tipo de tarjetas. La presente invencion no requiere, por consiguiente, el despliegue de nuevas entidades de encriptado (como las "claves de proteccion", las claves USB de encriptado u otro dispositivo a conectar a un terminal y que almacene una clave de encriptado) y preve la utilizacion de tarjetas seguras que permiten una autenticacion solida y mutua entre el equipo proveedor (4) y el chip (20) de la tarjeta, como se detalla a continuacion. Por consiguiente, la invencion puede aprovecharse de las tarjetas que ya se estan utilizando y que ya tienen los medios necesarios para su implantacion (en terminos de la tarjeta: capacidades de criptograffa simetrica, clave de encriptado y los datos acerca de la tarjeta) como, por ejemplo, las tarjetas bancarias de tipo EMV. Cabe senalar que en el caso de tarjetas seguras que requieren la introduccion de un codigo PIN (como las tarjetas EMV), se obtiene incluso una solida y mutua autenticacion entre el proveedor y el propio usuario. Mediante los medios aplicados en la presente invencion, el usuario tiene la seguridad de realizar una transaccion con su proveedor de servicio y este ultimo tiene tambien la seguridad de una transaccion con su cliente (el usuario o al menos un usuario autorizado, siempre que al usuario no le hayan robado su tarjeta y el codigo PIN asociado).

La presente invencion requiere el uso de un lector (1) de tarjeta segura, que contiene medios (12) de procesamiento de datos dispuestos para dialogar con el chip (20) de la tarjeta (2), en particular para obtener del chip (20) las firmas de los datos para el establecimiento del canal seguro y para realizar las transacciones realizadas en lmea. Ademas, estos medios (12) de procesamiento de datos se disponen para realizar operaciones criptograficas sobre los datos suministrados por el chip y para transmitir al equipo (4) proveedor los datos encriptados a traves de un canal seguro (CS).

El lector (1) esta (o sus medios de procesamiento estan) dispuesto (dispuestos) ademas para el establecimiento de un canal (CS) de comunicacion seguro (o "tunel seguro") con al menos un modulo (o dispositivo) de seguridad del equipo (4) proveedor en modo conectado (es decir, durante una comunicacion con el equipo proveedor por medio de al menos una red de comunicacion), por ejemplo, segun un algoritmo 3DES, por ejemplo en el modo CBC, y con una clave de sesion (Kses) previamente generada. Como se menciono anteriormente, la presente invencion utiliza una de las funcionalidades de las tarjetas seguras permitidas por al menos una clave de encriptado almacenada en el chip y proporcionada por el (o conocido del) proveedor de servicio. Cabe senalar que el algoritmo de cifrado 3DES (denominado tambien "Triple DES") que es un algoritmo de cifrado simetrico que encadena tres aplicaciones sucesivas del algoritmo DES (para “Data Encryption Standard", segun la terminologfa en ingles, que es un algoritmo de cifrado por bloques) en el mismo bloque de datos de 64 bits, con 2 o 3 claves DES diferentes solo se cita aqrn a modo de ejemplo ilustrativo y no limitativo. Asimismo, el modo CBC ("Cipher Block Chaining" segun la terminologfa en ingles o "encadenamiento de los bloques") que consiste en aplicar a cada bloque una "OR exclusivo” con el cifrado del bloque precedente antes de que el mismo sea cifrado y que utiliza un vector de inicializacion para hacer unico cada mensaje, citado aqrn solo como ejemplo ilustrativo y no limitativo. En efecto, se entendera de la lectura de la presente solicitud que los procedimientos de encriptado utilizados podran evolucionar en funcion de las normas

5

10

15

20

25

30

35

40

45

50

55

60

y que algunas realizaciones de la presente invencion se aprovechan de los dispositivos de seguridad ya en uso en las tarjetas seguras.

Los sistemas de inicializacion y de transaccion segura en lmea utilizan, de una manera conocida de por sf, al menos una red (RC) de comunicacion. Por ejemplo, esta red puede ser de tipo Internet. En diversas alternativas, la invencion puede utilizar varias redes. Ademas, las redes implicadas pueden ser de varios tipos, como por ejemplo una red de telefoma movil (como por ejemplo las redes de tercera generacion) que permiten una comunicacion de banda ancha con terminales tales como, por ejemplo, telefonos moviles u ordenadores provistos de medios de comunicacion adaptados, etc. Mas habitualmente, puede ser una red de tipo Internet, por ejemplo, alambrica.

Tambien de manera conocida de por sf, las transacciones en lmea se realizan generalmente a partir de un terminal (3), tal como un ordenador, por ejemplo, pero se pueden realizar desde otros tipos de terminales, tales como los telefonos moviles que contienen medios de comunicacion y al menos una aplicacion de navegacion en la red, conocida con el nombre de navegador (o "browser", segun la terminologfa en ingles). Cabe senalar que dicho terminal se designa aqrn como "terminal de usuario", pero es evidente que dicho terminal puede ser propiedad de cualquier entidad, que puede corresponder a diversos tipos de terminales y que esta designacion no debe interpretarse de manera limitativa. En general, es evidente que la navegacion en una red de tipo internet se puede realizar desde diversos tipos de terminales y la invencion no debe limitarse a los ejemplos no limitativos dados aqrn con fines ilustrativos. En cambio, la presente invencion que requiere el uso de un lector (1) de tarjeta segura, es necesario que el terminal (3) pueda bien contener dicho lector directamente en el terminal o bien estar conectado a ese lector por medio de al menos un conector adaptado (por ejemplo, mini-USB, como se encuentra con frecuencia incluso en terminales moviles) y controladores ("drivers" segun la terminologfa en ingles) que permiten el control de un lector de ese tipo, siendo los detalles relativos al dialogo entre el terminal y el lector, en funcion de las transmisiones de datos en la red (a traves del navegador) proporcionados mas adelante en la presente descripcion. En el presente documento no se daran detalles de la disposicion ffsica de los terminales y de los lectores (ni de los controladores ni de otros medios utilizados), ya que el especialista entendera de la lectura de la invencion las disposiciones que son posibles sin apartarse del esprntu de la invencion. Ademas, la invencion preve tambien realizaciones que permiten prescindir de un terminal (3) en el que se debe conectar el lector (1). En estas realizaciones, el lector (1) sera provisto de medios de comunicacion en al menos una red (RC) de comunicacion. Este lector (1), denominado "comunicante" puede, en algunas alternativas, incorporar al menos una aplicacion que permita navegar por la red de comunicacion, para permitir al usuario conectarse al menos al equipo (4) proveedor. Las versiones mejoradas permitiran la conexion a otros servidores (por ejemplo, sitios de compras, etc.). En otras alternativas, el lector (1) no dispondra de un navegador (en su definicion comun de software de navegacion) pero sera configurado para poder conectarse directamente al equipo (4) proveedor, por ejemplo, a traves de medios de comunicacion (por ejemplo, de medios de comunicacion inalambricos como una red de telefoma movil) y a traves de medios de memorizacion que almacenan los datos que le permiten conectarse a ese equipo. Tales datos pueden contener, por ejemplo, al menos una URL ("Universal Resourdes Locator", en ingles) que indica la direccion de al menos un servidor del equipo (4) proveedor, posiblemente con un nombre de usuario y una contrasena. Estos datos pueden, por ejemplo, ser almacenados en los medios de memorizacion del propio lector (1) o en el chip (20) de la tarjeta (2) segura (y extrafdos por el lector para la comunicacion con el proveedor). Por consiguiente, el especialista entendera de la lectura de la presente solicitud que la invencion puede, de hecho, utilizar un dispositivo tal como un lector de tarjeta segura que se puede conectar a un terminal comunicante o formar el mismo dicho terminal comunicante y que, en el caso de que el propio lector forme un terminal comunicante, el navegador y el modulo de puerta de enlace (descritos mas adelante en la presente solicitud) pueden omitirse ya que estos ultimos se utilizan, respectivamente, para conectarse al equipo (4) proveedor y controlar la transmision de los datos del navegador entre el terminal y el lector. Sin embargo, en algunas realizaciones, el navegador y el modulo de puerta de enlace pueden implantarse a pesar de todo en este tipo de lector comunicante, para permitir mas funcionalidades (especialmente en el caso en el que el navegador sea un verdadero software de navegacion que requiera la integracion de un modulo de puerta de enlace como se ha descrito en la presente solicitud).

Por otra parte, tambien se sabe que las transacciones en lmea utilizan al menos un equipo (4) de un proveedor de servicio (por ejemplo, un establecimiento bancario o un organismo privado o publico) que comprende al menos un servidor (40) dispuesto para gestionar las comunicaciones, y en particular las transacciones, con los navegadores (N) de los terminales (3). Las transacciones en lmea, tales como las dadas como ejemplo ilustrativo y no limitativo, en la presentacion del ambito tecnico ("banca electronica", etc.), requieren generalmente la conexion del usuario (a traves del navegador de un terminal o, segun las alternativas descritas anteriormente, a traves del lector comunicante) con el servidor (40) para permitir una autenticacion de usuario y una autorizacion de la transaccion por el servidor (40). Ademas, el equipo proveedor (4) contiene tambien, en general, en la tecnica anterior al menos un modulo de seguridad (41) que esta dispuesto para desencriptar y verificar las firmas de transacciones proporcionadas por las tarjetas (pudiendo este modulo, por ejemplo, ser implantado en al menos un servidor del equipo (4) proveedor). Este modulo de seguridad (41) puede, a modo de ejemplo ilustrativo y no limitativo, contener, por ejemplo, como se conoce en el ambito bancario, un "entorno criptografico", que podra ser, por ejemplo, como los conocidos con el nombre de HSM (para “Hardware Security Module", segun la terminologfa en ingles) que permiten las operaciones de desencriptado de las firmas de las transacciones y de la verificacion de esas firmas. En general, un servidor del equipo (4) proveedor podra, en su caso, almacenar los datos relativos a las transacciones y/o a su encriptado. De manera conocida de por sf, el equipo proveedor (4) puede contener un primer servidor, denominado

5

10

15

20

25

30

35

40

45

50

55

60

frontal (como se muestra en la figura 1) al que se conectan los usuarios para realizar transacciones, y un segundo servidor, denominado servidor (40) de operaciones, que gestiona los inicios de sesion de los usuarios y los intercambios de datos requeridos en funcion de las transacciones solicitadas (por el usuario o por un servidor de un sitio de compras, por ejemplo), transmitiendo los datos sensibles al modulo de seguridad (41) para el cifrado/descifrado. El especialista comprendera, por consiguiente, que el equipo proveedor (4) podra contener al menos un servidor (40) (por ejemplo, un unico servidor que cumple las funciones del servidor frontal y del servidor de operaciones) y al menos un modulo (41) de seguridad (por ejemplo, "entorno criptografico", por ejemplo de tipo HSM), implantado en el mismo servidor o (como se muestra en la figura 1) en al menos un dispositivo diferente.

En algunas realizaciones, el lector (1) y el equipo proveedor (4) estan conectados a traves, respectivamente, de los medios de comunicacion, implantados directamente en el lector o a traves de un terminal (3), por ejemplo mediante un navegador (N) y los medios de comunicacion de al menos un servidor (40), a traves de una comunicacion segura segun un protocolo de tipo SSL/TLS dentro del cual esta abierto el canal (CS) seguro. Se sabe en este ambito que las conexiones de los usuarios en los servidores de su proveedor (proveedores) de servicio (servicios) (por ejemplo, un establecimiento bancario) se transfieren por conexiones seguras (por ejemplo, segun el protocolo https). La presente invencion permite el uso de protocolos de seguridad, por ejemplo del tipo SSL/TLS para proteger la sesion de comunicacion, pero permite ademas crear un canal (CS) seguro dentro de esta sesion, para proteger aun mas las informaciones sensibles intercambiadas, por ejemplo para permitir resistir principalmente los ataques "hombre en el medio" u "hombre en el navegador". En otras realizaciones, la comunicacion con el equipo (4) proveedor podra hacerse segun otros tipos de protocolos, principalmente los protocolos no seguros, ya que el establecimiento del canal (CS) seguro se realiza desde el principio de la comunicacion para que ningun dato sensible circule "en abierto" por la red. Por ejemplo, desde que el lector (1) se activa (por ejemplo, cuando se conecta a un terminal comunicante o cuando accede a la tarjeta), se conecta (mediante sus medios de comunicacion o los del terminal) con el equipo (4) proveedor a traves de la red (RC) de comunicacion (por ejemplo, mediante una URL almacenada en los medios de memorizacion y extrafda por el lector) para establecer el canal seguro.

Se comprende, por consiguiente, que los sistemas de inicializacion y de transaccion segura en lmea, a traves de al menos una red (RC) de comunicacion que contiene al menos un lector (1) de tarjeta (2) segura, que se comunica (por ejemplo, a traves de un terminal (3) que contiene medios (30) de procesamiento de datos que ejecutan al menos un navegador (N) dispuesto para comunicarse a traves de dicha red (RC), o directamente mediante los medios de comunicacion) con al menos un equipo (4) de un proveedor de servicio que comprende al menos un servidor (40) dispuesto para gestionar las transacciones con los lectores (1) o navegadores (N) de terminales (3) de los usuarios, por el intercambio de datos representativos de transacciones, y al menos un modulo de seguridad (41), dispuesto para proteger estas transacciones (en cooperacion con el lector).

Mas concretamente, los sistemas segun la invencion estan dispuestos para el establecimiento de un canal (CS) seguro entre el lector (1) de la tarjeta (2) segura y el modulo de seguridad (41), por medio de al menos una clave de encriptado (CF) y de los datos (D_chip) representativos de al menos una informacion asociada a la tarjeta, almacenadas en el chip de la tarjeta segura. Esta clave de encriptado corresponde a un "secreto compartido" por la tarjeta y el equipo (4) proveedor y se utiliza para generar por ambas partes una clave de sesion (Kses) que permite el encriptado de los datos de las transacciones transmitidas a traves del canal seguro. De este modo, el modulo de seguridad (41) (o servidor) y el lector (1) utilizan la misma clave de sesion para encriptar/desencriptar los datos que se intercambian para la transaccion. Se comprende, por consiguiente, que por estos encriptados/desencriptados efectuados por ambas partes, se establece un canal seguro (CS) entre las dos entidades para permitir que los datos sensibles no puedan ser violados. Estos datos (D_chip) representativos de las informaciones vinculadas a la tarjeta corresponden a los datos "publicos" porque no son sensibles y pueden, por consiguiente, circular sin encriptar por la red. Estos datos (D_chip) publicos se envfan al equipo (4) proveedor para que pueda identificar la tarjeta (2) y realizar las mismas operaciones criptograficas que la tarjeta (2) y el lector (1). En el presente documento, mediante la expresion "establecimiento de un canal seguro" se entiende el hecho de que el equipo (4) proveedor (especialmente el modulo (41) de seguridad) y el lector (1) se conectan para calcular una misma clave de sesion (Kses) que utilizan para encriptar/desencriptar los datos de las transacciones intercambiadas mas adelante, en transito por el canal (CS) seguro. La presente invencion se refiere, por consiguiente, a un procedimiento y a un sistema de inicializacion de transacciones seguras que se basan en el establecimiento de un canal seguro (CS) para las transacciones. Una vez establecido este canal (CS), la transaccion se inicializa y puede ejecutarse a traves del canal seguro. La presente invencion tambien se refiere, por consiguiente, a un procedimiento y un sistema de transacciones seguras que se basan en dicha inicializacion mediante el establecimiento de un canal seguro (CS). La presente invencion propone, por consiguiente, sistemas resistentes a los diversos tipos de ataques conocidos que utilizan, de manera ventajosa, los mecanismos de seguridad ya en uso en las tarjetas seguras, pero aprovechandose de ellas a distancia en relacion con el equipo del proveedor de servicio por medio de al menos un canal (CS) seguro que permita garantizar la seguridad de las transacciones, o incluso su total confidencialidad en ciertas realizaciones que se detallan mas adelante. En efecto, en lugar de proponer una simple firma de las transacciones por la tarjeta (2) (mediante el lector), realizada al final de la transaccion para validar esta ultima, como en la tecnica anterior (particularmente en los sistemas de tipo CAP), se propone inicializar la transaccion estableciendo un canal seguro (CS) que se basa en los mismos mecanismos criptograficos, pero cuyo uso se modifica para la aplicacion de la presente invencion. El uso de estos mecanismos criptograficos se modifica, en particular, debido a que el (los) criptograma (criptogramas) generado (generados) por la tarjeta (2) son utilizados por

5

10

15

20

25

30

35

40

45

50

55

60

el lector (1) para generar una clave de sesion (Kses), por ejemplo, mediante la concatenacion de dos criptogramas proporcionados por la tarjeta (2). Por otra parte, el modulo de seguridad esta aqu dispuesto para generar tambien la misma clave sesion (Kses) que luego se utilizara por este ultimo y por el lector para encriptar/desencriptar los datos que deben intercambiarse para la transaccion propiamente dicha. En cambio, en la tecnica anterior, especialmente en los sistemas CAP, la tarjeta envfa simplemente un criptograma al final de la transaccion al modulo de seguridad (41) que verifica simplemente si el criptograma es correcto. Ademas, el uso de estos mecanismos se modifica durante las transacciones pues las operaciones de encriptado/desencriptado se realizan por ambas partes para los envfos de datos a traves del canal seguro (CS), tanto desde el servidor al lector como desde el lector al servidor. En la tecnica anterior, especialmente en los sistemas CAP, el servidor no encripta los datos a enviar a la tarjeta o al lector. Se comprende, por consiguiente, que el encriptado por el modulo de seguridad de los datos enviados al lector que los desencripta es un uso ventajoso y nuevo de los mecanismos de los que se conoce solo una parte. Ademas, el establecimiento del canal seguro se basa en el intercambio de informaciones entre la tarjeta (mediante el lector) y el servidor. Cuando todos los datos relativos a la transaccion solo se introducen, se procesan y/o se visualizan en el lector (y nada en el terminal al que el lector puede estar conectado), la invencion permite una total confidencialidad de los datos, ademas de la seguridad proporcionada por el canal seguro (CS), como se detalla mas adelante.

El sistema de inicializacion segun la invencion contiene al menos un lector (1) de tarjeta chip con acceso al equipo (4) proveedor a traves de dicha red (RC) de comunicacion y que comprende medios (12) de procesamiento dispuestos para, por una parte, intercambiar datos con al menos un chip (20) de al menos una tarjeta (2) segura, con el fin de obtener del chip (20), y transmitir al modulo de seguridad (41), los datos (D_chip), denominados publicos, representativos de al menos una informacion asociada con la tarjeta (2) y, por otra parte, generar, en cooperacion con dicho chip (20), al menos una clave de sesion (Kses), y transmitir al modulo de seguridad (41), los datos encriptados mediante esta clave de sesion (Kses). El modulo de seguridad (41) esta dispuesto para calcular dicha clave de sesion (Kses), a partir de dichos datos publicos (D_chip) recibidos y de al menos una clave de encriptado (CF).

Este calculo de la clave de sesion (Kses) por el lector (1) y el modulo de seguridad (41) que permite la inicializacion de la transaccion mediante el establecimiento de un canal (CS) para la comunicacion segura en el que los datos representativos de la transaccion podran circular en forma encriptada por dicha clave de sesion (Kses).

Para el calculo de la clave de sesion (Kses) a partir de los datos recibidos, el modulo de seguridad (41) puede realizar los mismos calculos que el lector (1) y la tarjeta (2). Por ejemplo, el lector puede generar la clave de sesion a partir de al menos un criptograma (ARQC, AaC) generado por el chip (20) de la tarjeta (2), como se detalla en la presente solicitud, y el modulo de seguridad (41) puede tambien generar al menos un criptograma (ARQC, AAC), y despues calcular la clave de sesion (Kses) a partir de este (estos) ultimo (ultimos).

El sistema segun algunas realizaciones se describira ahora con referencia a la figura 1. Cabe senalar que las diversas realizaciones descritas en la presente solicitud se pueden combinar entre sf a menos que no se mencione explfcitamente lo contrario, o que no sean compatibles entre sf y/o que su combinacion no funcione, ya sea por el sistema o por el procedimiento.

El sistema de transaccion segun la presente invencion contiene, por consiguiente, al menos un lector (1) de una tarjeta chip conectado al terminal (3) usuario y que comprende medios (12) de procesamiento dispuestos especialmente para intercambiar datos con una tarjeta (2) segura de un usuario a la que accede el lector (debido a que la tarjeta esta insertada en el lector o debido a una lectura a distancia en el caso de tarjetas y lectores denominados "sin contacto"). El lector (1) puede tambien contener medios (10) de representacion visual y medios (11) de entrada (tal como una pantalla y una pluralidad de teclas, o incluso una pantalla tactil), para permitir al usuario verificar las informaciones visualizadas y entrar o validar los datos, segun las diversas realizaciones. Los medios (12) de procesamiento del lector (1) estan dispuestos tambien para realizar un procesamiento local de los datos como, por ejemplo, las operaciones de cifrado (encriptado) o descifrado (desencriptado) de los datos representativos de una transaccion, por ejemplo en funcion de los mensajes intercambiados con la tarjeta o con el equipo (4) proveedor. Cabe senalar que la tarjeta (2) con chip (20) se llama "de un usuario" y se sabe en este ambito que pertenecen exclusivamente a un usuario. Sin embargo, tambien se sabe que las tarjetas seguras, por ejemplo del tipo EMV, que tienen varios titulares, y esta designacion no debe interpretarse, por consiguiente, de manera limitativa sino para sugerir que permite la identificacion (completamente fiable en algunos casos) del usuario que hace uso de ella como un usuario autorizado (por la verificacion del codigo PIN, en concreto). Las tarjetas (2) seguras son conocidas de la tecnica anterior y contienen al menos un chip (20) que permite firmar las transacciones, en particular una vez realizada la autenticacion de su usuario, por validacion de un codigo de identificacion personal valido (codigo PIN, para "Personal Identification Number”, segun la terminologfa en ingles). No se daran detalles, por consiguiente, sobre el funcionamiento de estas tarjetas mas alla de las etapas mas espedficas en la implantacion de la presente invencion.

Los medios (12) de procesamiento del lector (1) de la tarjeta segura estan, ademas, dispuestos para generar, en cooperacion con el chip (20) de la tarjeta (2), al menos una clave de sesion (Kses). Para generar una clave de sesion (Kses), el lector (1) obtiene de la tarjeta (2) una serie de datos que se detallan mas adelante segun diversas realizaciones. En particular, la clave de sesion (Kses) es generada por el lector (1) en cooperacion con el chip (20) que almacena al menos una clave de encriptado (CF) y datos (D_chip) publicos. Los medios (12) de procesamiento

5

10

15

20

25

30

35

40

45

50

55

60

del lector (1) pueden, por ejemplo, ejecutar al menos una aplicacion espedfica para la implantacion de la invencion (principalmente para el establecimiento del canal seguro mediante el encriptado/desencriptado de los datos). En algunas realizaciones, los medios (12) de procesamiento del lector (1) estan dispuestos para recibir del modulo de seguridad (41), y procesar al menos una peticion de establecimiento (inicializacion) del canal (CS) seguro, provocando la consulta del chip (20) por el lector (1) para obtener al menos un criptograma (AAC, ARQC) y los datos (D_chip) representativos de las informaciones asociadas a la tarjeta (2), lo que permite a los medios (12) de procesamiento del lector (1) generar la clave de sesion (Kses) que sirve para establecer el canal (CS) de comunicacion seguro y transmitir al modulo de seguridad (41), por una parte, los datos (D_chip) representativos de las informaciones asociadas a la tarjeta (2) y, por otra parte, dichos datos encriptados utilizando esta clave de sesion (Kses). En algunas realizaciones, esta peticion de establecimiento del canal puede contener un numero impredecible (UN) aumentando la seguridad como se detalla mas adelante. En este caso, los datos encriptados por el lector (1) utilizando la clave de sesion (Kses) contendran los datos relativos a ese numero impredecible (UN). Por ejemplo, el lector genera un numero de sesion (Nses) que puede, por ejemplo, corresponder a una concatenacion de ese numero impredecible (UN) con un contador de transaccion (conocido con el nombre de ATC en el ambito de la banca) y puede cifrar este numero de sesion (Nses) por la clave de sesion (Kses) para enviarlo al modulo de seguridad (41). Al establecer el canal (CS) seguro, el lector (1) puede solicitar la introduccion del codigo PIN por parte del usuario, con el fin de autentificar a este ultimo para acondicionar la generacion del (de los) criptograma (criptogramas). En respuesta al pedido de establecimiento del canal, el lector envfa al equipo (4) proveedor al menos los datos (D_chip) representativos de las informaciones asociadas a la tarjeta (2). Estos datos pueden ser enviados sin encriptado previo por el lector (1), como se menciono anteriormente. El modulo de seguridad (41) esta dispuesto para calcular la clave de sesion (Kses) a partir de al menos una clave de encriptado (CF) y los datos (D_chip) publicos que le son transmitidos por el lector (1), que los ha obtenido ante el chip (20) de la tarjeta (2). Estos intercambios de datos permiten, por consiguiente, la inicializacion de la transaccion dado que esta clave de sesion (Kses) permite el establecimiento de canal seguro (CS) entre el modulo de seguridad (41) y el lector (1) por medio de encriptados/desencriptados de los datos intercambiados entre estos ultimos. Los datos intercambiados para permitir la transaccion (por ejemplo, para definir diversos parametros de la transaccion, para validar la transaccion, etc.) se encriptan entonces desde el principio (por el lector y el modulo de seguridad) a diferencia de algunas soluciones de la tecnica anterior (principalmente CAP) donde solo la validacion de la transaccion se basa en una firma por la propia tarjeta (2) (y no un encriptado por ambas partes por el modulo de seguridad y el lector).

En algunas realizaciones, el chip (20) de la tarjeta (2) esta, de hecho, dispuesto para generar, a partir de la clave de encriptado (CF), al menos un criptograma (AAC, ARQC) utilizado por los medios (12) de procesamiento del lector (1) para generar la clave de sesion (Kses) que sirve para el establecimiento del canal (CS) seguro. El (los) criptograma (criptogramas) generado (generados) por la tarjeta puede (o pueden) ser, por ejemplo, del tipo de los criptogramas conocidos con el nombre de AAC (para “Application Authentication Cryptogram”, segun la terminologfa en ingles) y/o con el nombre de ARQC (para “Authorization ReQuest Cryptogram” segun la terminologfa en ingles) convencionalmente conocidos en este ambito. En algunas alternativas de realizacion, el chip puede generar los dos tipos de criptogramas y sera su confluencia lo que permita al lector (1) generar la clave de sesion (Kses) (por ejemplo, por una concatenacion de dos criptogramas).

En algunas realizaciones, el modulo de seguridad (41) utiliza al menos una clave, denominada clave madre (CM) que se utiliza para la generacion de las claves (CF) de las tarjetas (2) seguras proporcionadas por el proveedor de servicio, denominadas claves hijas (CF), siendo cada una de las tarjetas (2) proporcionadas identificables a partir de al menos una informacion contenida en los datos (D_chip) publicos.

En estas realizaciones, los medios (12) de procesamiento del lector (1) transmiten al modulo de seguridad (41) los datos (D_chip) publicos para que pueda encontrar la clave de encriptado (CF) que se utilizara para calcular la clave de sesion (Kses) y permitir asf el encriptado/desencriptado de los datos representativos de la transaccion, transmitidos a traves del canal (CS) seguro. Segun un ejemplo particular, el modulo de seguridad (41) utiliza un algoritmo, por ejemplo, del tipo 3DES, para generar las claves de encriptado (CF) a partir de la clave madre (CM) y de los datos (D_chip) publicos. Dicho algoritmo permite, por consiguiente, al modulo de seguridad (41), por medio de los datos (D_chip) publicos que recibe del lector, encontrar la clave hija a utilizar a partir de la clave madre (CM). Para mayor seguridad, cabe senalar que la clave madre (CM) utilizada por el modulo de seguridad (41), se puede almacenar en forma encriptada por al menos una clave de encriptado, denominada clave secreta (SK). Cabe senalar tambien que la clave de encriptado (CF) solo esta realmente presente de forma furtiva en el modulo de seguridad (41), cuando se calcula la clave de sesion (Kses).

En algunas realizaciones correspondientes a una alternativa a las realizaciones del parrafo anterior, el equipo (4) del proveedor de servicio contiene al menos una base de datos que almacenan las claves de encriptado (CF) de las tarjetas (2) seguras proporcionadas por el proveedor de servicio, accediendo el modulo de seguridad (41) a esta base de datos para encontrar, en funcion de los datos (D_chip) publicos recibidos del lector (1) de la tarjeta chip, la clave (CF) a utilizar para calcular la clave de sesion (Kses). Para mayor seguridad, cabe senalar aqrn que las claves de encriptado (CF) conservadas en el modulo de seguridad (41) pueden ser almacenadas en forma encriptada, por al menos una clave de encriptado, denominada clave secreta (SK).

En algunas realizaciones, los datos (D_chip) representativos de las informaciones vinculadas a la tarjeta (2) pueden ser representativos de al menos una informacion que permite al menos identificar la tarjeta utilizada para la

5

10

15

20

25

30

35

40

45

50

55

60

transaccion. Segun diversas realizaciones, estos datos tambien pueden representar al menos una informacion relativa a las posiciones (o valores) de los contadores. Estos datos pueden ser, por ejemplo, como los actualmente conocidos en el ambito de las tarjetas bancarias, que contienen un numero de cuenta primaria (PAN, de "Primary Account Number”, en ingles) que puede ser utilizado por el modulo de seguridad (41) para encontrar la clave hija (a partir de la clave madre o entre las claves hijas almacenadas, segun los 2 ejemplos descritos en los 2 parrafos anteriores). Otros datos utilizables por el modulo de seguridad (41) en la presente invencion, para encontrar el (los) criptograma (criptogramas), son datos conocidos con el identificador IAD (para “Issuer Authentication Data” segun la terminologfa en ingles) y que pueden contener los datos representativos de las informaciones conocidas con los acronimos KDI ("Key Derivation Index", segun la terminologfa en ingles), CVN (para “Cryptogram Version Number", segun la terminologfa de ingles) y CVR (para “Card Verification Result” segun la terminologfa en ingles). Ademas, estos datos pueden contener tambien datos conocidos con los nombres ingleses de "Card Risk Management Data Object List 1” (CDOL1), "Card Risk Management Data Object List 2" (CDOL2), "Application Transaccion Counter (contador de transacciones de la aplicacion" (ATC) y "Primary Account Number Sequence (secuencia del numero de cuenta primaria" (PSN). Cabe senalar que los ejemplos de datos representativos de las informaciones asociadas a la tarjeta que se dan aqu no son limitativos y solo representan ejemplos seleccionados, en particular en el ambito de la banca, para detallar la manera en que el modulo de seguridad (41) puede calcular la clave de sesion que permite el cifrado de los datos que circulan por el canal (CS) seguro.

Cualquiera o todos estos datos (D_chip) de la tarjeta (2) permite al modulo de seguridad (41) calcular la clave de sesion (Kses). Asimismo, segun diversas realizaciones, los datos publicos (D_chip) representan al menos una informacion asociada a la tarjeta y permiten al menos identificar la tarjeta (2). Por ejemplo, el modulo de seguridad (41) puede estar dispuesto para:

- encontrar la clave de encriptado (CF) a utilizar por al menos una parte de estos datos (D_chip), por ejemplo, el PAN de la tarjeta (2) que les transmite el lector (1),

- generar al menos un criptograma (AAC, ARQC) a partir de al menos una parte de estos datos (D_chip) y de la clave de encriptado (CF), por ejemplo mediante la ejecucion de al menos una aplicacion tal como la utilizada por la tarjeta para generar el (los) criptograma (criptogramas),

- calcular la clave de sesion (Kses) de la misma manera que el lector (1) a partir del (de los) criptograma (criptogramas) (AAC, ARQC), por ejemplo, por medio de una aplicacion al menos parcialmente equivalente a la del lector.

En algunas realizaciones, el establecimiento del canal (CS) seguro es iniciado por el equipo (4) proveedor (cuando el lector (1) se haya conectado con este ultimo o cuando una solicitud de transaccion es recibida por este ultimo). Por ejemplo, cuando las tarjetas (2) contienen varias aplicaciones para generar los criptogramas (lo que permite aumentar el nivel de seguridad), el equipo (4) proveedor (ya sea el servidor (40) de las operaciones, ya sea el modulo (41) la seguridad) puede enviar un orden de inicializacion del canal (CS) seguro al lector (1), especificando al menos una aplicacion a utilizar para generar los criptogramas, por medio de al menos un identificador de aplicacion (AID, para "Application IDentifier", segun la terminologfa en ingles). Se sabe que los chips (20) de las tarjetas (2) seguras almacenan a veces al menos una lista que da un orden de prioridad a sus aplicaciones. El identificador de la aplicacion permite que el chip no utilice las aplicaciones en este orden sino en funcion de lo que le es indicado por el equipo (4) proveedor. Como alternativa, el equipo (4) proveedor puede almacenar las mismas listas y el identificador de aplicacion transmitido puede, por consiguiente, indicar simplemente el numero de aplicacion en la lista. En otras alternativas mas simples, las listas del equipo (4) proveedor permiten prescindir de dicho identificador de aplicacion. En otras realizaciones, el canal (CS) seguro se podna iniciar por el lector (1) que transmita al equipo (4) proveedor dicho identificador de aplicacion que le es suministrado por la tarjeta (2) cuando genera al menos un criptograma o que habra utilizado para indicar a la tarjeta que aplicacion utilizar para generar el (los) criptograma (criptogramas). Cabe senalar que los mismos mecanismos para identificar la aplicacion se pueden utilizar para informar al lector acerca de la aplicacion que se debe utilizar para generar la clave de sesion (en el caso de que contuviera varias aplicaciones para esta funcion) o para informar al equipo (4) proveedor sobre la aplicacion que ha utilizado.

Algunas realizaciones contienen un mecanismo que permite aumentar aun mas la seguridad del encriptado. Este mecanismo se basa en un numero impredecible (UN) mencionado anteriormente, que es generado por el equipo (4) proveedor (por el servidor (40) de las operaciones o por el modulo (41) de seguridad), al establecer el canal (CS) seguro. Este numero impredecible (UN) es transmitido al lector (1) para formar una incertidumbre de la cual se generara la clave de sesion (Kses). Alternativamente, el numero impredecible (UN) puede ser generado por la tarjeta (2) o el lector (1), o incluso ser introducido por el usuario en el lector (1) y transmitido al equipo (4) proveedor, pero la seguridad mejora cuando es el servidor quien lo envfa al lector. En algunas realizaciones que combinan las realizaciones o las alternativas de las realizaciones anteriores, para poder aumentar aun mas el nivel de seguridad, el numero impredecible (UN) y el identificador de aplicacion se transmiten ambos en el momento del establecimiento (inicializacion) del canal (CS) seguro (ya sea a solicitud del lector o del proveedor).

Se comprende, por consiguiente, que en algunas realizaciones particularmente seguras, el lector (1) puede solicitar al chip (20) de la tarjeta generar un primer criptograma (por ejemplo ARQC) especificando un numero impredecible (UN). El chip (20) devolvera entonces un primer criptograma, por ejemplo, con un contador de transaccion (ATC, por ejemplo) y con datos del tipo IAD (por ejemplo, DKI, CVN y cVr). El lector puede entonces solicitar al chip (20) de la tarjeta generar un segundo criptograma (por ejemplo, AAC) especificando, por ejemplo, el numero impredecible (UN) de nuevo. El chip (20) devolvera entonces un segundo criptograma, por ejemplo, con un contador de transaccion

5

10

15

20

25

30

35

40

45

50

55

(ATC, por ejemplo) y con los datos del tipo IAD (por ejemplo, DKI, CVN y CVR). El lector (1) puede generar entonces la clave de sesion (Kses) concatenando los criptogramas primero y segundo.

Por otra parte, en algunas realizaciones, el lector (1) esta dispuesto para generar un numero de sesion (Nses). Este numero de sesion (Nses) esta vinculado al numero impredecible (UN) y al contador de transaccion (por ejemplo ATC) asociado con un identificador de usuario de la tarjeta (2). Asimismo, el lector (1) genera el numero de sesion (Nses) por la combinacion del numero impredecible (UN) y el contador de transaccion (por ejemplo, por medio de una concatenacion).

En estas realizaciones, una vez calculada la clave de sesion, el lector puede transmitir el numero de sesion (Nses) al equipo (4) proveedor, en forma encriptada por la clave de sesion (Kses). Este numero de sesion (Nses) permite a continuacion al equipo (4) proveedor identificar el lector (1) con el que las transacciones estan en marcha. El servidor (40) de operaciones puede utilizar este numero de sesion (Nses) para rastrear las operaciones realizadas. Por ejemplo, el servidor (40) de operaciones puede solicitar encriptados/desencriptados al modulo de seguridad que le indica el numero de sesion. Ademas, el equipo (4) proveedor puede ser dispuesto para generar un numero de secuencia (Nseq) asociado a cada transaccion e incrementado en cada peticion enviada al lector (1). De este modo, se mantiene un registro de cada orden (Nseq) para cada operacion (Nses). Los datos que circulan a traves del canal seguro pueden, por consiguiente, estar siempre acompanados de un numero de sesion (Nses), de un numero de secuencia (Nseq) y estar encriptados por la clave de sesion (Kses).

Una vez establecido el canal (CS) seguro, el lector (1) puede dialogar con el equipo (4) proveedor de forma segura y acceder a la tarjeta (2) para obtener diversos tipos de datos. En algunas realizaciones, los medios (12) de procesamiento del lector (1) estan dispuestos para recibir al menos un mensaje encriptado que requiere la consulta del chip (20), procedente del equipo proveedor (4), y desencriptar este mensaje utilizando la clave de sesion (Kses), de manera que envfe a la tarjeta (2) al menos una peticion de APDU de consulta del chip (20).

En general, el lector esta dispuesto para responder a ordenes o peticiones (por ejemplo, a traves de estos mensajes encriptados) enviadas por el equipo (4) proveedor (por ejemplo, el servidor (40) de operaciones). Estas peticiones pueden referirse, como ejemplos ilustrativos y no limitativos, a:

- una solicitud de confirmacion de la conexion del lector (1) en el terminal (3) y/o una solicitud de identificacion del lector (sin necesitar el intercambio con la tarjeta)

- una orden de inicializacion del canal seguro,

- una solicitud de representacion visual de las informaciones enviadas por el equipo (4) proveedor, para confirmacion (validacion) por el usuario,

- una solicitud de representacion visual de una invitacion para la entrada de datos por parte del usuario,

- una solicitud de firma de datos,

- las solicitudes de consulta del chip (peticion APDU), por ejemplo, recibidas en forma de mensaje encriptado, desencriptados por el lector que interroga al chip.

En algunas realizaciones, el servidor (40) de operaciones del equipo proveedor (4) esta dispuesto para gestionar el establecimiento y la utilizacion del canal (CS) seguro conservando (almacenando) el numero impredecible (UN), el numero de secuencia (Nseq) asociado con cada transaccion e incrementado en cada peticion enviada al lector (1), y el numero de sesion (Nses).

En algunas realizaciones, el modulo de seguridad (41) del equipo proveedor (4) esta dispuesto para almacenar la clave de sesion (Kses) en los medios de memoria y/o para encriptar la clave de sesion (Kses) utilizando una clave, denominada clave maestra (KM), y transmitirla al servidor (40) para almacenamiento en forma encriptada ([Kses]KM) en los medios de memorizacion. Asimismo, por ejemplo, el servidor (40) de operaciones, encargado de la gestion de las comunicaciones con el usuario (a traves del terminal y del lector) conserva la clave de sesion (pero en forma encriptada por la clave del modulo de seguridad para mayor seguridad, ya que el servidor no puede ser tan seguro como el modulo de seguridad) y la reenvfa al modulo de seguridad a cada solicitud de encriptado/desencriptado. Los intercambios con el usuario no tienen entonces que ser seguidos por el modulo de seguridad que simplemente realiza las operaciones de encriptado/desencriptado en respuesta a las solicitudes del servidor (40) de operaciones que gestiona las otras operaciones, principalmente identificando la transaccion en marcha con el numero de sesion (Nses) y la peticion en marcha con el numero de secuencia (Nseq).

El equipo (4) proveedor, principalmente el servidor (40) de operaciones esta dispuesto, por consiguiente, para recoger estos datos (D_chip) representativos de las informaciones vinculadas a la tarjeta (2) y, en algunas realizaciones, para conservar los elementos siguientes asociados con la operacion (al menos el tiempo de la operacion):

- el criptograma ([Kses]KM) de la clave de sesion (Kses), devuelto por el modulo de seguridad (41),

- el n.° de sesion (Nses), que puede, por ejemplo, estar constituido por 4 octetos del UN y 2 octetos del ATC asociado con el identificador del titular,

- n.° de secuencia (Nseq) durante una sesion (operacion), por ejemplo, constituida por 2 octetos e incrementada en cada peticion u orden enviada al lector (1).

Ademas, el servidor (40) de operaciones puede estar dispuesto para verificar la consistencia de la informacion

5

10

15

20

25

30

35

40

45

50

55

60

controlando que un numero de sesion correcto (en comparacion con el n.° conservado) este presente cuando el descifrado de los datos recibidos del lector (1), y para verificar que el numero de secuencia (Nseq) este estrictamente creciendo en una sesion. Por ultimo, tambien puede estar dispuesto para verificar en los datos (D_chip) que se ha completado la autenticacion del titular (PIN).

Los datos sobre la transaccion se pueden almacenar tambien, especialmente para prever los casos de oposicion, aunque la validacion de las transacciones realizadas por el usuario autentificado por su codigo pueda hacer que las transacciones no sean rechazables.

En algunas realizaciones en las que la invencion utiliza un navegador (software de navegacion ejecutado por los medios de procesamiento del terminal (3) de usuario o del lector (1) directamente), la invencion preve un modulo de puerta de enlace (ME) que permite transmitir los datos recibidos desde el equipo (4) proveedor al lector (1). De hecho, los navegadores (N) conocidos no permiten, en la actualidad, transmitir los datos recibidos a traves de una red de comunicacion hacia un lector de tarjetas. En el caso de un navegador ejecutado por los medios (30) de procesamiento de un terminal (3) de usuario, se necesitara al menos un modulo (ME) de puerta de enlace ejecutado por esos medios (30) de procesamiento. En el caso de un lector de comunicacion mencionado anteriormente, este modulo, opcionalmente, se puede omitir. Este modulo de puerta de enlace esta dispuesto para controlar los intercambios de los datos que circulan por el canal (CS) seguro entre el modulo de seguridad (41) y el lector (1), transmitiendo al lector (1) los datos recibidos del equipo proveedor (principalmente el servidor (40) de operaciones) por el navegador (N). En algunas realizaciones, este modulo de puerta de enlace (ME) puede ejecutarse dentro del entorno de software proporcionado por el navegador. Por ejemplo, este modulo de puerta de enlace puede ser un modulo de extension ("plug-in (enchufable)", segun la terminologfa en ingles) del navegador (N). Se puede implantar en forma de una aplicacion, por ejemplo de tipo JAVA®. La invencion puede, por consiguiente, prever diversos tipos de implantacion, tal como los modulos enchufables, o de codigo descargable o en el futuro, los navegadores pueden contener una funcion de este tipo. Alternativamente, tambien es posible que el lector y/o la tarjeta almacene (almacenen) los datos que permiten la instalacion en el terminal de este modulo. De este modo, el terminal (3) de usuario, en el momento de la conexion del lector o/y cuando el lector acceda a la tarjeta, pueda encontrarse provisto automaticamente del modulo de puerta de enlace permitiendo las transmisiones de datos en el canal seguro.

Por ejemplo, tal modulo (ME) de puerta de enlace puede permitir que el navegador verifique la presencia del lector, confirmando al navegador esta presencia o, en caso de ausencia o respuesta inadecuada, provocando la representacion visual de un mensaje que invite al usuario a conectar el lector. En general, el modulo de puerta de enlace sera responsable de transmitir al lector las solicitudes recibidas por el navegador, tales como las solicitudes detalladas anteriormente como ejemplos ilustrativos y no limitativos (consulta del chip, validacion de los datos, firma de los datos, invitacion a la entrada, etc.) y se encargara de transmitir la (o las) respuesta (respuestas) del lector (1) al navegador.

En algunas realizaciones, al menos una parte de los datos representativos de la transaccion, transmitidos al servidor (40) del equipo proveedor (4), son introducidos por el usuario en los medios de entrada del terminal (3), a traves de las informaciones visualizadas por el navegador (N) en los medios de representacion visual del terminal (3). Estas realizaciones no garantizan necesariamente la confidencialidad ya que varios tipos de ataques permitiran violar la confidencialidad, o incluso permiten alterar los datos de entrada. Sin embargo, incluso si los datos de entrada en el navegador son alterados, podra garantizarse mediante la presente invencion la seguridad de las transacciones si el usuario utiliza el lector (1) para introducir, verificar los datos relativos a la transaccion y para validar la transaccion ya que los datos de la transaccion habran sido encriptados para circular por el canal (CS) seguro sin que puedan ser alterados. La invencion podra prever visualizar a traves del navegador un mensaje informando al usuario de la necesidad de verificar y validar las informaciones sobre el lector. En algunas realizaciones que permiten una confidencialidad total de las informaciones y una total seguridad, los datos son introducidos por el usuario en el lector (1). En algunas realizaciones, al menos una parte de los datos representativos de la transaccion, transmitidos al servidor (40) del equipo proveedor (4), son introducidos por el usuario en los medios (11) de entrada del lector (1) de la tarjeta chip. Se comprende, por consiguiente, que en algunas alternativas de la invencion, la seguridad y la confidencialidad total de las transacciones esta garantizada por el hecho de que todos los datos circulan por el canal seguro entre el lector y el equipo proveedor.

En algunas realizaciones, la inicializacion de la transaccion que sigue a una transmision al servidor (40) del equipo proveedor (4) de al menos una parte de los datos representativos de la transaccion, por un servidor (5) de terceros que gestiona un sitio internet al que se ha conectado el usuario. De ese modo, la inicializacion se produce cuando el usuario intenta realizar una transaccion. La propia transaccion puede pasar entonces por el canal seguro (CS). En algunas realizaciones, al menos parte de los datos representativos de la transaccion se transmiten al servidor (40) del equipo proveedor (4) por un servidor (5) de terceros que gestiona un sitio internet en el que el usuario se ha conectado. De la presente descripcion se comprende que el usuario puede conectarse al servidor (5) de terceros desde su lector/terminal en el caso en que el lector este integrado en un terminal comunicante o conectarse al servidor (5) de terceros desde su terminal en el caso de que el lector este conectado a dicho terminal. La conexion del usuario se hace a traves del navegador (N) del terminal (3), para realizar una transaccion, seleccionado por los medios de entrada del terminal (3). De ese modo, la invencion permite tambien la compra de artfculos en lmea. El equipo proveedor (4) que recibe los datos relativos a una transaccion del servidor (5) de terceros al que esta conectado el navegador (N) puede conectarse con el lector para establecer el canal seguro y que ya no haya datos

5

10

15

20

25

30

35

40

45

50

55

60

sensibles accesible en la red.

La invencion se refiere tambien a un procedimiento de inicializacion de transaccion segura en lmea y a un procedimiento de transaccion segura en lmea cuya realizacion se muestra en la figura 2. Estos procedimientos son implantados por los sistemas segun la invencion. El procedimiento de transaccion contiene al menos una etapa de transmision (91) de datos cifrados, por dicha clave de sesion (Kses) entre el modulo de seguridad (41) y el lector (1), despues de un etapa de establecimiento (90) de al menos un canal (CS) de comunicacion seguro entre el modulo de seguridad (41) y el lector (1). Esta etapa de establecimiento (90) del canal (CS) seguro se ejecuta por medio de las siguientes etapas previas:

- generacion (52) de al menos una clave de sesion (Kses), por los medios (12) de procesamiento del lector (1), en cooperacion con la tarjeta (2), despues del encriptado de los datos utilizando esta clave de sesion (Kses),

- obtencion (53), por el lector (1), a partir del chip (20) de la tarjeta (2), de los datos (D_chip) representativos de las informaciones asociadas a la tarjeta (2),

- transmision (54), desde el lector (1) al modulo de seguridad (41), de los datos (D_chip) representativos de las informaciones asociadas a la tarjeta (2) y de los datos encriptados utilizando la clave de sesion (Kses),

- generacion (55), por el modulo de seguridad (41), de la clave de sesion (Kses) a partir de al menos una clave de encriptado (CF) del modulo de seguridad (41) y de los datos (D_chip) recibidos.

Despues de esta etapa de establecimiento (90) del canal (CS) de comunicacion seguro, la transaccion puede tener lugar en una secuencia determinada (en funcion del tipo de transaccion), de manera completamente segura, por medio de al menos una etapa de transmision (91) de datos cifrados entre el modulo de seguridad (41) y el lector (1). Se comprende, por consiguiente, que la presente invencion presenta la ventaja de proteger los datos transmitidos desde el inicio de la transaccion en lugar de solo proteger la validacion de la transaccion mediante una firma (criptografica) como en la tecnica anterior. En algunas realizaciones, la etapa de generacion (52) de al menos una clave de sesion (Kses), por los medios (12) de procesamiento del lector (1) esta precedida por una etapa de generacion (51), por el chip (20) de la tarjeta (2), de al menos un criptograma (AAC, ARQC) a partir de la clave de encriptado (CF) almacenada en el chip (20) y de transmision de este (estos) criptograma (criptogramas) al lector (1) que genera la clave de sesion (Kses) a partir de este (estos) criptograma (criptogramas) (AAC, ARQC).

En algunas realizaciones, el procedimiento contiene al menos una etapa de entrada (50) por el usuario de la tarjeta (2), de al menos un codigo de identificacion personal (PIN) del usuario, y de autenticacion de este codigo por el chip (20) de la tarjeta. Esta etapa de entrada/autenticacion (50) puede ser ejecutado en el establecimiento del canal seguro, para que el usuario se autentifique desde el principio y que los intercambios de datos necesarios en la transaccion se realicen a traves del canal que se haya establecido mediante la autenticacion del usuario de la tarjeta. Esta etapa permite, por consiguiente, al menos una etapa de firma (60) de los datos por el chip (20). Por ejemplo, cuando el lector requiere criptogramas del chip para el calculo de la clave de sesion, el chip efectua las firmas haciendo al menos un criptograma y el lector genera la clave de sesion, como se menciono anteriormente. En el caso de una autenticacion en el momento de establecer el canal seguro (CS), esta firma (60) para la inicializacion de la transaccion se distingue de las firmas utilizadas habitualmente en este ambito, en particular en la CAP, ya que estas firmas clasicas se realizan al final de la transaccion para validar esta ultima (mediante el envfo de un criptograma) mientras que la firma de inicializacion de estas realizaciones se realiza para el establecimiento del canal, antes de cualquier intercambio de datos, lo que asegura favorablemente la transaccion. Sin embargo, la presente invencion permite tambien la ejecucion de otra etapa de firma al final de la transaccion. Por ejemplo, despues de que se haya establecido el canal y una vez que la mayor parte de las etapas necesarias para la transaccion hayan tenido lugar a traves del canal por el intercambio de datos en forma encriptada, es posible solicitar de nuevo la entrada del codigo PIN por parte del usuario al final de la transaccion, por ejemplo, a traves de la representacion visual de un resumen de las informaciones de la transaccion y de una invitacion a introducir el PIN para una firma del tipo utilizado habitualmente en la CAP. En general, el procedimiento puede tambien contener al menos una etapa de validacion por parte del usuario de las informaciones visualizadas y/o introducidas en el lector y que corresponden a los datos representativos de la transaccion.

En algunas realizaciones, el procedimiento contiene al menos una etapa de encapsulacion/desencapsulacion (58) de los datos representativos de la transaccion que circulan a traves del canal (CS) seguro.

En algunas realizaciones, la etapa de generacion (52) de al menos una clave de sesion (Kses), por los medios (12) de procesamiento del lector (1) esta precedida por un etapa de generacion (51), por el chip (20) de la tarjeta (2), de al menos un criptograma (AAC, ARQC) a partir de la clave de encriptado (CF) almacenada en el chip (20) y de transmision de este (estos) criptograma (criptogramas) al lector (1) generando la clave de sesion (Kses) a partir de este (estos) criptograma (criptogramas) (AAC, ARQC). Por ejemplo, el lector concatena dos criptogramas diferentes generados.

En algunas realizaciones, el procedimiento contiene al menos una etapa de recepcion y procesamiento, por los medios (12) de procesamiento del lector (1), de al menos una peticion de inicializacion del canal (CS) seguro enviado por el modulo de seguridad (41), que comprende un numero impredecible (UN) y provocando la consulta del chip (20) por el lector (1) para obtener al menos un criptograma (AAC, ARQC) y los datos (D_chip) representativos de las informaciones vinculadas a la tarjeta (2), esta etapa que permite la etapa de generacion (52) de la clave de sesion (Kses) que sirve para establecer el canal (CS) de comunicacion seguro y la transmision (54) al modulo de

5

10

15

20

25

30

35

40

45

50

55

60

seguridad (41), por una parte, de los datos (D_chip) representativos de las informaciones vinculadas a la tarjeta (2) y, por otra parte, dichos datos encriptados utilizando la clave de sesion (Kses), que contienen los datos relativos al numero impredecible (UN).

El procedimiento de transaccion segura segun la invencion contiene las etapas del procedimiento de inicializacion y al menos una etapa de transmision (91) de datos entre el modulo de seguridad (41) y el lector (1), en forma encriptada utilizando dicha clave de sesion (Kses), ejecutada en un sistema de transaccion segura segun la invencion.

En algunas realizaciones, el servidor (40) esta dispuesto para requerir del modulo de seguridad (41), en cada etapa de transmision (91) de datos con el lector (1), de un encriptado/desencriptado por dicha clave de sesion (Kses) de los datos transmitidos, estando el lector (1) dispuesto para encriptar/desencriptar tambien los datos intercambiados durante la transaccion.

De la lectura de la presente solicitud, se entendera que la etapa (90) de inicializacion del canal seguro, por el intercambio de los datos necesarios puede contener tambien las etapas de transmision de datos representativos del numero impredecible (UN), del identificador de aplicacion (AID), del numero de sesion (Nses), del numero de secuencia (Nseq), etc., mencionados previamente. Tambien se comprende que, una vez terminada la inicializacion (90) del canal, el procedimiento puede llevarse a cabo con al menos una iteracion de la etapa de transmision (91) de datos encriptados utilizando la clave de sesion. Cada iteracion de esta transmision (91) esta vinculada con al menos una etapa de encriptado/desencriptado (910) de los datos transmitidos. De ese modo, se comprende que la invencion se refiere, en primer lugar, a un procedimiento y a un sistema de inicializacion de transaccion en los que el establecimiento (90), o inicializacion, del canal seguro (CS) se lleva a cabo por la ejecucion de las etapas descritas anteriormente para permitir que las dos entidades utilicen la misma clave de sesion y que la invencion se ocupe tambien de un procedimiento y un sistema de transaccion seguro en los que las transmisiones (91) de los datos representativos de la transaccion esten vinculados con al menos una etapa de encriptado/desencriptado (910) de los datos transmitidos por dicha clave de sesion (Kses). Es por el hecho de que los datos esten encriptados por lo que se entiende que circulan por un canal seguro.

En general, se comprende que la invencion permite la ejecucion de etapas relativas a tales transacciones como, por ejemplo, las transferencias bancarias en lmea, los pagos en lmea (por ejemplo, de tipo 3D-seguro), las modificaciones del codigo PIN en lmea (haciendose el envm del nuevo codigo de entrada en forma encriptada por la clave de sesion a traves del canal seguro). Cabe senalar que la presente invencion permite, por supuesto, la transmision de otro tipo de datos que los que se refieren al codigo PIN ya que el termino "transaccion" se refiere aqrn abarcando cualquier tipo de transmision de datos. En el caso de un cambio de codigo PIN de una tarjeta segura, el nuevo codigo PIN transmitido de forma cifrada a traves del canal seguro es descifrado por el modulo (41) de seguridad y puede ser almacenado por el equipo (4) proveedor. En el ambito bancario, los cambios de codigo PIN requieren el uso de una peticion espedfica de la tarjeta, conocida con el nombre de "secure messaging (mensajena segura)". La invencion puede integrar esta funcionalidad utilizando el envm, por el equipo (4) proveedor que haya recibido el nuevo codigo PIN elegido por el usuario (entrada en el lector), de tal peticion que contenga el nuevo codigo PIN y que permita el cambio del codigo PIN por la tarjeta.

Los diversos tipos de transacciones posibles mediante la ejecucion del procedimiento podran llevarse a cabo segun varias secuencias, al alcance del especialista. Las figuras 3 y 4 muestran la secuencia de una operacion de transferencia, en el ejemplo descrito anteriormente de un equipo (4) proveedor que comprende un primer servidor, denominado frontal, al cual accede el navegador (N) del terminal (3) al que esta conectado un lector (1) que accede al chip (20) de la tarjeta (2) y un servidor (40) de operaciones que gestionan todas las operaciones y que preguntan al modulo de seguridad (41) para los encriptados/desencriptados. La figura 3 muestra la secuencia hasta el establecimiento (90) del canal seguro (CS), en un ejemplo de realizacion adaptado a una operacion de transferencia. La figura 4 muestra la continuacion de la realizacion del procedimiento de la figura 3, a partir del establecimiento (90) del canal seguro (CS). La figura 3 muestra, por consiguiente, una realizacion del procedimiento de inicializacion de transaccion y la figura 4 muestra, por consiguiente, una realizacion del procedimiento de transaccion. En este ejemplo de las figuras 3 y 4, se considera que la sesion de "banca electronica" ya esta en marcha: el usuario ya ha sido autentificado por un procedimiento establecido por el banco y desea realizar una operacion del tipo transferencia bancaria durante su sesion. Su lector esta conectado, y su tarjeta insertada. En este ejemplo, el procedimiento para ejecutar dicha operacion de transferencia se desarrollara de la forma siguiente:

- Envm (61) por el equipo (4) proveedor (el servidor frontal web, por ejemplo) de una invitacion a una entrada de los campos de la operacion hacia el terminal (3);

- Entrada (62) de los datos de la operacion por el usuario en el terminal (3);

- Envm (63) de los datos de la operacion y peticion de confirmacion del terminal (3) hacia el servidor Frontal Web;

Cabe senalar que la entrada puede hacerse de hecho en el lector (1) en lugar de en el terminal. En este caso, las etapas anteriores seran complementar por las etapas de transmisiones, por medio del modulo de puerta de enlace (ME), los datos entre el terminal y el lector. Cabe senalar tambien que se han omitido aqrn todas las etapas realizados por el modulo de puerta de enlace y que solo se menciona el terminal (3) para mayor claridad y simplicidad. El procedimiento continua con:

- Envm (64) de los datos de la operacion del Frontal Web al servidor (40) de la operacion;

5

10

15

20

25

30

35

40

45

50

55

60

- Orden (65) de inicializacion del canal seguro, por el servidor de operacion hacia el terminal (3);

- Prueba (66) de la presencia del lector por el terminal (3);

- Prueba (67) de la presencia de la tarjeta por el lector (l);

- Orden (68) de inicializacion (90) del canal seguro por el terminal (3) hacia el lector (1);

- Intercambio (intercambios) (69) entre el lector y la tarjeta (por las peticiones descritas anteriormente, en

particular aqm para una solicitud de introduccion del codigo PIN);

- Entrada (70) del codigo PIN por parte del usuario, despues de una invitacion en la representacion visual del lector (1);

- Intercambio (intercambios) (71) entre el lector y la tarjeta (por las peticiones descritas anteriormente, en particular para la verificacion del codigo PIN de la tarjeta);

- Generacion (52) de la clave de sesion (Kses) por el lector (1) para el establecimiento (90) el canal seguro (CS), por ejemplo, con Generacion (51) del criptograma (criptogramas) por la tarjeta (2), Generacion de un numero de sesion N(ses), y despues Encriptado (910) del numero de sesion N(ses);

- Obtencion (53) de los datos (D_chip) de la tarjeta (2) por el lector (1);

- Transmision (54) de los datos (D_chip) representativos de las informaciones vinculadas a la tarjeta (2), del lector (1) al modulo de seguridad (41), aqm principalmente por medio de:

o Envfo (72) de los datos (D_chip) de la tarjeta y el numero de sesion (Nses) cifrado por la clave de sesion (Kses) por el lector (1) hacia el terminal (3);

o Envfo (73) de los datos (D_chip) de la tarjeta y, en su caso, el numero de sesion (Nses) cifrado por la clave de sesion (Kses), por el terminal (3) hacia el servidor (40) de operaciones;

- Orden (74) de creacion de la clave de sesion (Kses) a partir de los datos (D_chip) de la tarjeta, por el servidor de operacion hacia el modulo de seguridad (41);

- Generacion (55), por el modulo de seguridad (41), de la clave de sesion (Kses) a partir de una clave de encriptado (CM) del modulo de seguridad (41) y de los datos (D_chip) recibidos,

- Envfo (75) de la clave de sesion (Kses) cifrada por la clave maestra (KM) por el modulo de seguridad (41) hacia el servidor de operacion (para el almacenamiento y la reutilizacion en las etapas siguientes de la transaccion, en su caso con el numero de sesion y el numero de secuencia).

El Canal (CS) seguro se activa entonces (establecimiento (90) mediante las generaciones (52 y 55) de ambas

partes. El procedimiento de inicializacion se ha completado en esta realizacion y el procedimiento de transaccion

puede entonces continuar (figura 4) por:

- Orden (76) de cifrado (910) de los datos de la operacion para su representacion visual en la pantalla del lector, por el servidor de operacion hacia el modulo de seguridad (41),

- Transmision (91) de los datos de la transaccion encriptados utilizando la clave de sesion (Kses) aqm principalmente por medio de:

o Envfo (77) de la cadena cifrada de caracteres por la clave de sesion por el modulo de seguridad (41) hacia el servidor de operacion;

o Orden (78) de solicitud de confirmacion de las informaciones cifradas por la clave de sesion por el servidor de operacion hacia el terminal (3);

o Orden (79) de solicitud de confirmacion de las informaciones cifradas por la clave de sesion, por el terminal (3) hacia el lector (1);

- Representacion visual (80) en el lector (1) de las informaciones cifradas y Validacion/Anulacion (81) por el usuario en funcion de las informaciones visualizadas.

Cabe senalar que el procedimiento puede contener varias iteraciones sucesivas de las diversas etapas, incluidas las transmisiones (91) que pueden contener diversas peticiones tales como las descritas anteriormente, especialmente con respecto a la orden (79), la representacion visual (80) y la validacion/anulacion (81): por ejemplo, una iteracion para solicitar la validacion/anulacion de la cuenta a ser cargada, una iteracion para solicitar la validacion/anulacion de la cuenta que se le atribuye, etc. Segun diversas alternativas, se podra de hecho tener una sola orden (79) enviada para varios requerir varias representaciones visuales (80) y validaciones (81) y etapas o varias ordenes para varias etapas de validacion/anulacion). Cabe senalar tambien que la encapsulacion/desencapsulacion (58) no se menciona aqm para simplificar la descripcion de la secuencia de las etapas.

El procedimiento de transaccion continua entonces con una transmision (91) en el otro sentido, aqm, en particular aqm gracias a:

- Envfo (82) de las informaciones validadas, firmadas por la tarjeta y despues cifradas por el lector (1) con la clave de sesion, hacia el terminal (3);

- Envfo (83) de las informaciones validadas, firmadas por la tarjeta y despues cifradas por el lector (1) con la clave de sesion, por el terminal (3) hacia el servidor de operacion;

- Orden (84) de descifrado de las informaciones validadas, firmadas por la tarjeta y despues cifradas con la clave de sesion por el servidor de operacion hacia el modulo de seguridad (41);

Para ayudar a conservar un registro de las operaciones, el procedimiento puede continuar con una etapa de envfo (85) de las informaciones validadas y de la firma en abierto para el archivo, del modulo de seguridad (41) hacia el servidor (40) de operacion. El servidor (40) de operacion puede entonces realizar una Operacion de reconocimiento, por ejemplo, con el envfo (86), al menos al terminal (3), de una confirmacion de operacion (confirmacion de la

5

10

15

20

25

30

35

40

45

50

55

60

transaccion realizada).

Al leer este ejemplo ilustrativo anterior y los medios espedficos descritos en la presente solicitud, el especialista comprendera las etapas, especialmente entre las descritas anteriormente, que se pueden ejecutar mediante diversas operaciones como, por ejemplo, transacciones bancarias (pago en lmea) o los envfos seguros de datos (por ejemplo, representativos de informaciones sobre la salud del usuario, etc.)

El modulo de seguridad (41) esta dispuesto al menos para permitir una iniciacion de transaccion por medio de al menos una funcion de inicializacion del canal seguro, por ejemplo ejecutada a continuacion de una orden de creacion del canal (CS) seguro que proviene del servidor (40) de operaciones. Por ejemplo, esta funcion puede tener, como parametros de entrada, datos representativos de informaciones vinculadas a la tarjeta (D_chip) para la constitucion de la clave de sesion y, como valores de retorno, la clave de sesion (Kses) cifrada por la clave maestra (KM) del modulo de seguridad (41): [Kses]KM. Cabe senalar que, segun diversas realizaciones, los valores devueltos pueden tambien contener el numero impredecible (UN) y/o el identificador de aplicacion (AID) mencionado anteriormente o que el servidor de operaciones pueda generar esta funcion de inicializacion del canal seguro transmitiendola al lector despues de haber anadido allf el numero impredecible (UN) y/o el identificador de aplicacion (AID).

En algunas realizaciones, el modulo de seguridad (41) esta dispuesto tambien para permitir una transaccion segura por medio de al menos una funcion de cifrado/descifrado (encriptado/desencriptado) por ejemplo ejecutada despues de:

- Una orden de encriptado (cifrado), por ejemplo enviada al modulo de seguridad por el servidor (40) de operaciones. Por ejemplo, esta funcion puede tener en parametros [Kses]KM la clave de sesion cifrada por la clave maestra del modulo de seguridad, asf como los datos a cifrar y, en los valores devueltos, los datos cifrados por la clave de sesion (Kses).

- Una orden de desencriptado (descifrado), por ejemplo enviada al modulo de seguridad por el servidor (40) de operaciones. Por ejemplo, esta funcion puede tener, en parametros, la clave de sesion cifrada por la clave maestra del modulo de seguridad ([Kses]KM) asf como los datos a descifrar y, en valores devueltos, los datos en abierto (descifrados).

Ademas, dependiendo de las aplicaciones y la arquitectura (del equipo) del proveedor de servicio, la invencion puede tambien incluir otros datos y funciones conocidas por el especialista (clave de transporte, transcifrado...) y que son espedficas de cada proveedor de servicio.

La presente invencion implica "medios de procesamiento de datos" en varios dispositivos (servidor, terminal, lector, tarjeta, etc.). El especialista comprendera al leer la presente solicitud que dichos medios de procesamiento de datos se refieren, para la tarjeta segura, el chip que contiene al menos un microprocesador que permite el procesamiento de los datos. Ademas, el chip permite almacenar diversos tipos de datos, tales como los representativos de informaciones vinculadas a la tarjeta, pero tambien los datos que permiten la ejecucion de la aplicacion (aplicaciones) espedfica (espedficas) (para la firma de las transacciones en particular). Por otra parte, el especialista comprendera que, para los servidores, los terminales y el lector, tales medios pueden contener tambien al menos un microprocesador, por ejemplo montado sobre una placa madre. En general, los medios de procesamiento de datos pueden contener al menos un circuito electronico y/o al menos un procesador. Dependiendo de los recursos informaticos necesarios, son posibles varias alternativas al alcance del especialista. Del mismo modo, las diversas tareas y funciones descritas aqrn pueden de hecho ser realizadas por varios dispositivos diferentes que cooperan para formar la entidad que se esta describiendo (servidor, terminal, etc.). De hecho, es posible, por ejemplo, que varios servidores cooperen para llevar a cabo las tareas necesarias dentro del sistema al que pertenecen, como se explica, por ejemplo, para los servidores del equipo (4) proveedor, y la invencion no debe ser limitada a la presencia de un unico servidor, por ejemplo. Del mismo modo, el termino servidor es particularmente claro para las aplicaciones descritas aqrn, pero se entendera que la invencion se puede ejecutar tambien sustituyendo el equipo proveedor (servidores) por al menos un terminal de un usuario (que contendra entonces los medios espedficos descritos para el equipo proveedor, despues de haber configurado con anterioridad la tarjeta y ese terminal para permitir la ejecucion de la invencion. Ademas, la invencion ejecuta, en diversas realizaciones, las aplicaciones de software y la manera en la que estas aplicaciones se ejecutan debe entenderse que no se limitan a su ejecucion en un solo dispositivo, ya que los medios de procesamiento pueden ser distribuidos a traves de multiples dispositivos. De este modo, las aplicaciones descritas aqrn pueden tambien provenir de fuentes dispares (especialmente en el caso del codigo descargable) y es una interpretacion funcional que debera aplicarse, ya que lo que importa es la ejecucion de las funciones descritas aqrn.

En particular, la invencion ejecuta medios espedficos, principalmente en el terminal usuario (modulo de puerta de enlace para el navegador), en el equipo proveedor (al menos el modulo de seguridad y un servidor para los intercambios), en el lector (aplicacion espedfica). La invencion puede, por consiguiente, involucrar tambien a cada uno de esos elementos por separado, con sus medios espedficos descritos aqrn.

Debe ser evidente para los expertos en la tecnica que la presente invencion permite realizaciones con otras numerosas formas espedficas sin apartarse del ambito de aplicacion de la invencion reivindicada. En consecuencia, las presentes realizaciones se deben considerar ilustrativas, pero pueden ser modificadas en el ambito definido por

el alcance de las reivindicaciones adjuntas, y la invencion no debe ser limitada a los detalles dados anteriormente.

Claims (17)

1. 5

   10

   15

   20

   25

   30

   35

   40

   45

   50

   55

   REIVINDICACIONES

   1. Lector (1) de tarjeta chip para transacciones seguras en lmea, a traves de al menos una red (RC) de comunicacion, por el intercambio de datos representativos de transacciones con al menos un equipo (4) de un proveedor de servicios que comprende al menos un servidor (40) dispuesto para gestionar las transacciones en lmea y al menos un modulo de seguridad (41) que asegura estas transacciones en cooperacion con el lector (1), caracterizado por que comprende medios (12) de procesamiento que estan adaptados para:

   - intercambiar, antes de cualquier transaccion, los datos con al menos un chip (20) de al menos una tarjeta (2) segura, con el fin de obtener, del chip (20), y transmitir, al modulo de seguridad (41), los datos (D_chip), denominados publicos, representativos de al menos una informacion vinculada a la tarjeta (2),

   - gestionar, antes de cualquier transaccion, en cooperacion con dicho chip (20), al menos una clave de sesion (Kses), y transmitir al modulo de seguridad (41) los datos encriptadas utilizando esta clave de sesion (Kses), con el fin de que el modulo de seguridad (41) puede calcular dicha clave de sesion (Kses), a partir de dichos datos publicos (D_chip) recibidos y de al menos una clave de encriptado (CF),

   - intercambiar los datos representativos de la transaccion con el modulo de seguridad (41), en forma encriptada por dicha clave de sesion (Kses), formando de este modo un canal (CS) de comunicacion seguro para la transaccion.
2. 2. Lector (1) de tarjeta chip segun la reivindicacion 1, caracterizado por que los medios (12) de procesamiento del lector (1) estan adaptados para generar la clave de sesion (Kses) en cooperacion con el chip (20) de la tarjeta (2), requiriendo del chip (20) de la tarjeta (2) que genere, a partir de al menos una clave de encriptado (CF) almacenada en el chip (20), al menos un criptograma (AAC, ARQC) utilizado por el lector (1) para generar la clave de sesion (Kses) que sirve para el establecimiento del canal (CS) seguro.
3. 3. Sistema de transaccion segura en lmea, a traves de al menos una red (RC) de comunicacion, conteniendo el sistema al menos un equipo (4) de un proveedor de servicio que comprende al menos un servidor (40) dispuesto para gestionar transacciones en lmea, por el intercambio de datos representativos de las transacciones con al menos un lector (1) de tarjeta (2) chip, comprendiendo dicho equipo (4) tambien al menos un modulo de seguridad (41), dispuesto para proteger estas transacciones, caracterizado por que:

   - dicho sistema contiene al menos un lector (1) de tarjeta chip segun una de las reivindicaciones 1 y 2,

   - el modulo de seguridad (41) calcula dicho clave de sesion (Kses), a partir de dichos datos publicos (D_chip) recibidos y de al menos una clave de encriptado (CF),

   - el lector (1) y el modulo de seguridad (41) encriptan y desencriptan, por dicha clave de sesion (Kses), los datos representativos de la transaccion que se intercambian durante la transaccion, formando asf un canal (CS) de comunicacion seguro para la transaccion.
4. 4. Sistema segun la reivindicacion 3, caracterizado por que:

   - el modulo de seguridad (41) utiliza al menos una clave, denominada clave madre (CM) que se utiliza para la generacion de las claves (CF) de las tarjetas (2) seguras proporcionadas por el proveedor de servicio, denominadas claves hijas (CF), siendo cada una de las tarjetas (2) proporcionadas identificables a partir de al menos una informacion contenida en los datos (D_chip) publicos,

   - los medios (12) de procesamiento del lector (1) transmiten al modulo de seguridad (41) los datos (D_chip) publicos para que pueda encontrar la clave de encriptado (CF) a utilizar para calcular la clave de sesion (Kses).
5. 5. Sistema segun una de las reivindicaciones 3 y 4, caracterizado por que el equipo (4) del proveedor de servicio contiene al menos una base de datos que almacena las claves de encriptado (CF) de las tarjetas (2) seguras proporcionadas por el proveedor de servicio, accediendo el modulo de seguridad (41) a esta base de datos para encontrar, en funcion de los datos (D_chip) publicos recibidos del lector (1) de tarjeta chip, la clave de encriptado (CF) a utilizar para calcular la clave de sesion (Kses).
6. 6. Sistema segun una de las reivindicaciones 3 a 5, caracterizado por que el lector (1) y el equipo proveedor (4) estan vinculados a traves de una comunicacion segura segun un protocolo de tipo SSL/TLS dentro del cual se establece el canal (CS) seguro.
7. 7. Sistema segun una de las reivindicaciones 3 a 6, caracterizado por que los medios (12) de procesamiento del lector (1) estan dispuestos para recibir el modulo de seguridad (41) y tratar al menos una peticion de inicializacion del canal (CS) seguro que comprende un numero impredecible (UN) y que provoca la consulta del chip (20) por el lector (1), para obtener al menos un criptograma (AAC, ARQC) y los datos (D_chip) representativos de las informaciones vinculadas a la tarjeta (2), lo que permite a los medios (12) de procesamiento del lector (1) generar la clave de sesion (Kses) que sirve para establecer el canal (CS) de comunicacion seguro y de transmitir al modulo de seguridad (41), por una parte, los datos (D_chip) representativos de las informaciones vinculadas a la tarjeta (2) y, por otra parte, dichos datos encriptados utilizando esta clave de sesion (Kses), que contiene los datos relativos al numero impredecible (UN).
8. 8. Sistema segun una de las reivindicaciones 3 a 6, caracterizado por que la inicializacion de la transaccion hecha a continuacion de una transmision al servidor (40) del equipo proveedor (4) de al menos una parte de los datos representativos de la transaccion, por un servidor (5) de terceros que gestiona un sitio de Internet al que se ha conectado el usuario.

   5

   10

   15

   20

   25

   30

   35

   40

   45

   50
9. 9. Sistema segun una de las reivindicaciones 3 a 8, caracterizado por que el servidor de (40) del equipo proveedor (4) esta dispuesto para gestionar el establecimiento y la utilizacion del canal (CS) seguro procesando y conservando un numero impredecible (UN), la clave de sesion (Kses), un numero de sesion (Nses) generado en el establecimiento del canal seguro (CS) y que esta vinculado al numero impredecible (UN) y un contador de transaccion de la tarjeta (2), asf como un numero de secuencia (Nseq) incrementado en cada peticion enviada al lector (1), durante cada sesion.
10. 10. Sistema segun una de las reivindicaciones 3 a 8, caracterizado por que el modulo de seguridad (41) del equipo proveedor (4) esta dispuesto para almacenar la clave de sesion (Kses) en medios de memorizacion y/o para encriptar la clave de sesion (Kses) utilizando una clave, denominada clave maestra (KM), y transmitirla al servidor (40) para el almacenamiento en forma encriptada en los medios de memorizacion.
11. 11. Sistema segun una de las reivindicaciones 3 a 10, caracterizado por que el servidor (40) esta dispuesto para requerir del modulo de seguridad (41), en cada transmision de datos con el lector (1), un encriptado/desencriptado por dicha clave sesion (Kses) de los datos transmitidos, estando el lector (1) dispuesto para encriptar/desencriptar tambien los datos intercambiados durante la transaccion.
12. 12. Procedimiento de inicializacion de transaccion segura en lmea, a traves de al menos una red (RC) de comunicacion, ejecutada utilizando al menos un lector segun una de las reivindicaciones 1 y 2, caracterizado por que contiene al menos una etapa de establecimiento (90) de al menos un canal (CS) de comunicacion segura entre el modulo de seguridad (41) y el lector (1) que se ejecuta mediante los siguientes etapas:

    - generacion (52) de al menos una clave de sesion (Kses), por los medios (12) de procesamiento del lector (1), en cooperacion con la tarjeta (2), y despues el encriptado de los datos utilizando esta clave de sesion (Kses)

    - obtencion (53), por el lector (1), a partir del chip (20) de la tarjeta (2), de los datos (D_chip) representativos de las informaciones vinculadas a la tarjeta (2),

    - transmision (54), del lector (1) al modulo de seguridad (41), de los datos (D_chip) representativos de las informaciones vinculadas a la tarjeta (2) y de los datos encriptados utilizando la clave de sesion (Kses).

    - generacion (55), por el modulo de seguridad (41), de la clave de sesion (Kses) a partir de al menos una clave de encriptado (CF) del modulo de seguridad (41) y de los datos (D-chip) recibidos.
13. 13. Procedimiento segun la reivindicacion 12, caracterizado por que la etapa de generacion (52) de al menos una clave de sesion (Kses), por los medios (12) de procesamiento del lector (1) esta precedida por una etapa de generacion (51), por el chip (20) de la tarjeta (2), de al menos un criptograma (AAC, ARQC) a partir de la clave de encriptado (CF) almacenada en el chip (20) y de la transmision de este (estos) criptograma (criptogramas) al lector (1) que genera la clave de sesion (Kses) a partir de este (estos) criptograma (criptogramas) (AAC, ARQC).
14. 14. Procedimiento segun una de las reivindicaciones 12 y 13, caracterizado por que contiene al menos una etapa de entrada (50), por el usuario de la tarjeta (2), de al menos un codigo de identificacion personal (PIN) del usuario, y la autenticacion de ese codigo por el chip (20) de la tarjeta, permitiendo esta etapa de entrada/autenticacion (50) al menos una etapa de firma (60) de los datos por el chip (20).
15. 15. Procedimiento segun una de las reivindicaciones 12 a 14, caracterizado por que contiene al menos una etapa de recepcion y procesamiento, por los medios (12) de procesamiento del lector (1), de al menos una peticion de inicializacion del canal (CS) seguro enviado por el modulo de seguridad (41) que comprende un numero impredecible (UN) y que provoca la consulta del chip (20) por el lector (1), para obtener al menos un criptograma (aAc, ARQC) y los datos (D_chip) representativos de las informaciones vinculadas a la tarjeta (2), permitiendo esta etapa la etapa de generacion (52) de la clave de sesion (Kses) que sirve para establecer el canal (CS) seguro de comunicacion y la transmision (54) al modulo de seguridad (41), por una parte, los datos (D_chip) representativos de las informaciones vinculadas a la tarjeta (2) y, por otra parte, dichos datos encriptados utilizando esta clave de sesion (Kses), que contiene los datos relativos al numero impredecible (UN).
16. 16. Procedimiento de transaccion segura en lmea, caracterizado por que contiene las etapas del procedimiento de inicializacion segun una de las reivindicaciones 12 a 15 y al menos una etapa de transmision (91) de los datos entre el modulo de seguridad (41) y el lector (1), en forma encriptada utilizando dicha clave de sesion (Kses).
17. 17. Procedimiento segun la reivindicacion 16, caracterizado por que el servidor (40) esta dispuesto para requerir del modulo de seguridad (41), en cada etapa de transmision (91) de los datos con el lector (1), un encriptado/desencriptado por dicha clave de sesion (Kses) de los datos transmitidos, estando el lector (1) dispuesto para encriptar/desencriptar tambien los datos intercambiados durante la transaccion.