ES2923919T3 - Protección de una comunicación P2P - Google Patents

Protección de una comunicación P2P Download PDF

Info

Publication number
ES2923919T3
ES2923919T3 ES19000473T ES19000473T ES2923919T3 ES 2923919 T3 ES2923919 T3 ES 2923919T3 ES 19000473 T ES19000473 T ES 19000473T ES 19000473 T ES19000473 T ES 19000473T ES 2923919 T3 ES2923919 T3 ES 2923919T3
Authority
ES
Spain
Prior art keywords
user
data
card
communication
certification
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
ES19000473T
Other languages
English (en)
Inventor
Volker Stöhr
Frank-Michael Kamm
Nils Gerhardt
Andreas Chalupar
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Giesecke and Devrient Mobile Security GmbH
Original Assignee
Giesecke and Devrient Mobile Security GmbH
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Giesecke and Devrient Mobile Security GmbH filed Critical Giesecke and Devrient Mobile Security GmbH
Application granted granted Critical
Publication of ES2923919T3 publication Critical patent/ES2923919T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H04W12/069—Authentication using certificates or pre-shared keys
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication
    • G06F21/32—User authentication using biometric data, e.g. fingerprints, iris scans or voiceprints
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication
    • G06F21/33—User authentication using certificates
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication
    • G06F21/34—User authentication involving the use of external additional devices, e.g. dongles or smart cards
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0853—Network architectures or network communication protocols for network security for authentication of entities using an additional device, e.g. smartcard, SIM or a different communication terminal
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0838—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these
    • H04L9/0841—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these involving Diffie-Hellman or related key agreement protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3234—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving additional secure or trusted devices, e.g. TPM, smartcard, USB or software token
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/40—Security arrangements using identity modules
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0861—Network architectures or network communication protocols for network security for authentication of entities using biometrical features, e.g. fingerprint, retina-scan
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/60—Context-dependent security
    • H04W12/65—Environment-dependent, e.g. using captured environmental data

Abstract

La invención se refiere a un método para asegurar la comunicación peer-to-peer entre dos terminales (10), que permite utilizar tarjetas inteligentes convencionales (11) en lugar de otros tokens de hardware que deben proporcionarse primero. En particular, la presente invención permite realizar una comunicación de datos particularmente segura en la que no es necesaria ninguna modificación del hardware subyacente. Un usuario se registra ante una autoridad de certificación (30) vinculando la prueba de posesión de un elemento de seguridad (204, ..., 212) y la identidad del usuario en base a los datos personales del usuario. Se genera un certificado de usuario (214) utilizando los datos personales del usuario y una clave pública. La presente invención también está dirigida a una disposición de comunicación configurada correspondientemente para asegurar la comunicación entre pares ya un producto de programa informático con comandos de control que implementan el método o hacen funcionar la disposición de comunicación. (Traducción automática con Google Translate, sin valor legal)

Description

