MXPA06006588A

MXPA06006588A - Sistema y metodo de transferencia segura de informacion.

Info

Publication number: MXPA06006588A
Application number: MXPA06006588A
Authority: MX
Inventors: Robert Ziegler
Original assignee: Solidus Networks Inc D B A Pay
Priority date: 2003-12-11
Filing date: 2004-12-11
Publication date: 2007-08-02
Also published as: US7387240B2; US20050194438A1; CA2549379A1; AU2004305043A1; JP2007514377A; EP1697854A2; BRPI0417547A; WO2005060630A2; CN1954308A; WO2005060630A3

Abstract

La informacion puede ser transferida de una forma segura desde un primer dispositivo (102) hacia un segundo dispositivo (110) sobre una red abierta (108) mediante la transferencia de software al primer dispositivo (102) y la ejecucion del software; los datos representan la informacion que es ingresada al primer dispositivo (102) y transferida al segundo dispositivo (110), el segundo dispositivo (110) utiliza los datos para determinar la informacion.

Description

SISTEMA Y MÉTODO DE TRANSFERENCIA SEGURA DE INFORMACIÓN CAMPO DE IA INVENCIÓN La invención se refiere al campo de transferencia segura de información, en particular a transferencia segura de información para transacciones de red abierta.

ANTECEDENTES DE IA INVENCIÓN La necesidad respecto a comunicación segura es antigua y ha crecido hasta una importancia primordial. Cualquier sistema que implemente una transferencia electrónica de fondos, por ejemplo, requiere medidas de seguridad de nivel múltiple. Los actos simples de asignar y utilizar un Número de Identificación Personal (NIP) para accesar a la red de débito de ATM requieren el uso de protocolos y/o hardware altamente controlados . Cualquier transacción es susceptible de fraude y engaños. Incluso un encuentro cara a cara entre un cliente y un banquero podría ser sujeto de fraudes de suplantación o falsa identidad. Las transacciones entre extraños y de manera más particular, las transacciones realizadas en una red abierta como la Internet no pueden realizarse dentro de limitaciones de riesgo razonable sin algún tipo de verificación de identidad. El uso de un NIP provee un cierto nivel de verificación, ya que se supone que la única persona que conoce el NIP debe ser el tarjetahabiente autorizado. Desde luego, cualquier comunicación del NIP está sujeta a ataques de escucha ilegal, intercepción o intermediarios. Cuando se efectúa la conexión a la red de ATM, el NIP podría no transmitirse, incluso en forma encriptada, a través de redes abiertas. Sin embargo, no se tiene que transmitir la información para que se comunique. Por ejemplo, se pueden utilizar técnicas de conocimiento cero para comunicar la información sin transmitir la información. Los protocolos de conocimiento cero aprovechan el hecho que se puede demostrar la posesión de datos sin revelar los datos. Otro método para comunicar información sin transmitir la información se puede observar en un procedimiento de remitente de NIP. El procedimiento de remitente de NIP permite que un tarjetahabiente seleccione un NIP utilizando una forma y el envío por correo del documento. El procedimiento de remitente de NIP se ajusta a las normas ANSÍ actuales y es aceptado en la Industria bancaria. El emisor de la tarjeta asocia una forma con una tarjeta que ha sido expedida a un tarjetahabiente. La asociación típicamente es para una forma específica utilizando un número de serie y puede ser una asociación para un tipo de forma utilizando un ID de la forma. El emisor de la tarjeta envía la forma asociada al tarjetahabiente. Se le pide al tarjetahabiente que seleccione un NIP para una cuenta determinada llenando una forma en papel y suministrándola al emisor de la tarjeta o al productor del emisor a través del correo normal. La forma en papel que completa el tarjetahabiente está diseñada específicamente para dicho propósito. En primer lugar, ésta típicamente es una forma con copia al carbón de capas múltiples. La forma incluye una página superior para inscribir el N1P en una manera que sea claramente entendible al usuario. La página superior permite la inscripción no segura de la información. De conformidad con el protocolo la página superior es destruida por el tarjetahabiente tan pronto como se inscribe el NIP, de modo tal que no exista una copia insegura de la información. La página, o páginas, inferiores están diseñadas específicamente para proteger los datos que han sido inscritos. Se pueden generar porciones de la página a través de procedimientos criptográficos para ocultar adicionalmente los datos. El tarjetahabiente llena la forma seleccionando su NIP en la página superior encerrando en círculos uno o más valores o llenando burbujas que representan su NIP deseado. La información de posición se transfiere a través de la página inferior. La información de posición no incluye, en ninguna forma, los números que constituyen el NIP. La información codificada representa la posición del NIP en la ahora destruida hoja superior. Una vez que el tarjetahabiente destruye la página superior de la forma, no existe una versión en texto claro o encriptado del NIP. Esta página inferior que contiene la información de posición se envía después a través de correo normal hacia el emisor de la tarjeta. La página es segura contra un ataque de intercepción debido a que la forma no tiene información que identifique al tarjetahabiente y no tiene información que ayude a identificar los números asociados con los datos de posición. El emisor de la tarjeta puede recuperar el valor que representa al NIP a partir de la página "inferior" que se devuelve y la información relacionada con la forma de petición, tal como un número de forma o número de serie. Por lo tanto, lo que se necesita es un sistema y método para transferir información a través de una red abierta en modo seguro.