DESCRIPCIÓN
Protección de una comunicación P2P
La presente invención se refiere a un procedimiento para proteger una comunicación de igual a igual (peer to peer) entre dos terminales, que permite emplear tarjetas inteligentes habituales, ya personalizadas sin que deban facilitarse tokens de hardware especialmente adaptados. En particular la presente invención, permite llevar a cabo una comunicación de datos segura sin que sea necesaria una modificación del hardware subyacente. La invención se refiere además a una disposición de comunicación configurada de manera correspondiente para proteger una comunicación de igual a igual, así como a un producto de programa informático con comandos de control, que implementan el procedimiento o hacen funcionar la disposición de comunicación.
Se conocen procedimientos en los que se protege una comunicación entre dos entidades en la tecnología de software. Preferiblemente en este sentido se aplican procedimientos criptográficos que se orientan en los datos en sí y los encripta, o también protegen el canal de comunicación de tal modo que se impiden diferentes escenarios de ataque. Uno de estos escenarios de ataque es el denominado ataque de reproducción en el que una tercera instancia no autorizada escucha una comunicación de datos entre dos instancias autorizadas y reproduce de nuevo después la comunicación de datos grabada. Por ejemplo se autentifica una primera instancia en una segunda instancia a través de un canal de comunicación, que no es seguro y se escucha. Dado que en este sentido se transfieren datos de autentificación válidos a una tercera instancia le es posible reproducir esta comunicación después de nuevo frente a la segunda instancia y por consiguiente obtener acceso a datos y servicios.
En cuanto a tecnología de hardware se conocen soluciones que se orientan a que el usuario lleve consigo un token de hardware que está especialmente protegido frente a ataques. Estos tokens de hardware presentan componentes electrónicos que pueden estar configurados para almacenar de manera segura claves criptográficas y ejecutar con ello dentro del token de hardware operaciones criptográficas y facilitarlas al usuario. La desventaja de dicho procedimiento es que la facilitación del token de hardware es compleja; además a menudo el usuario no está dispuesto a llevar otro aparato. Esto puede reducir la aceptación del usuario de dicho procedimiento.
Se conocen además soluciones según el estándar FIDO. A este respecto se realiza una autenticación unilateral de un usuario con respecto a un servicio central. La autenticación exige un registro anterior en este servicio central exactamente. Por esta razón no pueden utilizarse así como así soluciones según el estándar FIDO para una autenticación directa de un usuario frente a otro usuario cualquiera. La autenticación del servicio central frente al usuario se realiza con procedimientos establecidos, en particular con certificados de servidor SSL/TLS y X.509.
Además, el marco de autenticación universal (UAF) FIDO (Universal Authentication Framework) facilita un marco universal para la autentificación con el que es posible una autentificación sin clave. Este marco soporta por ejemplo características biométricas. El usuario se autentifica según el estándar UAF frente a su terminal móvil personal mediante su conocimiento, como por ejemplo un PIN o una contraseña y/o características biométricas.
En la autentificación de dos factores se utiliza preferiblemente el estándar común U2F (Universal Second Factor, segundo factor universal). La especificación U2F se gestiona mediante la alianza FIDO (Fast Identity Online).
Se conoce adicionalmente el denominado Universal Authentication Framework UAF, estandarizado mediante la alianza FIDO. En la página web https://fidoalliance.org/download/ puede accederse a especificaciones correspondientes. Esto es válido tanto para las especificaciones UAF como para las especificaciones U2F. En particular, además de la especificación UAF 1.1 pueden descargarse las especificaciones adicionales especificación de protocolo FIDO UAF y especificaciones FIDO 2.0.
La autentificación de dos factores se inicia por regla general al preguntar para la autentificación a un proveedor de servicios (Relying Party, parte de confianza) como primer factor el nombre del usuario, y dado el caso, la contraseña correspondiente, en donde el nombre del usuario identifica al usuario y la contraseña autentica al usuario. El proveedor de servicios verifica estos datos y, si los datos son correctos, inicia la comprobación del segundo factor (posesión) en forma de U2F.
En una primera etapa el proveedor de servicios (parte de confianza) envía un paquete de datos a un ordenador de cliente, como por ejemplo un navegador web. Este comprende un desafío, que son algunos datos seleccionados aleatoriamente, una identificación de aplicación (App-ID), y una identificación de clave (KeyHandle), que se ha guardado al iniciar la sesión inicial.
El ordenador de cliente verifica la identificación de aplicación, la complementa con datos adicionales como por ejemplo una identificación de canal (Channel ID) y transfiere estos datos cifrados al aparato U2F. El aparato U2F puede ser por ejemplo un candado (dongle) USB con un pulsador.
El aparato U2F con ayuda de la identificación de clave {KeyHandle) averigua la clave privada adecuada para esta sesión (kpriv), y firma con esta los valores cifrados de la identificación de aplicación y el desafío y forma así la respuesta de retorno firmada.
Adicionalmente un contador (Counter) se integra en la respuesta para poder identificar aparatos U2F duplicados. El ordenador de cliente, como por ejemplo el navegador web transfiere estos datos al proveedor de servicios que con la clave pública verifica la firma y los datos contenidos en esta y, en el caso de que sean correctos, concede el acceso.
El desafío en el FIDO-U2F es que esté diseñado para poder utilizarse en un PC o similar, en el que también un candado USB pueda utilizarse como segundo factor en una interfaz USB. Aunque es posible presentar el segundo factor a través de NFC o Bluetooth, sin embargo en este caso se requieren autenticadores especiales que, por regla general, deben crearse expresa y exclusivamente para el uso para FIDO.
La desventaja de los procedimientos conocidos es que las soluciones con tecnología software a menudo no son seguras y al menos se descubren fallos en la seguridad después de un periodo determinado. En cambio, si se emplea una solución con tecnología hardware, entonces existe la desventaja de que este hardware todavía tenga que adquirirse y distribuirse y el usuario además a menudo no acepte en la medida suficiente el que tenga que llevarlos consigo físicamente.
Por el documento JP 2012049752 A se conoce un procedimiento para facilitar un certificado que pueda almacenarse en una tarjeta IC para la utilización de servicios digitales que se ejecute mediante un terminal frente a un punto de registro y un punto de emisión. El usuario se registra en el punto de registro presentando un documento de identidad existente. La tarjeta IC calcula un par de claves PKI y envía al punto de registro la clave pública junto con un certificado formado mediante la clave secreta. Este verifica el par de claves PKI y su pertenencia a la tarjeta IC. Desde una base de datos el punto de registro averigua datos personales del usuario, y con la clave pública del par de claves PKI genera una petición de certificado que manda a la tarjeta IC. La tarjeta IC envía la petición de certificado al punto de emisión que genera el certificado de usuario y la devuelve a la tarjeta IC. El certificado de usuario se verifica desde el punto de registro.
El documento DE 102011013562 B3 describe un procedimiento para la autenticación para la realización de una comunicación confiable entre una primera parte y una segunda parte basada en una combinación de contraseñas y certificados.
El documento DE 102017000768 Al describe un procedimiento para realizar una autentificación de dos factores entre un cliente y una parte contraria, en donde como segundo factor se emplea un soporte de datos que realiza una comunicación con servidor adicional.
[seguir con la pág. 5 original]
En general existe una demanda de procedimientos especialmente sencillos que desde el punto de vista de los usuarios sean poco complejos y puedan realizarse en particular con el hardware existente.
El objetivo de la presente invención es indicar un procedimiento que permita a dos interlocutores no registrados en una instancia de registro común realizar una comunicación de igual a igual que se caracterice por una elevada seguridad y que pueda hacerse funcionar con hardware existente. Además va a proponerse una disposición de comunicación correspondiente, así como un producto de programa informático con comandos de control que ejecuten el procedimiento o hagan funcionar la disposición de comunicación.
El objetivo se resuelve con las características de las reivindicaciones independientes. Otras configuraciones ventajosas están indicadas en las reivindicaciones dependientes.
Se propone un procedimiento para proteger una comunicación de igual a igual entre dos terminales mediante tarjetas inteligentes, según la reivindicación 1.
La solución según la invención permite una autenticación recíproca de dos usuarios sin que estos tengan que registrarse previamente para ello especialmente. Más bien es suficiente con que los usuarios estén registrados en cada caso en una tercera instancia confiable.
La solución según la invención permite un aumento de la confianza en la identidad del interlocutor y la evitación de los denominados ataques de intermediario (Man-in-the-middle).
El experto distingue en este sentido que las etapas de procedimiento pueden ejecutarse iterativamente y en particular pueden ser necesarias otras subetapas. En particular es posible que las etapas de procedimiento se ejecuten del lado del emisor y después también se ejecuten del lado del receptor. Esto permite una protección de la comunicación por ambos lados. Si por lo tanto en lo sucesivo se describen etapas de procedimiento, entonces también es posible que emisores y receptores aparezcan recíprocamente y por consiguiente las etapas de procedimiento se ejecuten en ambos lados.
La comunicación de igual a igual propuesta es una comunicación de datos entre dos terminales, que preferiblemente se presentan como terminales móviles como teléfonos móviles. En este sentido el tipo de la comunicación de datos no está limitada sino que más bien debe protegerse cualquier tipo de comunicación de datos según la invención.
Una tarjeta inteligente es con frecuencia una tarjeta chip en el formado de tarjeta de crédito o generalmente un soporte de datos portátil de bolsillo, de pequeño formato; pero además pueden presentarse tarjetas inteligentes también en otros formatos, por ejemplo como pegatina, como llavero, como dispositivo portable o también en forma virtual. Normalmente las tarjetas inteligentes presentan componentes electrónicos que permiten comunicación de datos y procesamiento de datos. Así, las tarjetas inteligentes comprenden microcontroladores y memorias que permiten que puedan generarse informaciones criptográficas. Según la invención se ha reconocido que tales tarjetas inteligentes con progreso técnico son cada vez más eficientes y por consiguiente también pueden integrarse en procedimientos criptográficos.
La comunicación de datos entre tarjetas inteligentes y los terminales se realiza preferiblemente a través de una interfaz aérea. Para ello la tarjeta inteligente dispone de una antena en forma de bobina que es adecuada para inducir una corriente o efectuar la transmisión de datos. En este sentido, sin embargo, también es concebible que las tarjetas inteligentes estén equipadas con un suministro eléctrico para lo cual son adecuadas baterías. En un caso de aplicación preferido la tarjeta inteligente comunica de tal modo que esta se pone delante de un lector o del terminal móvil y a continuación se induce una corriente que lleva a cabo temporalmente el suministro eléctrico de los componentes. A modo de ejemplo la comunicación entre una tarjeta inteligente y un terminal puede efectuarse con contacto o sin contacto, por ejemplo mediante comunicación de campo cercano.
En una etapa de preparación, se realiza en cada caso un registro de cada usuario en un punto de certificación, que actúa como instancia confiable. Al usuario le corresponde registrar su terminal en el caso de un punto de certificación confiable. En el punto de certificación el usuario se registra junto con su elemento de seguridad, por ejemplo una tarjeta inteligente. El punto de certificación conoce los datos que identifican al usuario y al elemento de seguridad, es decir, por ejemplo, la tarjeta inteligente. Técnicamente el punto de certificación normalmente es un servidor que está acoplado en comunicación con el terminal o los terminales. En este sentido ventajosamente es posible que los terminales puedan estar acoplados en cada caso con un punto de certificación propio, separado mediante procesamiento de datos. Los terminales móviles están configurados de modo que también pueden transferir datos confiables al punto de certificación.
En el marco del registro la identidad del usuario se constata mediante un procedimiento adecuado al verificarse los datos personales del usuario. Generalmente son adecuados procedimientos que permiten por conexión online una identificación del usuario remota y confiable. Esto puede realizarse p. ej. con ayuda de tarjetas de identidad electrónicas, p. ej. un documento de identidad. Convenientemente la verificación sucede en un denominado procedimiento de identificación por vídeo. El punto de certificación actúa en este sentido como un servidor que lee la información necesaria del marco de datos correspondiente. Para constatar la identidad el usuario sujeta su documento de identidad, p. ej. una tarjeta de identidad electrónica, delante de una cámara e intercambia datos con un empleado del punto de certificación.
Por lo demás, el usuario prueba la posesión del elemento de seguridad. Esto puede realizarse p. ej. mediante una autenticación EMV cuando el elemento de seguridad es una tarjeta EMV. En el marco del intercambio de datos se verifica convenientemente también el elemento de seguridad, p. ej. a través de una NFC para garantizar una transmisión segura de todos los datos necesarios.
Mediante el registro se establece un enlace entre la prueba de la posesión de la tarjeta inteligente - así como opcionalmente un factor adicional, p. ej. el conocimiento de una contraseña - y la identidad del usuario y se almacenan los datos personales del usuario obtenidos a este respecto. El registro se realiza por regla general una vez. En autenticaciones futuras permite constatar la identidad del usuario solo mediante la prueba de la posesión de la tarjeta inteligente, o dado el caso, adicionalmente mediante la prueba de un factor adicional y asociarle los datos personales de usuario verificados. Es posible que un empleado del punto de certificación conozca personalmente al usuario, o que este también facilite datos biométricos que se lean de manera automatizada. En general también es posible que el usuario visite una filial del punto de certificación.
En el marco del proceso de registro es posible que el usuario facilite informaciones personales o datos de usuario, dado que este punto de certificación se considera confidencial. Así, el usuario, según lo desee, puede indicar datos de usuario personales y, dado el caso, conceder una contraseña. Ventajosamente los datos personales de usuario deben indicarse únicamente con respecto al punto de certificación y no se intercambian con otros terminales móviles.
El certificado de usuario firmado con la clave secreta del punto de certificación comprende tanto datos de usuario personales como una clave pública del usuario. Otra parte conoce la clave pública del punto de certificación y puede verificar con ello el certificado de usuario. Una clave pública es una información de un procedimiento criptográfico, en donde un acceso a datos y servicios se hace posible entonces en el caso de que una entidad pueda probar tanto la clave pública como la posesión de la clave privada secreta correspondiente. La clave pública se presenta como una información que puede distribuirse a través de una red a otros componentes. Así, la otra parte de una comunicación de datos siempre necesita la clave pública de un punto de certificación para poder leer o comprobar un certificado de usuario. Los procedimientos para generar claves públicas se conocen en los medios competentes.
Luego se realiza una firma de un mensaje de petición mediante la tarjeta inteligente y una adición del certificado de usuario generado al mensaje de petición firmado. La información resultante se denomina información de verificación. Presenta al menos el mensaje de petición firmado y el certificado de usuario probado. El mensaje de petición puede convertirse a este respecto y presentarse p. ej. en forma de un valor Hash.
En la transferencia de la información de verificación a un terminal móvil adicional se transfiere el mensaje de petición firmado, también denominado mensaje de desafío firmado, y el certificado de usuario mediante procesamiento de datos. El terminal móvil adicional es el interlocutor del terminal móvil, que se registra igualmente. Mediante la información de verificación transferida al terminal móvil adicional le es posible verificar la información de verificación, empleando la clave pública del punto de certificación. A este respecto se verifica si la información de verificación esperada ha llegado realmente en esta forma o si se ha producido una manipulación. Si la información de verificación se verifica negativamente, el procedimiento propuesto puede interrumpirse, y la comunicación de datos se considera no segura.
La etapa de procedimiento de la transferencia de la información de verificación puede realizarse también recíprocamente de tal modo que el primer terminal móvil transfiere la información de verificación al segundo terminal móvil, y después el segundo terminal móvil transfiere otra información de verificación al primer terminal móvil. Por consiguiente, el procedimiento puede realizarse iterativamente, y en particular la etapa de procedimiento de la transferencia de la información de verificación puede realizarse iterativamente de tal modo que en una primera dirección de comunicación se transfiere una primera información de verificación y en la dirección de vuelta, es decir, la segunda dirección de comunicación, se transfiere una segunda información de verificación. Esto se explica con más detalle más adelante con respecto a las figuras, que hacen visible que, hablando en sentido figurado, de izquierda a derecha se transfiere un primer certificado de usuario y de derecha a izquierda se transfiere otro segundo certificado de usuario.
Por consiguiente puede realizarse también una autenticación a ambos lados de dos terminales o de dos usuarios finales. Aunque también las etapas individuales del procedimiento propuesto pueden ser conocidas, la totalidad de las etapas de procedimiento permite una comunicación de datos elegante y eficiente. El procedimiento según la invención aprovecha a este respecto el que las nuevas tarjetas inteligentes dispongan de capacidades de cálculo aumentadas.
Según un aspecto de la invención el procedimiento se lleva a cabo recíprocamente en ambos lados de un canal de comunicación entre el terminal móvil y el terminal móvil adicional. Esto tiene la ventaja de que también es posible una autenticación recíproca y la comunicación de datos del terminal móvil al terminal móvil adicional también puede tener lugar en la dirección de vuelta. En particular pueden tener lugar también el registro y la autenticación del terminal móvil adicional. Por consiguiente el procedimiento se realiza simétricamente, y ambos terminales móviles comunican con el punto de certificación correspondiente.
Según un aspecto adicional de la invención entre ambos terminales un canal de comunicación protegido se construye mediante un procedimiento Diffie-Hellman. El procedimiento Diffie-Hellman es un protocolo conocido para el acuerdo de claves que permite a los interlocutores implicados proteger mediante la clave determinada una conexión de comunicación. El canal de comunicación protegido tiene la ventaja de que las etapas de procedimiento ya preparadas pueden realizarse a través del canal de comunicación y después el procedimiento según la invención puede utilizarse para proteger la comunicación. La negociación propiamente dicha de las claves en el procedimiento Diffie-Hellman se realiza entre los terminales implicados. Preferiblemente se comprueba que las claves sean auténticas empleando los elementos de seguridad, de modo que cada parte sabe con seguridad con quién comunica.
Según un aspecto adicional de la invención el registro del usuario comprende un procedimiento de identificación por vídeo. Esto tiene la ventaja de que el usuario puede registrarse de manera totalmente automática en el punto de certificación. En una variante el usuario presenta su documento a un empleado del punto de certificación a través de una conexión de audio y vídeo.
En el contexto de la invención el punto de certificación es un servidor. El punto de certificación puede estar realizado también como unidad de certificación, en donde el procedimiento propuesto se lleva a cabo por completo mediante procesamiento de datos sin que el usuario tenga que dirigirse personalmente a una filial.
Convenientemente el certificado de usuario presenta una validez temporal. Esto tiene la ventaja de que se prevea un mecanismo de seguridad adicional y la verificación solo se desarrolla positivamente en el caso de que el certificado de usuario también sea realmente válido. Para ello puede fijarse un periodo de validez o una fecha de vencimiento.
Convenientemente el certificado de usuario se almacena en un terminal móvil y/o en una memoria de datos del punto de certificación. Esto tiene la ventaja de que existe un control sobre dónde se guardan los datos personales del usuario incluidos en el certificado de usuario como nombre, dirección, etc.
Según un aspecto adicional de la invención el certificado de usuario se transfiere del punto de certificación al terminal y a continuación se borra localmente del punto de certificación. Esto tiene la ventaja de que los datos relevantes para la seguridad, que no se limitan únicamente al certificado de usuario, se borran rápidamente después de su uso y por consiguiente puede impedirse un acceso no autorizado. Por consiguiente se impide que un certificado de usuario se lea por un usuario no autorizado y que se abuse de la información personal incluida en el certificado de usuario.
Según un aspecto adicional de la invención se prevén interfaces que permiten una comunicación de datos con otros procedimientos de autenticación. Esto tiene la ventaja de que el procedimiento propuesto pueda integrarse en marcos de trabajo existentes y, en particular, que puedan utilizarse implementaciones de estos marcos de trabajo según la invención. Las interfaces permiten en este sentido una comunicación de datos y pueden referirse también a formatos de mensaje para que sea posible que los mensajes que son necesarios para implementar el procedimiento propuesto puedan leerse o interpretarse también por otros marcos de trabajo.
Convenientemente, el terminal se facilita como un teléfono móvil que comunica inalámbricamente con la tarjeta inteligente. Esto tiene la ventaja de que se crea una alta aceptación del usuario dado que el usuario normalmente lleva consigo su teléfono inteligente y por consiguiente puede proteger en cualquier momento la comunicación también de manera móvil. Preferiblemente la comunicación de datos puede llevarse a cabo mediante campo cercano, lo que sin embargo no ha de entenderes como restrictivo.
En una variante la tarjeta inteligente puede estar realizada también en forma electrónica en forma de una HCE (Host Card Emulation, emulación de tarjeta). En otras variantes la tarjeta inteligente se presenta en otros factores de forma, p. ej. como eUICC (UICC integrado). En una forma de realización preferida la tarjeta inteligente se presenta como tarjeta EMV. EMV significa Europay, Mastercard y VISA. Estas tarjetas ya gozan de una amplia difusión en el mercado. La utilización de tarjetas EMV tiene la ventaja de que puedan volver a emplearse procedimientos conocidos para la comunicación con tales tarjetas sin que tengan que adaptarse. Una tarjeta inteligente en la forma de una tarjeta EMV se lleva por tanto a un nuevo contexto en el que se emplean certificados EMV existentes, habituales con respecto al punto de certificación. El punto de certificación crea después un certificado de usuario generado según la invención.
El objetivo se resuelve también mediante una disposición de comunicación para proteger una comunicación de igual a igual entre dos terminales mediante tarjetas inteligentes, según la reivindicación 14.
Los componentes propuestos pueden presentar componentes adicionales que asuman por ejemplo la comunicación de red. Normalmente el punto de certificación se presenta como un servidor, el terminal como un teléfono móvil y la tarjeta inteligente como una tarjeta EMV.
El objetivo también se resuelve mediante un producto de programa informático con instrucciones de control que implementan el procedimiento o hacen funcionar la disposición de comunicación propuesta.
En concreto, en el presente caso la tarjeta EMV va a utilizarse para la autenticación mutua de dos usuarios finales, en donde la autenticación propiamente dicha se realiza con ayuda de certificados de usuario alternativos y que los certificados EMV almacenados en la tarjeta EMV no se emplean en este momento.
Los componentes del procedimiento propuesto son dos móviles, como representantes técnicos en cada caso de un usuario, dos tarjetas EMV de los usuarios, así como en cada caso un punto de certificación, que puede expedir para un usuario en cada caso un certificado de usuario.
En la variante básica un usuario debe registrarse con sus datos personales en el punto de certificación, p. ej. a través de un procedimiento de identidad por vídeo. Con la identidad por vídeo u otro procedimiento adecuado el usuario prueba su identidad, es decir, se realiza una verificación de sus datos personales, como nombre, dirección, etc.
Después, el usuario con respecto al punto de certificación realiza una autenticación EMV normal, con lo cual el punto de certificación genera un certificado de usuario a través de los datos personales del usuario así como a través de la clave pública de la tarjeta EMV. Para la utilización en cada caso la tarjeta de un usuario firma un desafío y el terminal añade el certificado de usuario recibido anteriormente. El aparato opuesto puede verificar mediante la clave pública del punto de certificación el certificado de usuario y después verificar el desafío firmado.
Según la invención es especialmente ventajoso que el procedimiento presente etapas que describen características funcionales de la disposición de cálculo. La disposición de cálculo puede presentar características estructurales que pueden reproducirse funcionalmente también como etapas de procedimiento.
Otros diseños ventajosos se explican con más detalle mediante las figuras adjuntas. Muestran:
Fig. 1: una disposición de comunicación para proteger una comunicación de igual a igual;
Fig. 2: un registro del terminal o de la tarjeta EMV en el punto de certificación;
Fig. 3: una autenticación de igual a igual directa;
Fig. 4: un registro de la tarjeta EMV o del terminal en el punto de certificación;
Fig. 5: un aspecto de una autenticación de igual a igual directa;
Fig. 6 : un aspecto de una autenticación de igual a igual indirecta;
Fig. 7: un registro de un usuario mediante una contraseña;
Fig. 8 : una autenticación de igual a igual indirecta con una clave derivada;
Fig. 9: un diagrama de flujo para proteger una comunicación de igual a igual; y
Fig. 10: un aspecto adicional de una autenticación de igual a igual directa.
La Figura 1 muestra una forma de realización de la disposición de comunicación para proteger una comunicación de igual a igual entre dos terminales 10, 20 con ayuda de elementos 11, 21 de seguridad, en donde en el presente caso los terminales 10, 20 se presentan como teléfonos móviles y los elementos 11, 21 de seguridad se presentan como tarjetas inteligentes en forma de tarjetas EMV. Al menos una instancia 30, 40 confiable para la que se toma como base a continuación la realización como punto de certificación se da en el presente caso mediante un servidor.
La invención no está limitada a las formas de realización mencionadas. Por elemento 11, 21 de seguridad se entiende una unidad de procesamiento de datos limitada en recursos que mediante un tamaño de construcción reducido, así como arquitectura de software y hardware especial, está protegida frente a manipulaciones. Además de la realización como tarjeta inteligente los elementos 11, 21 de seguridad pueden presentar una serie de formas de construcción adicionales, por ejemplo la forma de un eUICC (UICC integrado), o sin cuerpo, p. ej. en forma de una HCE (Host Card Emulation). Un terminal puede ser en principio cualquier aparato que pueda comunicar con un elemento de seguridad.
Dos interlocutores 12, 22 que poseen en cada caso un terminal 10, 20, llamado en lo sucesivo también aparato, deben poder comunicar de manera segura entre sí mediante estos aparatos 10, 20. Cada uno de los interlocutores 12, 22 mencionados en el siguiente usuario posee en cada caso una tarjeta EMV 11, 21 y según un aspecto de la invención con esta tarjeta 11, 21 prueba su propia identidad directa o indirectamente con respecto al otro usuario 22, 12 o su aparato 20, 10.
La prueba de la identidad comprende por ejemplo la transmisión de nombre y apellido y/u otros datos que van a definirse. No es necesario que los dos usuarios 12, 22 ya se conozcan de antes. Ambos usuarios 12, 22 confían en una o varias instancias 30, 40 de orden superior que actúan como puntos de certificación (Certification Authorities, CA, autoridades de certificación).
La Figura 1 muestra los componentes de sistema implicados y sus conexiones. Por comunicación según un aspecto de la invención se entiende la transmisión de voz (telefonía), imágenes, mensajes (mensajería, chats) etc. Comunicación segura significa en particular la protección de autenticidad, integridad y confidencialidad de los datos transmitidos.
Para la autenticación deben utilizarse datos de tarjeta, en particular datos de tarjeta de tarjetas EMV. Los datos de tarjeta son datos que identifican la tarjeta, p. ej. una tarjeta inteligente que funciona como tarjeta EMV o de alguna otra manera están relacionados con la tarjeta, en particular el número de tarjeta (PAN = Primary Account Number, número de cuenta primario) y la fecha de vencimiento de la tarjeta. Los datos de tarjeta normalmente están almacenados en el chip y, si está presente, impresos o estampados en la banda magnética, así como sobre el cuerpo de tarjeta.
Si los elementos 11, 21 de seguridad son tarjetas inteligentes en forma de tarjetas EMV, llevan certificados de tarjeta. Con los certificados de tarjeta las organizaciones de tarjetas, p. ej. Visa o Mastercard, y los bancos emisores confirman la exactitud de los datos de tarjeta, en particular la relación entre datos de identificación de tarjeta y claves específicas para cada tarjeta. Los certificados y las claves específicas de cada tarjeta están almacenadas de manera estándar en el chip.
En la utilización de los datos de tarjeta para la autenticación debe evitarse que un interlocutor reciba datos de la tarjeta del otro interlocutor que podrían emplearse para transacciones de pago, en particular el número de tarjeta (PAN) y la fecha de caducidad de la tarjeta.
Al contrario que los usuarios 12, 22 las instancias de orden superior (CA) son confiables sin limitaciones de modo que a estas pueden transferirse datos de tarjeta adecuados para transacciones de pago.
Para la comunicación segura, entre los dos aparatos 10, 20 según un aspecto de la invención mediante un procedimiento de intercambio de claves Diffie-Hellman (DH basado en la función exponencial discreta o ECDH basado en curvas elípticas) para la duración de una comunicación se acuerda un secreto común en forma de una clave de sesión simétrica (Session Key, SK). Mediante (EC)DH se produce un canal a prueba de escuchas y protegido de manipulaciones. Esto se realiza de forma anónima, los dos usuarios 12, 22 todavía no conocen su identidad mutuamente. Un atacante denominado Man in the Middle (intermediario) podría establecer en cada caso una conexión con el primer usuario 12 y con el segundo usuario 22. Cuando se autentifican usuario 12 y usuario 22 mutuamente y a este respecto verifican que ambos emplean la misma clave de sesión SK no se impide sin embargo un ataque de Man in the Middle (intermediario).
En el caso más sencillo un usuario 12, 22 se identifica mediante una tarjeta EMV 11, 21 mediante la firma de un desafío. Para que el punto opuesto pueda verificar la identidad del otro usuario en cada caso necesita en cada caso una información confiable que pruebe la conexión de la identidad de usuario con la clave pública de la tarjeta EMV. Los certificados de tarjeta presentes en las tarjetas EMV 11, 21 no pueden emplearse para ello porque es cierto que contienen datos de tarjeta como el PAN, pero no la identidad de usuario requerida (nombre, apellido etc.). Por esta razón se emplean certificados de usuario (UserCert1, UserCert2) alternativos, que se crean mediante instancias confiables (CA) y en lo sucesivo se denominan certificados de usuario. En la firma a través del desafío entra también la clave de sesión SK acordada; esto se realiza de modo que el interlocutor que recibe la firma y conoce la SK puede comprobar la firma también, pero esto no puede determinarse desde la firma de la SK.
Los certificados de usuario se generan mediante puntos de certificación 30, 40 que en lo sucesivo también se denominan brevemente CA. Confirman la exactitud de los datos de usuario en conexión con las claves, mediante las cuales un usuario se autentifica frente a su interlocutor. En función de la variante estas son diferentes claves: Clave de la tarjeta EMV 11, 21 en la variante directa y clave del punto de certificación 30, 40 en la variante indirecta.
Para obtener de un CA 30, 40 un certificado de usuario, el usuario 12, 22, según un aspecto de la presente invención, debe registrarse previamente con sus datos de usuario personales en el CA 30, 40. Los datos de usuario son datos que identifican el usuario o que están relacionados con él de manera inequívoca, por ejemplo nombre, dirección, fecha de nacimiento. Los datos de usuario están impresos por ejemplo en su documento de identidad o almacenados en este. La identificación del usuario y la constatación de los datos de usuario puede realizarse p. ej. por identificación por vídeo.
Además, el usuario en el registro debe probar la posesión real del elemento de seguridad 11, 21. Si el elemento de seguridad 11, 21 es una tarjeta EMV, esto puede tener lugar mediante una autenticación EMV habitual empleando los datos de tarjeta y las funciones criptográficas asimétricas facilitadas empleando los certificados de tarjeta. Durante la autenticación los certificados de tarjeta se transmiten al punto de certificación y se verifican mediante este. La prueba de posición debe realizarse de modo que el CA 30, 40 esté seguro de que este usuario 12, 22 posee realmente el elemento de seguridad 11, 21.
En la protección de la comunicación de igual a igual con ayuda de tarjetas EMV pueden diferenciarse dos variantes fundamentales:
Variante básica A - autenticación directa: La firma de la tarjeta EMV 11, 21 de uno de los usuarios 12, 22 se verifica directamente mediante el aparato 20, 10 del otro usuario 22, 12. Un certificado de usuario de los CA 30, 40 confirma a este respecto la conexión de la clave pública de la tarjeta EMV 11,21 y datos de usuario del primer usuario 12, 22.
Variante básica B - autenticación indirecta: La firma de la tarjeta EMV 11, 21 de uno de los usuarios 12, 22 se verifica solo mediante el CA 30, 40. El CA 30, 40 crea una firma para la autenticación de uno de los usuarios 12, 22 , que se verifica por el aparato 20 , 10 del otro usuario 22, 12.
A continuación se describen con más detalle las variantes mediante posibles aspectos.
La Figura 2 muestra una primera parte de un primer aspecto A/1, que se refiere al registro de un usuario 12, 22 en un punto 30, 40 de certificación. El registro se realiza sin contraseña.
Un usuario 12, 22 se registra con ayuda de su aparato 10, 20 con sus datos personales y la tarjeta EMV 11, 21 en su CA 30, 40. Después de una comprobación exitosa mediante el CA 30, 40 este crea un certificado de usuario UserCert, etapa 214, a través de los datos personales del usuario 12, 22 y la clave pública de la tarjeta EMV 11, 21. El certificado de usuario es adecuado para una autenticación directa frente a otro usuario 12, 22. Es válido durante un periodo más largo. El certificado de usuario se almacena en el aparato 10, 20 del usuario 12, 22, normalmente hasta el final del periodo de validez.
La Figura 3 muestra como segunda parte de aspecto A/1 una autenticación de igual a igual (P2P) directa entre dos usuarios 12, 22, que se han registrado ambos en un CA 30, 40, como se describe mediante la Figura 2. Es posible que los dos usuarios 12, 22 se hayan registrado en la misma CA 30, 40. En el establecimiento de una comunicación P2P segura el usuario 12, 22 se autentica frente a otro usuario 22, 12 al firmar un valor hash a través de un desafío de la otra parte y la clave de sesión SK con su tarjeta EMV 11, 21, etapa 310. A esta firma añade el certificado de usuario UserCert almacenado en el aparato 10, 20. Transfiere la firma y certificado de usuario a la otra parte, es decir, al otro aparato 20, 10 para la verificación, etapa 314.
En la variante mostrada en las figuras 2 y 3 el aparato 10, 20, durante el establecimiento de la comunicación con el otro aparato 20, 10, ya no debe comunicar más con el CA 30, 40, dado que el certificado de usuario está almacenado en el aparato 10, 20. El CA 30, 40 durante la expedición del certificado de usuario solo debe procesar los datos del usuario 12, 22 y de la tarjeta EMV 11,21. Sin embargo no es necesario guardarlos de forma duradera en una base de datos.
No obstante, para la prueba de la posesión además del uso de la tarjeta EMV 11, 21 no está implicado ningún segundo factor, p. ej. el conocimiento de un PIN o de una contraseña. Dado que el certificado de usuario UserCert está almacenado en el aparato 10, 20, el usuario 12, 22 siempre debe emplear el mismo aparato 10, 20 o copiar el certificado de usuario en otros aparatos.
La Figura 4 muestra un aspecto adicional que se refiere al registro de un usuario 12, 22 en un punto de certificación 30, 40 empleando una contraseña y sirve para los aspectos A/2, A/3, B/1. El registro se realiza sin la creación inmediata de un certificado de usuario.
Un usuario 12, 22 se registra con sus datos de usuario personales, una contraseña elegida por él mismo, etapa 400 y la tarjeta EMV 11, 21 en su CA 30, 40. Después de una comprobación exitosa mediante el CA 30, 40, este almacena los datos en una base de datos de usuario. En este momento el CA 30, 40 todavía no expide ningún certificado de usuario.
La Figura 5 muestra una autenticación P2P directa según un aspecto A/2 entre dos usuarios 12, 22 empleando una contraseña. Los usuarios 12, 22 se han registrado en cada caso en un CA 30, 40 común o dos distintos, como se representa en la Figura 4. El certificado de usuario no se expide hasta cuando se produce la autenticación.
En el establecimiento de una comunicación P2P segura el aparato 10, 20 exige del CA 30, 40 un certificado de usuario expedido. Para ello el usuario 12, 22 se autentica con su tarjeta EMV 11, 21 y su contraseña frente al CA 30, 40. Después de una verificación exitosa de una autenticación de dos factores, con ayuda de la base de datos de usuario, el CA 30, 40 expide un nuevo certificado de usuario UserCert, etapa 518. Con este certificado de usuario el CA 30, 40 confirma no solo la exactitud de los datos de usuario (nombre y apellido etc.) y de la clave pública de la tarjeta EMV 11, 21, sino que incluye adicionalmente el desafío Chpeer del usuario P2P 22, 12. Con ello el CA 30, 40 con respecto al interlocutor P2P 22, 12 confirma que el certificado de usuario está expedido especialmente para esta autenticación P2P.
La autenticación adicional del usuario 12, 22 con respecto al interlocutor P2P 22, 12 se realiza análogamente a la variante A/1.
En la variante mostrada en la Figura 5 se respalda una autenticación de dos factores del usuario 12, 22. El certificado de usuario UserCert no necesita almacenarse en el aparato 10, 20. El aparato 10, 20 solo debe saber a qué CA 30, 40 debe conectarse. Con ello, para el usuario 12, 22 es más fácil emplear varios aparatos.
No obstante el CA 30, 40 debe expedir un certificado de usuario para un aparato 10, 20 cada vez que quiere establecer una comunicación con otro aparato 20, 10. El CA 30, 40 requiere una base de datos para el almacenamiento duradero de los datos de usuario, una potencia de cálculo superior, una mayor disponibilidad. Además, el CA 30, 40 llega a saber qué usuario 12, 22 comunica, cuándo y con qué frecuencia. Con la tarjeta EMV 11, 21 se realizan dos autenticaciones, concretamente una con respecto al CA 30, 40 y una con respecto al otro usuario 22, 12. Una tarjeta NFC 11, 21 debe mantenerse para ello durante más tiempo en el campo. En algunas tarjetas (p. ej. Visa qVSDC), el contador de transacciones de aplicación (ATC, Application Transaction Counterde 2 byte) se incrementa cada vez en 2 en la tarjeta EMV. A consecuencia del mayor número de autenticaciones la tarjeta “ se desgasta” más rápidamente.
La Figura 10 muestra una variante A/3 que es una modificación de variante A/2 en la que la tarjeta EMV 11, 21 para una autenticación P2P debe contar solo una firma. La información de entrada para esta firma comprende ambos desafíos (CHpeer del interlocutor P2P y CHca de la CA) y la clave de sesión SK. Para que el CA 30, 40 y el interlocutor P2P puedan verificar la firma se les debe transferir los desafíos desconocidos en cada caso del aparato 10, 20. Para que la clave de sesión SK del CA no tenga que revelarse no entra directamente en la firma sino solo un valor hash a través de la SK y el desafío CHpeer. Por consiguiente, el desafío CH, que se firma mediante la tarjeta EMV se define de la siguiente manera:
CHpeer' = hash(CHpeer || SK)
CH = hash(CHca || CHpeer1)
En la variante mostrada en la Figura 10 la tarjeta EMV 11, 21 debe calcular ventajosamente solo una firma. No se producen limitaciones con respecto a la variante A/2.
La Figura 6 muestra un aspecto adicional B/1, que se refiere a una autenticación P2P indirecta entre dos usuarios 12, 22. El registro de los usuarios 12, 22 se realiza como se representa en la Figura 4.
Un usuario 12, 22 se registra con sus datos personales, una contraseña elegida por él mismo y la tarjeta EMV 11,21 en su CA 30, 40, etapa 402. Después de una comprobación exitosa mediante el CA 30, 40, etapa 404, este almacena los datos en una base de datos de usuario. En este momento el CA 30, 40 todavía no expide ninguna firma.
En el establecimiento de una comunicación P2P segura, el aparato 10, 20 exige del CA 30, 40 una firma de autenticación. Para ello el usuario 12, 22 se autentica con su tarjeta EMV 11, 21 y su contraseña con respecto al CA 30, 40, etapas 602, 608, 610, 612, 614. Después de la verificación exitosa de la autenticación de dos factores con ayuda de la base de datos de usuario, el CA 30, 40 crea la firma de autenticación a través de los datos de usuario (nombre y apellido etc.) y el valor hash a través del desafío CHpeer y la clave de sesión SK. Con ello el CA 30, 40 confirma la identidad del usuario 12, 22 con respecto al interlocutor P2P 22, 12 para esta sesión. Esta firma se transfiere desde el aparato 10, 20 al usuario P2P 22, 12 para la verificación.
Aunque la tarjeta EMV 11, 21 solo respalde la firma de un número impredecible de 4 Byte de longitud (CHca), puede considerarse completamente un CHpeer más largo en la firma de autenticación mediante los CA 30, 40.
La variante mostrada en la Figura 6 favorece una autenticación de dos factores del interlocutor. No es necesario almacenar ningún certificado de usuario UserCert en el aparato. El aparato 10, 20 solo debe saber a qué CA 30, 40 debe conectarse. Con ello, para el usuario 12, 22 es más fácil emplear varios aparatos.
No obstante el CA 30, 40 debe expedir una firma para un aparato, cada vez que quiere establecer una comunicación con otro aparato 20, 10. El CA 30, 40 requiere una base de datos para el almacenamiento duradero de los datos de usuario, una potencia de cálculo superior, una mayor disponibilidad. Además, el CA 30, 40 llega a saber qué usuario 12, 22 comunica, cuándo y con qué frecuencia.
La Figura 7 muestra un aspecto B/2, que se orienta a un registro de un usuario 12, 22 mediante una contraseña y se basa en la formación de un par de claves.
Un usuario 12, 22 se registra con sus datos personales, una contraseña elegida por él mismo, etapa 700 y la tarjeta EMV 11, 21 en su CA 30, 40, p. ej. un servidor de token, etapa 702, 704, 712. Después de la comprobación exitosa, etapa 714, mediante el CA 30, 40, a partir de los datos de tarjeta y la contraseña con ayuda de una clave maestra que solo conoce el CA 30, 40, este deriva un par de claves, etapa 716. El CA30, 40 crea un certificado de usuario UserCert a través de los datos personales del usuario 12, 22 y la clave pública del par de claves derivado, etapa 718. El certificado de usuario es válido durante un periodo más largo. El certificado de usuario se envía al aparato 10, 20, etapa 720, y este lo almacena, etapa 722. El CA 30, 40 desecha el certificado de usuario y el par de claves derivado.
La Figura 8 muestra una autenticación P2P indirecta según un aspecto B/2 entre dos usuarios 12, 22 con ayuda una contraseña mediante la formación de una clave derivada, en donde un certificado de usuario está almacenado en el aparato 10, 20. El registro del usuario 12, 22 se realiza como se representa mediante la Figura 7.
En el establecimiento de una comunicación P2P segura el aparato 10, 20 exige del CA 30, 40 una firma de autenticación, etapa 810. Para ello el usuario 12, 22 se autentica con su tarjeta EMV 11, 21 frente al CA 30, 40. El aparato 10, 20, etapa 816, envía también todos los demás datos necesarios al CA 30, 40: la contraseña, el certificado de usuario UserCert, el valor hash a través del desafío CHpeer del usuario 22, 12 y la clave de sesión SK.
Después de una verificación exitosa de la autenticación EMV, el CA 30, 40 a partir de los datos de tarjeta y la contraseña, con ayuda de la clave maestra CA deriva un par de claves, etapa 820; en caso de datos correctos se produce el mismo par de claves que en el registro, etapa 716. El CA 30, 40 verifica que la clave pública del par de claves derivado se ajusta al certificado de usuario UserCert, etapa 822.
Después de una verificación exitosa el CA 30, 40 con la clave privada del par de claves derivado crea la firma de autenticación a través del valor hash del desafío CHpeer y de la clave de sesión SK, etapa 824. El CA 30, 40 envía la firma Sig al aparato 10, 20, etapa 826. El aparato 10, 20 transfiere esta firma junto con el certificado de usuario UserCert al aparato 20, 10 del interlocutor P2P 22, 12 para la verificación, etapa 828.
En la variante mostrada en la Figura 8 siempre se realiza una autenticación de dos factores. No es necesario almacenar ninguna clave privada en el aparato o el CA.
Dado que el certificado de usuario UserCert está almacenado en el aparato 10, 20, un usuario 12, 22 siempre debe emplear en realidad el mismo aparato 10, 20 o copiar el certificado de usuario en otros aparatos. El CA 30, 40 llega a saber cuándo y con qué frecuencia un usuario 12, 22 comunica, es necesario en cada establecimiento de sesión y necesita una potencia de cálculo y disponibilidad correspondiente.
En una variante B/3, que es una modificación de la variante B/2, el certificado de usuario UserCert en el marco del registro no está almacenado en el aparato 10, 20 sino en una base de datos del CA (servidor de token).
En el establecimiento de la comunicación P2P el CA 30, 40 a partir de los datos de tarjeta EMV y la contraseña, como en la variante B/2, con ayuda de una clave maestra, que solo conoce el CA 30, 40 deriva el par de claves y con la clave pública puede encontrar el certificado de usuario correspondiente en la base de datos. Con respecto a la variante B/2 esta tiene la ventaja de que no es necesario almacenar ningún certificado de usuario UserCert en el aparato 10, 20. El aparato 10, 20 solo debe saber a qué CA 30, 40 debe conectarse. Con ello para un usuario 12, 22 es más fácil emplear varios aparatos. No obstante el CA necesita una base de datos para el almacenamiento de los certificados de usuario.
Generalmente puede haber uno o también varios puntos de certificación. Cada CA posee al menos un par de claves de raíz CA Root Key Pair. Un usuario 12, 22 puede seleccionar el CA 30, 40 mediante el cual puede certificarse. Los aparatos 10, 20 contienen las claves públicas de raíz CA de todos los CA para la comprobación de los certificados de usuario, p. ej., dentro de un almacén de claves de la aplicación de comunicación, estas están protegidas contra manipulaciones. Dos usuarios 12, 22, que quieren comunicar entre sí pueden estar certificados por los mismos CA 30, 40 o por diferentes CA 30, 40.
En los diagramas de secuencias la autenticación del usuario 12 con el aparato 10 con respecto al usuario 22 con el aparato 20 y la autenticación del usuario 22 en dirección opuesta con el aparato 20 con respecto al usuario 12 con el aparato 10 están representadas sucesivamente por razones de claridad. Para un desarrollo más rápido ambas autenticaciones pueden llevarse a cabo también en paralelo.
Sería concebible también que solo un usuario 12, 22 esté certificado por un CA 30, 40. También en este caso puede lograrse una cierta seguridad cuando ambos usuarios 12, 22 ya se conocen de antes. Cuando el usuario 12 se autentica con respecto al usuario 22 mediante certificado de usuario, a continuación el usuario 22 puede presentar de forma convincente su identidad dentro de la comunicación siguiente. Puede estar seguro a este respecto que no comunica información expresada a un atacante.
En todas las variantes presentadas, al usuario 12, 22 se le facilita un desafío CHpeer que adicionalmente a la clave de sesión SK entra en la firma de autenticación. En ambos casos, este desafío por razones de seguridad es necesario, en algunos casos puede renunciarse a este, lo que simplifica el procedimiento.
Si la inclusión del desafío CHpeer es necesaria depende de la variante del procedimiento y del tipo de la tarjeta EMV 11, 21. Como explicación se contempla el caso de que no sea el usuario autorizado 12, 22 con una tarjeta EMV 11, 21 auténtica quien quiera autenticarse frente a un usuario 22, 12, sino un atacante que en lugar de la tarjeta EMV 11, 21 solo posee varias firmas ya calculadas relativas a varios desafíos posibles CH. Adicionalmente se supone que se trata de un tipo de tarjeta EMV 11, 21 en el que solo un número no predecible de 4 Byte de longitud, Unpredictable Number, entra como desafío CH en el cálculo de firma.
Sin desafío CHpeer el siguiente ataque ahora sería posible: En el marco del intercambio de claves Diffie-Hellman ambos lados generan un par de claves a partir de claves privadas y públicas, y transfieren su clave pública al otro lado en cada caso. Cuando entonces el atacante ya ha recibido por la otra parte su clave pública, puede generar sus propios pares de claves hasta que se produzca una clave de sesión SK para la cual el atacante posee una firma de autenticación adecuada. En función del número de las firmas presentes, de la potencia de cálculo del atacante y longitud del desafío CH puede realizarse rápidamente un ataque de este tipo. Un ataque de este tipo puede evitarse porque, además de la clave de sesión SK, también se emplea un desafío CHpeer para el cálculo del desafío CH, y la otra parte genera el desafío CHpeer solo después de que la clave de sesión SK ya esté fijada.
La Figura 9 muestra un diagrama de flujo del procedimiento propuesto para proteger una comunicación de igual a igual entre dos terminales 10, 20 mediante tarjetas inteligentes 11, 21, que comprende un registro 100 de un usuario 12, 22 en un punto 30, 40 de certificación mediante una tarjeta inteligente 11, 21 y un terminal móvil 10, 20, una autenticación 101 del usuario en el punto 30, 40 de certificación mediante datos de usuario personales, una generación 102 de un certificado de usuario mediante el punto de certificación 30, 40 empleando datos personales de usuario, así como empleando una clave pública, que está almacenada en la tarjeta inteligente 11, 21, una firma de un mensaje de petición mediante la tarjeta inteligente 11, 21 y añadir el 102 certificado de usuario generado al mensaje de petición firmado mediante el terminal 10, 20 para crear una información de verificación y una transferencia de la información de verificación a un terminal móvil adicional, que mediante la clave pública verifica la información de verificación.
Con respecto al estado de la técnica la presente invención crea las siguientes ventajas:
Las tarjetas EMV 11, 21 ya emitidas y personalizadas pueden emplearse como token de seguridad para la autenticación sin que las tarjetas 11, 21 estén capacitadas originariamente para ello.
Una modificación de las tarjetas 11, 21 no es necesaria (ninguna aplicación pequeña adicional, ninguna modificación del sistema operativo de tarjeta, ningún requisito de almacenamiento mayor, ningún encarecimiento de las tarjetas).
El usuario final 12, 22 no necesita llevar ningún token adicional consigo, el editor no necesita editar ningún token nuevo. Hay disponible directamente como token de seguridad una base de tarjetas de > mil millones de tarjetas emitidas.
Con respecto al procedimiento de software se produce una seguridad claramente más elevada dado que las claves de autentificación privadas están vinculadas a un elemento de seguridad de hardware (tarjeta EMV). En conexión con PIN/contraseña resulta un procedimiento de dos factores auténtico con la seguridad criptográfica de la tarjeta 11, 21. No es necesario almacenar ninguna clave privada en un aparato de cliente potencialmente no seguro.
En el caso de las variantes A/1 y B/2, no es necesario que el CA 30, 40 (servidor de token) implicado almacene datos específicos de cada usuario. Las claves derivadas dinámicamente se desechan inmediatamente después de la autenticación. Por consiguiente, no se originan bases de datos con datos de usuario que podrían ser atacados potencialmente.