SUMARIO DE LA INVENCIÓN La información se puede transferir en forma segura desde un primer dispositivo hacia un segundo dispositivo a través de una red abierta transfiriendo software hacia el primer dispositivo y ejecutando el software. Los datos que representan la información se introducen en el primer dispositivo y se transfieren hacia el segundo dispositivo. El segundo dispositivo utiliza los datos para determinar la información.

BREVE DESCRIPCIÓN DE LAS FIGURAS Para un entendimiento más completo de la presente invención y de las ventajas de la misma, a continuación se hace referencia a la siguiente descripción tomada en conjunto con las figuras anexas en las cuales: La figura 1 es un diagrama de un sistema para la transferencia segura de información. La figura 2 es un diagrama arquitectónico del procedimiento de adquisición; y La figura 3 es un diagrama de la arquitectura del procedimiento de autorización.

DESCRIPCIÓN DETALLADA DE LA INVENCIÓN Con referencia ahora a las figuras, en las cuales se utilizan números de referencia similares para designar elementos similares a través de todas las diversas vistas, se describen de manera adicional varias modalidades de la presente invención. Las figuras no están necesariamente dibujadas a escala, y en algunos casos los dibujos se han exagerado o simplificado únicamente con propósitos ilustrativos. Un experto en la técnica apreciará que muchas aplicaciones y variaciones posibles de la presente invención están basadas en los siguientes ejemplos de posibles modalidades de la presente invención. Con referencia la figura 1, se muestra un sistema 100 para la transferencia segura de información. Se puede utilizar una computadora 102 que incluya una pantalla pixelada 104 y un dispositivo apuntador 106 tal como un ratón para enviar información, tal como un NIP, a una autoridad. La computadora 102 está conectada en forma comunicable al servidor de la autoridad 110 mediante la red 108. El servidor 110 puede estar conectado a un dispositivo de almacenamiento 112 y a un procesador seguro 114. Típicamente, un procedimiento de inicialización autentifica la computadora 102 al servidor 110. Una versión seleccionada y tal vez personalizada del software para introducción del NIP está asociada con la computadora 102 y se carga en la computadora 102 desde el servidor 110. El software puede estar vinculado en forma criptográfica a un procedimiento de Autorización. El tarjeta abiente utiliza el software para introducir datos que representen el NIP, tal como datos de posición que indiquen la posición de un número de NIP en una pantalla pixelada. Los datos se pueden enviar desde la computadora 102 hacia el servidor 110 a través de un canal de comunicaciones fuertemente encriptado. Cuando los datos son recibidos por el servidor 110, los datos se procesan en el procesador seguro 116 utilizando datos de asociación almacenados en el dispositivo de almacenamiento 112. El procesador seguro provee el NIP para autentificación, verificación, identificación o cualquier otro propósito apropiado. Los expertos en la técnica reconocerán que se pueden comunicar otras formas de datos en la misma manera. La pantalla de la computadora puede presentar una representación gráfica de un teclado (pad) de NIP tradicional al tarjetahabiente. La representación gráfica de un teclado de NIP es una forma suministrada al tarjetahabiente que provee una interfaz familiar para incrementar la capacidad de uso y aceptación. Sin embargo, el presionar un botón del ratón a medida que el cursor está sobre una representación gráfica de un número provee a la computadora el punto de ubicación de la pantalla y no el número. Únicamente el servidor tiene la asociación que puede generar el número a partir del punto de ubicación de la pantalla. Un procedimiento de Adquisición obtiene en forma segura la información a partir de la cual se puede extraer el NIP del tarjetahabiente. Un procedimiento de autorización permite que un comerciante basado en Internet solicite que se autorice una transacción de débito y obtenga el pago. Con referencia a la figura 2, se muestra un diagrama de un sistema de transferencia de información. Una computadora 102 está conectada en forma comunicable a un servidor de Red 120. El servidor de Red 120 provee una interfaz con un servidor de aplicación 122. El servidor de aplicación 122 está conectado a un módulo criptográfico hospedero 124. Cada uno de estos componentes forman una zona criptográfica. Las zonas criptográficas pueden ser identificadas por los controles criptográficos colocados dentro de la zona y delinean el punto en el que cambian los controles criptográficos. La primera zona provee la seguridad para comunicación entre la computadora 102 y el servidor de red 120. SSL es la encriptación estándar utilizada para comunicación por Internet. Los datos enviados desde la computadora 102 hacia el servidor de aplicación pueden estar encriptados. Por ejemplo, la Norma de Encriptación Avanzada (AES por sus siglas en inglés) puede proveer encriptación de 256 bits de toda la información comunicada entre la computadora 102 y el servidor de aplicación 122. Los datos enviados desde la computadora 102 hacia el TRSM 124 para extracción de NIP pueden estar encriptados. Por ejemplo, la AES puede proveer encriptación de 256 entre la computadora 102 y el TRSM 124. Los datos de adquisición son adquiridos por el software del sistema instalado en la computadora 102. Los datos de adquisición se pueden encriptar utilizando una Clave AES(Datos) • La primera zona incluye la computadora 112 y básicamente está sin control: La PC 102 del cliente es un punto final para casi toda la seguridad criptográfica en el procedimiento de Adquisición y no puede ser controlada directamente por el sistema. Es conveniente establecer una presencia de confianza en este punto no controlado. Una manera para establecer una presencia de confianza es utilizar métodos criptográficos provistos como parte del software del sistema que se descarga en forma segura, conforme a SSL de 128 bits, al inicio de cada sesión. La confianza se incrementa adicionalmente mediante el uso de tecnología de verificación de integridad de mensaje estándar, federal, reconocida a nivel nacional: Norma de Elección Arbitraria Segura [Secure Hash Standard (SHS) ] FIPS 180-2, Algoritmo de Elección Arbitraria Segura [Secure Hash Algorithm (SHA)] SHA-512. La segunda zona incluye el servidor de red y es un área controlada a la que se puede acceder a través de la Internet. Esta provee una interfaz accesible para los clientes, pero no desempeña ninguna función significativa excepto la de transmitir información de regreso a la Zona de Procesamiento de Aplicación. El servidor de red establece la sesión segura inicial para permitir la descarga del software del sistema y la carga de la clave criptográfica Pública del cliente (RSA 1024-bits) al Dispositivo Criptográfico Hospedero en la Zona 4. El servidor de red está ubicado dentro de un área físicamente segura. La tercera zona incluye el procesamiento de aplicación: Esta zona efectúa la mayoría del trabajo significativo de la fase de Adquisición. El servidor de Aplicación 122 se establece a sí mismo como el punto final para el canal de comunicaciones encriptado AES (256 bits) para el cliente 102. El servidor de aplicación 122 puede estar ubicado dentro de un área físicamente segura. La cuarta zona incluye un área segura que aloja dos componentes, el Módulo Criptográfico Cospedero (HCM) y el Almacén de Datos de Adquisición. Ambos componentes están dentro de un área físicamente segura. El HCM es un dispositivo FIPS 140-2 de nivel 3 y es el "caballito de batalla" del procedimiento de encriptación en el procedimiento de Adquisición. Este genera y utiliza las claves de AES creadas (comunicaciones y datos) para soportar y proteger la información durante el procedimiento de Transmisión. Este también ejecuta los procedimientos de encriptación de RSA y TDES. Esta es un área de retención criptográficamente asegurada (TDES de 128 bits) para los datos de adquisición mientras se espera a que comience el procedimiento de Autorización. Con referencia a la figura 3, se muestra un diagrama de flujo 300 de un procedimiento comercial. En el bloque de función 302, un usuario accesa a un sitio mercantil que utiliza el sistema de pago del sistema de la presente invención y selecciona Débito como la forma de pago por los servicios y/o mercancía ofrecida por el comerciante. Se establece una sesión asegurada de SSL de 128 bits entre el servidor de Red y la PC del cliente en el bloque de función 304. Bajo esta ruta de comunicaciones asegurada se descarga y se instala el software del sistema en el cliente en el bloque de función 306. Se puede cargar un certificado digital para establecer sesiones de SSL en el servidor de Red. El Módulo Criptográfico Hospedero puede cargar manualmente claves TDES generadas en forma aleatoria [KPS] bajo control dual y conocimiento dividido para utilizarlas en la encriptación de los datos de Adquisición para almacenamiento . El procedimiento continúa con el Establecimiento de la Clave de Comunicaciones en el bloque de función 308. Se genera un par de Claves Pública/Privada de RSA (1024 bits) . La Clave Pública se envía a través de SSL hacia el servidor de Red y después como texto claro hacia el servidor de Aplicación y finalmente hacia el Módulo Criptográfico Hospedero. El Módulo Criptográfico Hospedero genera una clave AES de 256 bits, AES¡Com) que será utilizada para proteger las comunicaciones entre el cliente y el Servidor de Aplicaciones. El Módulo Criptográfico Hospedero también genera una clave AES de 256 bits (AES (Datos) ) /• ésta se utiliza para encriptar los Datos de Adquisición entre el Cliente y el Módulo Criptográfico Hospedero. El Módulo criptográfico Hospedero cambia la clave AES(com), después genera una elección arbitraria criptográfica (SHA-512) de la clave AES(CO) cambiada, y después envuelve la clave AES(Com) cambiada, junto con la elección arbitraria criptográfica con la Clave Pública de RSA del Cliente. Este criptograma se presenta después al Servidor de Aplicación. El Módulo Criptográfico Hospedero cambia la clave AES (Datos)' después genera una elección arbitraria criptográfica (SHA-512) de la clave ?ES(Datos) cambiada, y después envuelve la clave AES(Dato?) cambiada, junto con la elección arbitraria criptográfica con la Clave Pública de RSA del Cliente. Este criptograma también se encripta con la clave AES(Com¡- Este criptograma se presenta después al Servidor de Aplicación. El Módulo Criptográfico Hospedero combina los dos elementos, cambia la combinación, después genera una elección arbitraria criptográfica (SHA-512) para la combinación cambiada, después encripta la combinación cambiada, junto con la elección arbitraria criptográfica de la combinación cambiada con la Clave Pública del Cliente. Este criptograma se presenta después al Servidor de Aplicación, y finalmente se transmite de regreso al Cliente envuelto también dentro de la SSL. El Cliente desencripta el paquete de claves con su clave Privada y después genera una elección arbitraria criptográfica (SHA-512) del resultado, comparando la elección arbitraria criptográfica calculada con aquella provista en el mensaje de intercambio de clave. El Cliente desencripta el criptograma recibido, primero con la AES(COItl) y después con la clave Privada del Cliente haciendo que la clave AES (Datos) quede disponible para comunicaciones entre el cliente y el Módulo Criptográfico Hospedero. El Cliente después desencripta el criptograma que contiene la clave AES (com) utilizando su clave Privada, genera una elección arbitraria criptográfica (SHA-512) de la clave resultante, comparando la elección arbitraria criptográfica calculada con aquella provista en el mensaje de intercambio de clave. El Cliente después desencripta el criptograma que contiene la clave AES(Datos) utilizando la clave AES(COm) desencripta también el resultado con su clave Privada, después genera la elección arbitraria criptográfica de la clave resultante, comparando la elección arbitraria criptográfica calculada con aquella provista en el mensaje de intercambio de claves. El Cliente ahora tiene tanto la clave AES(C?m), así como la clave AES(Datos) para comunicación adicional con el Servidor de Aplicación. Una vez que se establecen las rutas de comunicaciones, se pueden suministrar los datos de adquisición en el bloque de función 310. Los datos de adquisición se "cambian" primero después se encriptan conforme a la clave AES ¡Datos)- La información adicional que se va a transmitir con los datos de Adquisición se concatenan, y el resultado de nuevo se "cambia". El cliente efectúa una elección arbitraria criptográfica del criptograma resultante utilizando SHA-512. La elección arbitraria criptográfica resultante se concatena al bloque si los datos que se van a transmitir y el valor resultante se encriptan conforme a la clave AES(COm). El resultado de la encriptación se procesa después con CRC-64. CRC se anexa al criptograma. Este criptograma finalmente se envía bajo SSL al servidor de la Red. El servidor de la Red remueve la encriptación SSL y envía el mensaje al Servidor de Aplicación. Una vez recibido por el Servidor de Aplicación, se verifica la integridad del mensaje en el bloque de función 312. El Servidor de Aplicación analiza el mensaje y se efectúa CRC en la concatenación del criptograma y elección arbitraria. El CRC recién calculado se compara con el CRC enviado con el mensaje. Si estos coinciden, se confirma la integridad y continua el procedimiento. Si no, el procedimiento termina y se genera un error. El Servidor de Aplicación recurre al HCM para desencriptar el mensaje con la clave AES(Com)- El Servidor de Aplicación analiza de nuevo la concatenación y se efectúa un SHA-512 contra el criptograma. La elección arbitraria recién calculada se compara con la elección arbitraria enviada con el mensaje. Si éstas coinciden, se confirma la integridad y el procedimiento continua. Si no, el procedimiento termina y se genera un error. El criptograma se envía al Módulo Criptográfico Hospedero. Los Datos de Adquisición están almacenados en forma segura esperando el inicio del Procedimiento de Autorización. El Módulo Criptográfico Hospedero desencripta los Datos de Adquisición a partir de la clave AES(Datos) y los vuelve a encriptar con la clave TDES (Almacenamiento) [KPS] y envía el criptograma resultante al área de Almacenamiento de Adquisición. Las siguientes acciones o actividades se pueden lograr antes que se pueda autorizar la primera transacción. El TRSM de extracción de NIP carga manualmente las claves TDES generadas en forma aleatoria bajo control dual y conocimiento dividido para uso como claves de encriptación de NIP (PEK) [KPT o KPS] para proteger los bloques de NIP cuando se transmiten a la interfaz de EFT. El Módulo Criptográfico Hospedero carga manualmente las claves TDES generadas en forma aleatoria bajo control doble y conocimiento dividido para uso como las Claves Maestras [*KKS] para proteger todas las otras claves mientras están en almacenamiento. El Módulo Criptográfico Hospedero carga manualmente las claves TDES generadas en forma aleatoria bajo control dual y conocimiento dividido para uso como claves para encriptación de Clave (KEK) [KKT] para proteger el intercambio de clave utilizado para proteger los bloques de NIP (PEK) [KPT] cuando se transmiten hacia las redes de EFT. El procedimiento de autorización comienza cuando un comerciante accesa al Administrador de Transacción del sistema y solicita el pago por los servicios y/o mercancías ofrecidas por el comerciante. Una vez iniciado, el Servidor del Portal utiliza la información de transacción provista por el comerciante a través del Administrador de Transacción para identificar el criptograma de datos de adquisición apropiado en almacenamiento. El Servidor del Portal solicita el criptograma de datos de adquisición del almacenamiento y lo provee al TRSM de extracción de NIP. El TRSM de Extracción de NIP desencripta el criptograma de datos de adquisición utilizando la clave TDES (A?macenamiento) [KPS]. El TRSM de Extracción de NIP extrae el NIP del tarjetahabiente a partir de los Datos de Adquisición. El TRSM de Extracción de NIP crea el bloque de NIP requerido (formato 0 de ANSÍ) y encripta con la PEK(ATMD) [KPS] . El TRSM de Extracción de NIP provee el criptograma al Portal. El Portal envía el criptograma a la interfaz de EFT. La interfaz de EFT envía el criptograma al Módulo Criptográfico Hospedero. El Módulo Criptográfico Hospedero traduce el bloque de NIP desde la encriptación conforme a PEK(ATMD) [KPS] hasta encriptación conforme a PEK(EFT) [KPT] . El criptograma resultante se envía de regreso a la interfaz de EFT. La interfaz de EFT envía el criptograma a la Red de EFT. Los expertos en la técnica que tienen el beneficio de esta descripción apreciarán que esta invención provee un sistema para intercambio de NIP. Se debe entender que los dibujos y descripción detallada en la presente se deben considerar en un sentido ilustrativo en lugar de restrictivo, y que no pretenden limitar la invención a las formas y ejemplos particulares descritos. Por el contrario, la invención incluye cualesquiera modificaciones, cambios, reacomodos, sustituciones, alternativas, elecciones de diseño, y modalidades adicionales evidentes para los expertos en la técnica, sin alejarse del alcance y campo de esta invención, como quedan definidos por las siguientes reivindicaciones. Por lo tanto, se pretende que las siguientes reivindicaciones se interpreten de manera tal que abarquen a todas de dichas modificaciones, cambios, reacomodos, sustituciones, alternativas, elecciones de diseño, y modalidades adicionales.