Claims (13)

  1. REIVINDICACIONES
    i. Procedimiento para proteger una comunicación de igual a igual (peer to peer) entre dos terminales (10, 20) mediante elementos de seguridad que comprende:
    - registrar (100) un usuario (12, 22) en un punto (30, 40) de certificación mediante el enlace de las pruebas de la posesión de un elemento (11, 21) de seguridad y la identidad del usuario (12, 22), en donde la prueba de la identidad se realiza mediante datos de usuario personales, y la prueba de la posesión se realiza mediante certificados de tarjeta que prueban la relación entre datos de identificación del elemento (11, 12) de seguridad y claves almacenadas en el elemento (11, 12) de seguridad y se verifican mediante el punto (30, 40) de certificación;
    - generar (102) un certificado de usuario mediante el punto (30, 40) de certificación a través de los datos de usuario personales, así como a través de una clave del usuario pública almacenada en el elemento (11, 12) de seguridad o a través de una clave pública facilitada por el punto (30, 40) de certificación después de la autenticación del usuario (12, 22);
    - firmar (103) un mensaje de petición mediante el elemento (11, 21) de seguridad empleando una clave secreta que se corresponde con una clave pública del usuario o mediante el punto (30, 40) de certificación empleando una clave secreta facilitada mediante el punto (30, 40) de verificación;
    - añadir (104) el certificado de usuario generado (102) al siguiente mensaje de petición mediante el terminal (10, 20) o el punto (30, 40) de certificación para crear una información de verificación; y - transferir (105) la información de verificación a un terminal adicional (20, 10), que con ayuda de la clave pública del punto (30, 40) de certificación verifica (106) la información de verificación.
  2. 2. Procedimiento según la reivindicación 1, caracterizado por que la clave pública del usuario está guardada en el elemento (11, 21) de seguridad.
  3. 3. Procedimiento según la reivindicación 1 o 2, caracterizado por que el procedimiento se realiza recíprocamente en ambos lados de un canal de comunicación entre un primer terminal (10, 20) y un terminal (10, 20) adicional.
  4. 4. Procedimiento según una de las reivindicaciones anteriores, caracterizado por que entre los dos terminales (10, 20) se establece un canal de comunicación protegido mediante un procedimiento Diffie-Hellman.
  5. 5. Procedimiento según la reivindicación 4, caracterizado por que la clave acordada mediante procedimientos Diffie-Hellman se incluye en la creación de la información de verificación, y el terminal (20, 10) adicional en la verificación de la información de verificación comprueba la clave acordada mediante procedimientos Diffie-Hellman.
  6. 6. Procedimiento según una de las reivindicaciones anteriores, caracterizado por que la generación (102) de un certificado de usuario empleando los datos de usuario personales comprende una selección de datos de usuario calificados como confidenciales.
  7. 7. Procedimiento según una de las reivindicaciones anteriores, caracterizado por que el registro (100) del usuario comprende un procedimiento de identificación por vídeo.
  8. 8. Procedimiento según una de las reivindicaciones anteriores, caracterizado por que el certificado de usuario presenta una validez en el tiempo.
  9. 9. Procedimiento según una de las reivindicaciones anteriores, caracterizado por que el certificado de usuario se almacena en un terminal (10, 20) y/o en una memoria de datos del punto (30, 40) de certificación.
  10. 10. Procedimiento según una de las reivindicaciones anteriores, caracterizado por que el certificado de usuario se transfiere del punto (30, 40) de certificación al terminal (10, 20) y a continuación se borra localmente del punto de certificación.
  11. 11. Procedimiento según una de las reivindicaciones anteriores, caracterizado por que el terminal (10, 20) se facilita como teléfono móvil, y el elemento (11, 21) de seguridad como tarjeta inteligente que comunica inalámbricamente con el teléfono móvil (10, 20).
  12. 12. Procedimiento según la reivindicación 11, caracterizado por que la tarjeta inteligente (11, 21) está realizada como eUICC o en forma de un HCE.
  13. 13. Procedimiento según la reivindicación 11, caracterizado por que la tarjeta inteligente (11, 21) se presenta como una tarjeta EMV.
    Disposición de comunicación para proteger una comunicación de igual a igual entre dos terminales (10, 20) mediante elementos de seguridad que comprende:
    - un punto de certificación para registrar (100) un usuario (12, 22) mediante enlace de la prueba de la identidad mediante datos de usuario personales y la prueba de la posesión mediante certificados de tarjeta que prueban la relación entre datos de identificación del elemento (11, 12) de seguridad y claves almacenadas en el elemento (11, 12) de seguridad y se verifican por el punto (30, 40) de certificación;
    - una unidad de cálculo configurada para generar (102) un certificado de usuario mediante el punto (30, 40) de certificación a través de los datos de usuario personales, así como a través de una clave pública del usuario, que está almacenada en el elemento (11, 21) de seguridad o se facilita al usuario en el punto de certificación después de la autenticación;
    - una unidad de firma configurada para firmar (103) un mensaje de petición mediante el elemento de seguridad empleando una clave secreta que se corresponde con la clave pública del usuario o mediante el punto (30, 40) de certificación empleando una clave secreta facilitada mediante el punto (30, 40) de certificación y añadir (104) el certificado de usuario generado (102) al mensaje de petición firmado mediante el terminal (10, 20) o mediante el punto de certificación para crear una información de verificación; y
    - una unidad de interfaz adicional configurada para transferir (105) la información de verificación a un terminal adicional (10, 20), que mediante la clave pública verifica la información (106) de verificación.
    Producto de programa informático con instrucciones de mando que llevan a cabo el procedimiento según una de las reivindicaciones 1 a 14, cuando se ejecutan en un ordenador.
ES19000473T 2018-10-18 2019-10-16 Protección de una comunicación P2P Active ES2923919T3 (es)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
DE102018008271.8A DE102018008271A1 (de) 2018-10-18 2018-10-18 Absicherung einer P2P-Kommunikation

Publications (1)

Publication Number Publication Date
ES2923919T3 true ES2923919T3 (es) 2022-10-03

Family

ID=68295915

Family Applications (1)

Application Number Title Priority Date Filing Date
ES19000473T Active ES2923919T3 (es) 2018-10-18 2019-10-16 Protección de una comunicación P2P

Country Status (3)

Country Link
EP (1) EP3641369B1 (es)
DE (1) DE102018008271A1 (es)
ES (1) ES2923919T3 (es)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111597526B (zh) * 2020-07-23 2020-10-27 飞天诚信科技股份有限公司 一种凭据修正方法、系统和数据处理终端及其工作方法
DE102021124640A1 (de) * 2021-09-23 2023-03-23 3medi GmbH Verfahren zum digitalen Austauschen von Informationen

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2009070430A2 (en) * 2007-11-08 2009-06-04 Suridx, Inc. Apparatus and methods for providing scalable, dynamic, individualized credential services using mobile telephones
JP2012049752A (ja) * 2010-08-26 2012-03-08 Hitachi Ltd 電子証明書発行システムおよびその方法
DE102011013562B3 (de) * 2011-03-10 2012-04-26 Bundesrepublik Deutschland, vertreten durch das Bundesministerium des Innern, vertreten durch den Präsidenten des Bundesamtes für Sicherheit in der Informationstechnik Verfahren zur Authentisierung, RF-Chip-Dokument, RF-Chip-Lesegerät und Computerprogrammprodukte
DE102017000768A1 (de) * 2017-01-27 2018-08-02 Giesecke+Devrient Mobile Security Gmbh Verfahren zum Durchführen einer Zweifaktorauthentifizierung