Claims

NOVEDAD DE LA INVENCIÓN Habiendo descrito el presente invento, se considera como una novedad y, por lo tanto, se reclama como 5 prioridad lo contenido en las siguientes: REIVINDICACIONES

1.- Un método para transferir información desde 0 un primer dispositivo hacia un segundo dispositivo a través de una red abierta que comprende los pasos de: transferir software hacia dicho primer dispositivo; ejecutar dicho software en dicho primer 5 dispositivo; ingresar datos que representan dicha información; transferir dichos datos hacia dicho segundo dispositivo; y determinar dicha información a partir de dichos 0 datos en el segundo dispositivo.

2. - El método de conformidad con la reivindicación 1, caracterizado porque dicho primer dispositivo es una computadora.

3. - El método de conformidad con la ,5 reivindicación 1, caracterizado porque dicho primer dispositivo incluye una pantalla pixelada.

4. - El método de conformidad con la reivindicación 1, caracterizado porque dicho primer dispositivo incluye un dispositivo de entrada de interfaz gráfica.

5. - El método de conformidad con la reivindicación 4, caracterizado porque dicho dispositivo de entrada de interfaz gráfica es un ratón.

6.- El método de conformidad con la reivindicación 1, caracterizado porque dicho segundo dispositivo incluye un servidor de red.

7. - El método de conformidad con la reivindicación 1, caracterizado porque dicho segundo dispositivo incluye un procesador de aplicación.

8. - El método de conformidad con la reivindicación 1, caracterizado porque dicho segundo dispositivo incluye un procesador criptográfico.

9. - El método de conformidad con la reivindicación 8, caracterizado porque dicho paso de determinar la información se efectúa utilizando dicho procesador criptográfico.

10.- El método de conformidad con la reivindicación 1, caracterizado porque dicha información es un número de identificación personal.

11.- El método de conformidad con la reivindicación 1, caracterizado porque dichos datos son datos de posición.

12.- El método de conformidad con la reivindicación 1, caracterizado porque dichos pasos de transferencia son ejecutados sobre una red abierta.

13.- El método de conformidad con la reivindicación 12 comprende también el paso de encriptar los datos cuando los datos se transfieren a través de una red abierta.

14.- El método de conformidad con la reivindicación 12, caracterizado porque dicha transferencia se ejecuta bajo SSL.