Also Published As

Publication number Publication date
EP3641369B1 (de) 2022-07-06
DE102018008271A1 (de) 2020-04-23
EP3641369A1 (de) 2020-04-22

Similar Documents

Publication Publication Date Title
ES2887258T3 (es) Procedimiento para realizar una autenticación de dos factores
EP2369811B1 (en) System and methods for online authentication
RU2710897C2 (ru) Способы безопасного генерирования криптограмм
ES2816324T3 (es) Método que usa un único dispositivo de autenticación para autenticar a un usuario a un proveedor de servicios entre una pluralidad de proveedores de servicios y dispositivo para realizar dicho método
EP2401838B1 (en) System and methods for online authentication
ES2626064T3 (es) Procedimiento y sistema para autenticar a un usuario que utiliza un dispositivo móvil y por medio de certificados
ES2779750T3 (es) Sistema de firma electrónica para un documento electrónico que utiliza un circuito de autenticación de terceros
US8112787B2 (en) System and method for securing a credential via user and server verification
ES2644739T3 (es) Solicitud de certificados digitales
US6189098B1 (en) Client/server protocol for proving authenticity
ES2713390T3 (es) Procedimiento de verificación de identidad de un usuario de un terminal comunicante y sistema asociado
JP2009510644A (ja) 安全な認証のための方法及び構成
ES2659580T3 (es) Procedimiento de comprobación de la preservación de privacidad entre tres partes que se comunican entre sí
ES2769091T3 (es) Procedimiento de securización y de autentificación de una telecomunicación
US20230133418A1 (en) Personalised, server-specific authentication mechanism
WO2015055120A1 (zh) 用于安全性信息交互的装置
ES2923919T3 (es) Protección de una comunicación P2P
ES2773705T3 (es) Método para proporcionar firmas digitales seguras
ES2906397T3 (es) Método de autenticación con la ayuda de un terminal móvil que utiliza una clave y un certificado almacenado en un soporte externo
AU2016228254A1 (en) System and methods for online authentication
AU2015202661A1 (en) System and methods for online authentication
AU2015202677B2 (en) System and methods for online authentication