ES2866966T3 - Método para emitir tickets de autorización en un sistema inteligente de transporte - Google Patents

Método para emitir tickets de autorización en un sistema inteligente de transporte Download PDF

Info

Publication number
ES2866966T3
ES2866966T3 ES19153722T ES19153722T ES2866966T3 ES 2866966 T3 ES2866966 T3 ES 2866966T3 ES 19153722 T ES19153722 T ES 19153722T ES 19153722 T ES19153722 T ES 19153722T ES 2866966 T3 ES2866966 T3 ES 2866966T3
Authority
ES
Spain
Prior art keywords
server
account
authorization
enrollment
registration
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
ES19153722T
Other languages
English (en)
Inventor
Jasja Tijink
Refi-Tugrul Güner
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.)
Kapsch TrafficCom AG
Original Assignee
Kapsch TrafficCom AG
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 Kapsch TrafficCom AG filed Critical Kapsch TrafficCom AG
Application granted granted Critical
Publication of ES2866966T3 publication Critical patent/ES2866966T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/04—Payment circuits
    • G06Q20/045—Payment circuits using payment protocols involving tickets
    • G06Q20/0457—Payment circuits using payment protocols involving tickets the tickets being sent electronically
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/02—Reservations, e.g. for tickets, services or events
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
    • G06Q20/102—Bill distribution or payments
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q50/00—Information and communication technology [ICT] specially adapted for implementation of business processes of specific business sectors, e.g. utilities or tourism
    • G06Q50/40—Business processes related to the transportation industry
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07B—TICKET-ISSUING APPARATUS; FARE-REGISTERING APPARATUS; FRANKING APPARATUS
    • G07B15/00—Arrangements or apparatus for collecting fares, tolls or entrance fees at one or more control points
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07B—TICKET-ISSUING APPARATUS; FARE-REGISTERING APPARATUS; FRANKING APPARATUS
    • G07B15/00—Arrangements or apparatus for collecting fares, tolls or entrance fees at one or more control points
    • G07B15/02—Arrangements or apparatus for collecting fares, tolls or entrance fees at one or more control points taking into account a variable factor such as distance or time, e.g. for passenger transport, parking systems or car rental systems
    • 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/321—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 a third party or a trusted authority
    • H04L9/3213—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 a third party or a trusted authority using tickets or tokens, e.g. Kerberos
    • 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/02—Protecting privacy or anonymity, e.g. protecting personally identifiable information [PII]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/08—Access security
    • 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/69—Identity-dependent
    • H04W12/75—Temporary identity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/30—Services specially adapted for particular environments, situations or purposes
    • H04W4/40—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/42—Anonymization, e.g. involving pseudonyms
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/30—Services specially adapted for particular environments, situations or purposes
    • H04W4/40—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P]
    • H04W4/42—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P] for mass transport vehicles, e.g. buses, trains or aircraft
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/30—Services specially adapted for particular environments, situations or purposes
    • H04W4/40—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P]
    • H04W4/44—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P] for communication between vehicles and infrastructures, e.g. vehicle-to-cloud [V2C] or vehicle-to-home [V2H]

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • General Business, Economics & Management (AREA)
  • Strategic Management (AREA)
  • Theoretical Computer Science (AREA)
  • Tourism & Hospitality (AREA)
  • Economics (AREA)
  • Development Economics (AREA)
  • Marketing (AREA)
  • Human Resources & Organizations (AREA)
  • Operations Research (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Quality & Reliability (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Primary Health Care (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Telephonic Communication Services (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

Un método para emitir tickets (ATn) de autorización seudónimos a los nodos (Ni) de un sistema inteligente SIT (1) de transporte cooperativo, , nodos (Ni) que intercambian mensajes (Mk), cada uno de los cuales está firmado con uno de dichos tickets (ATn) de autorización, comprendiendo el método: a) recibir una solicitud (TR) de ticket de un nodo (Ni) en un servidor (AA) de autorización del SIT (1), solicitud (TR) de ticket que contiene las credenciales (EC) de inscripción del nodo solicitante (Ni), en donde las credenciales (EC) de inscripción están encriptadas con una clave pública (Kpu) de un servidor (EA) de inscripción del SIT (1), y enviar (12) una solicitud (VR) de validación que contenga las credenciales (EC) de inscripción del nodo solicitante al servidor (EA) de inscripción; b) desencriptar las credenciales (EC) de inscripción contenidas en la solicitud (VR) de validación con una clave privada respectiva (Kpr) en el servidor (EA) de inscripción, realizar una verificación (13) de validez que solo se pasa cuando tanto el nodo solicitante (Ni) identificado por las credenciales (EC) de inscripción desencriptadas como, para el nodo solicitante (Ni), una cuenta (ACm) en un servidor (AS) de cuentas están inscritos con el servidor (EA) de inscripción y, en caso de que se apruebe la verificación (13) de validez, incrementar un valor (CV) de contador de un contador (CTm) asignado a dicha cuenta (ACm) y enviar (16) un mensaje (VM) de validación al servidor (AA) de autorización; c) emitir (17), cuando se recibe el mensaje (VM) de validación en el servidor (AA) de autorización , un ticket (ATn) de autorización seudónimo al nodo solicitante (Ni); d) repetir las etapas a) a c) hasta que expire un período (CP) de facturación predeterminado y, al expirar, enviar (21), desde el servidor (EA) de inscripción al servidor (AA) de autorización, un mensaje (ME) que contenga dicho valor (CV) de contador y un identificador (IAC) para dicha cuenta (ACm), calcular, a partir del valor (CV) de contador recibido en el servidor (AS) de autorización, una solicitud (CR) de cobro para la cuenta (ACm) identificada por el identificador recibido (IAC), y enviar (22) la solicitud (CR) de cobro al servidor (AS) de cuentas para realizar el cobro en dicha cuenta (ACm).

Description

DESCRIPCIÓN
Método para emitir tickets de autorización en un sistema inteligente de transporte
La presente invención se refiere a un método para emitir tickets de autorización seudónimos a nodos de un sistema inteligente de transporte cooperativo, nodos que intercambian mensajes, cada uno de los cuales está firmado con uno de dichos tickets de autorización.
Un sistema inteligente de transporte ("SIT", o “ ITS” por sus siglas en inglés) permite a los usuarios de la carretera y a los administradores de tráfico compartir información intercambiada por mensajes entre vehículos e infraestructura (también conocida como "estaciones SIT", en la presente memoria denominadas "nodos") en forma de comunicación vehículo a vehículo (V2V) y/o vehículo a infraestructura (V2I), y coordinar sus acciones. Los sistemas de este tipo son conocidos, entre otros, a partir de la Estrategia europea sobre sistemas inteligentes de transporte cooperativos ("SIT-C"), una iniciativa que discute e implementa la movilidad cooperativa, conectada y automatizada en un SIT. Se espera una mejora significativa de la seguridad vial, la eficiencia del tráfico y la comodidad de la conducción con el despliegue de un SIT como consecuencia de ayudar al conductor, habilitado por la conectividad digital entre vehículos y entre vehículos e infraestructura, a tomar las decisiones correctas y adaptarse a la situación del tráfico. Para muchos escenarios de conectividad digital, se deben verificar la autenticidad e integridad de los mensajes que normalmente contienen información como posición, velocidad, rumbo, etc. en lo que se refiere a la fiabilidad de la información intercambiada. Sin embargo, debe minimizarse el impacto en la privacidad de cada usuario de la carretera. Para lograr esos dos objetivos, los SIT-C han propuesto que cada mensaje enviado desde un nodo debe estar firmado por un ticket de autorización seudónimo que haya sido emitido al nodo a petición de este por un servidor de autorización de confianza (también conocido como "autoridad de autorización") y, por lo tanto, garantiza la autenticidad sin que el nodo se identifique en el mensaje. El nodo puede utilizar cada ticket de autorización para firmar uno o más mensajes; sin embargo, por razones de privacidad, los tickets de autorización usados serán reemplazados con frecuencia por otros nuevos. Además, la identidad de cada nodo está certificada por un servidor de inscripción (también conocido como "autoridad de inscripción"), con el que cada nodo debe inscribirse y que valida cada ticket de autorización antes de ser emitido por el servidor de autorización.
Por razones de privacidad, el servidor de autorización y el servidor de inscripción, aunque se comunican entre sí, están separados entre sí, de modo que el servidor de autorización no tiene acceso a las identidades de los nodos registrados con el servidor de inscripción y el servidor de inscripción no tiene acceso a los tickets de autorización emitidos por el servidor de autorización, como se describe, por ejemplo, en BilJmeyer N. et al., PRESERVE Technical Report 6 - Development of Life-Cycle Management Components, ETSI draft, v0.43, 650, route des Lucioles, F-06921 Sophia-Antipolis, Francia, vol. ITS, 17 de diciembre de 2012, págs. 1-48.
Si bien la autenticidad e integridad de cada mensaje intercambiado en el SIT puede demostrarse de manera efectiva, el número de tickets de autorización seudónimos que debe emitir el servidor de autorización es muy alto en un SIT que tenga muchos nodos. Por tanto, la carga en el servidor de autorización alcanza niveles elevados. No obstante, se desea dar servicio a un gran número de nodos de modo que toda la información de tráfico importante sea accesible para compartir dentro del SIT.
Es un objeto de la presente invención proporcionar un método para emitir tickets de autorización seudónimos que facilite la implementación de un SIT para un gran número de nodos con una privacidad mejorada.
Según la presente invención, este objeto se consigue mediante un método del tipo mencionado al principio, que comprende:
a) recibir una solicitud de ticket de un nodo en un servidor de autorización del SIT, solicitud de ticket que contiene las credenciales de inscripción del nodo solicitante, en donde las credenciales de inscripción están encriptadas con una clave pública de un servidor de inscripción del SIT, y enviar una solicitud de validación que contenga las credenciales de inscripción del nodo solicitante al servidor de inscripción;
b) desencriptar las credenciales de inscripción contenidas en la solicitud de validación con una clave privada respectiva en el servidor de inscripción, realizar una verificación de validez que solo se pasa cuando tanto el nodo solicitante identificado por las credenciales de inscripción desencriptadas como, para el nodo solicitante, una cuenta en un servidor de cuentas están inscritos con el servidor de inscripción y, en caso de que se pase la verificación de validez, incrementar un valor de contador de un contador asignado a dicha cuenta y enviar un mensaje de validación al servidor de autorización;
c) emitir, cuando se recibe el mensaje de validación en el servidor de autorización, un ticket de autorización seudónimo al nodo solicitante;
d) repetir las etapas a) a c) hasta que expire un período de facturación predeterminado y, al expirar,
enviar, desde el servidor de inscripción al servidor de autorización, un mensaje que contenga dicho valor de contador y un identificador de dicha cuenta,
calcular, a partir del valor de contador recibido en el servidor de autorización, una solicitud de cobro para la cuenta identificada por el identificador recibido, y enviar la solicitud de cobro al servidor de cuentas para realizar el cobro en dicha cuenta.
El presente método permite ofrecer la emisión de tickets de autorización seudónimos por parte del servidor de autorización en forma de servicio de pago descentralizado. Por lo tanto, se pueden agregar nuevos servidores de autorización, incluso uno por uno, al SIT y se facilita el reparto de esfuerzos (o carga) entre los servidores de autorización de tal modo que se pueda atender incluso a una gran cantidad de nodos, y aún en aumento, en el SIT. Al mismo tiempo, la privacidad de cada nodo no solo se mantiene sino que incluso se mejora debido al hecho de que no puede deducirse una relación entre un ticket emitido y un nodo solicitante a partir del valor de contador acumulado. Por lo tanto, el servidor de autorización, a pesar de emitir los tickets de autorización a los respectivos nodos solicitantes y enviar solicitudes de cobro al servidor de cuentas para realizar el cobro en la cuenta del nodo solicitante, no tiene la información necesaria para crear un vínculo entre la identidad o cuenta de un nodo y los tickets de autorización emitidos al nodo. Además, el servidor de autorización no puede desencriptar las credenciales de inscripción del nodo solicitante en la solicitud de ticket. En consecuencia, ni el servidor de autorización ni el servidor de inscripción, que no tiene información sobre los tickets de autorización emitidos, pueden rastrear qué ticket de autorización se emitió a qué nodo. Debe observarse en este contexto que el nodo cuando envía una solicitud de ticket usa, por ejemplo, un identificador de una sola vez o similar para su identificación con respecto al servidor de autorización.
Se entenderá que puede haber más de un servidor de cuentas. Cada servidor de cuentas puede mantener una o más cuentas y cada cuenta puede estar inscrita con el servidor de inscripción para uno o más servidores de autorización y/o para uno o más nodos. En una realización ventajosa, la cuenta en el servidor de cuentas está inscrita con el servidor de inscripción para más de un nodo. Por lo tanto, cuando varios nodos, por ejemplo, vehículos de un fabricante y/o tipo específico, comparten una cuenta común, se cargan en la cuenta todos los tickets de autorización emitidos por el servidor de autorización a todos los nodos que comparten esta cuenta. Mediante tal acumulación de cobros, la privacidad se mejora aún más. Sin embargo, en una realización alternativa, la cuenta en el servidor de cuentas está inscrita con el servidor de inscripción para un único nodo de modo que cada nodo, es decir, su cuenta, se cobra por separado de otros nodos, es decir, cuentas. Incluso en este caso, ni el servidor de inscripción ni el servidor de autorización tienen información suficiente para determinar qué ticket de autorización se ha emitido a qué nodo solicitante debido al contador acumulativo utilizado en el período de facturación, de modo que se mejora la privacidad.
Para la verificación de plausibilidad y/o resolución de disputas, es particularmente favorable cuando la etapa c) comprende además almacenar el mensaje de validación recibido en una base de datos del servidor de autorización. El servidor de autorización puede comparar entonces los valores de contador recibidos del servidor de inscripción para todas las cuentas con el número total de tickets de autorización emitidos a todos los nodos solicitantes durante el período de facturación y, si hay una discrepancia, se puede iniciar una resolución de disputas.
En una realización ventajosa, el servidor de inscripción firma digitalmente el mensaje que contiene el valor de contador y el identificador de la cuenta antes de enviarlo. De este modo, se garantiza la autenticidad del mensaje de tal manera que se evita la manipulación y se pueden resolver las discrepancias o disputas sobre una base certificada. Sin embargo, debe tenerse en cuenta que se puede emplear una arquitectura de seguridad incluso más extensa, por ejemplo, según el estándar ETSI TS 102940, con el apoyo de una infraestructura de clave pública (PKI) utilizando certificados de seudónimo cambiantes que pueden ser emitidos por, por ejemplo, una autoridad de certificado raíz que aprueba tanto el servidor de autorización como el servidor de inscripción. Además, la comunicación en el SIT generalmente puede estar encriptada y cada participante, es decir, cada uno de los nodos, el servidor de inscripción, el servidor de autorización y el servidor de cuentas, puede ser capaz de generar claves criptográficas y/o pares de claves para compartir con los otros.
La invención se explicará ahora con más detalle a continuación sobre la base de realizaciones ejemplares de la misma con referencia a los dibujos adjuntos, en los que:
La Figura 1 muestra un sistema inteligente de transporte cooperativo en un diagrama de bloques esquemático; y la Figura 2 muestra el método inventivo para emitir tickets de autorización seudónimos a nodos del sistema inteligente de transporte cooperativo de la Figura 1 en un diagrama de secuencia.
La Figura 1 muestra un ejemplo de un sistema inteligente de transporte cooperativo ("SIT") 1, por ejemplo, un SIT 1 según la Estrategia europea sobre sistemas inteligentes de transporte cooperativos ("SIT-C"). Dentro del SIT 1, se realiza el método que se muestra en la Figura 2. El SIT 1 comprende una pluralidad de nodos N1, N2 , ..., en general Ni, que intercambian mensajes M1, M2 , ..., en general Mk. Cada nodo Ni es, por ejemplo, un vehículo o un dispositivo de infraestructura tal que el intercambio de mensajes Mk permita que los usuarios de la carretera y los administradores de tráfico del SIT 1 compartan información, por ejemplo, mediante comunicación de vehículo a vehículo ("V2V") y/o de vehículo a infraestructura ("V2I").
Como se explicará con mayor detalle a continuación en el contexto de la Figura 2, el SIT 1 comprende al menos un servidor EA de inscripción (también: "autoridad de inscripción") y al menos un servidor AA de autorización (también: "autoridad de autorización"). El SIT 1 comprende además opcionalmente al menos una autoridad RCA de certificado raíz que aprueba (flechas 2 y 3, respectivamente) tanto el servidor AA de autorización como el servidor EA de inscripción, y un administrador TLM de listas de confianza opcional para habilitar (flecha 4) la autoridad RCA de certificado raíz. Además, el SIT 1 comprende al menos uno de entre uno o más operadores/fabricantes OM y uno o más servidores AS de cuentas, en donde cada servidor AS de cuentas mantiene una o más cuentas AC1, AC2, ..., en general ACm, una para cada uno o más nodos Ni y, cuando el SIT 1 comprende más de un servidor AA de autorización, para uno o más servidores AA de autorización. Para la comunicación entre el servidor EA de inscripción, el servidor AA de autorización, el operador/fabricante OM, el servidor AS de cuentas y los nodos Ni, el SIT 1 tiene enlaces L de comunicación, por ejemplo, enlaces L de comunicación por cable y/o inalámbricos. Cada enlace L de comunicación puede ser directo o mediante nodos intermedios Ni.
Cada mensaje Mk intercambiado en el SIT 1 deberá estar autenticado para su controlabilidad y para evitar la manipulación. Al mismo tiempo, se mantendrá la privacidad de los nodos Ni. Para lograr ambas cosas, cada mensaje Mk está firmado con un ticket AT1, AT2, ..., en general ATn de autorización seudónimo (Figura 2). El método de emisión de estos tickets ATn de autorización se explicará ahora en detalle con referencia a la Figura 2.
Cada nodo Ni se identifica en el servidor EA de inscripción mediante credenciales EC de inscripción que son adecuadas para identificar de forma inequívoca el nodo Ni. En el ejemplo mostrado en la Figura 2, en una primera etapa 5 del método el operador/fabricante OM registra información sobre cada nodo Ni - incluidas las credenciales EC de inscripción del mismo - con el servidor EA de inscripción como se conoce de, por ejemplo, el SIT-C. En otra realización, las credenciales EC de inscripción pueden ser generadas por el propio nodo Ni o proporcionadas al nodo Ni, por ejemplo, por el operador/fabricante OM, y luego se comparten con el servidor EA de inscripción.
En la etapa 6, el servidor AS de cuentas registra la cuenta ACm respectiva para cada nodo Ni y, en el caso de más de un servidor AA de autorización, para al menos un servidor de AA autorización con el servidor EA de inscripción. En una realización opcional, cuando el servidor AS de cuentas es operado por el operador/fabricante OM de manera que esté integrado en el mismo, las etapas 5 y 6 pueden fusionarse. De nuevo, la cuenta ACm para un nodo Ni alternativamente puede ser compartida con el servidor EA de inscripción por el propio nodo Ni, por ejemplo, después de haber sido proporcionada con el mismo por el servidor de cuentas AS. En una realización alternativa, el servidor AS de cuentas es operado por el servidor EA de inscripción de manera que esté integrado en el mismo; en este caso, la etapa 6 puede no ser necesaria, por ejemplo, cuando el propio nodo Ni registra su respectiva cuenta ACm con el servidor eA de inscripción, por ejemplo, durante la inscripción como se describe a continuación.
En la etapa 7, el servidor AS de cuentas se registra con el servidor AA de autorización. Este registro puede notificarse al servidor EA de inscripción en la etapa 8, ya sea en el momento del registro o cuando el servidor EA de inscripción lo solicite posteriormente. En otra realización, este registro con el servidor AA de autorización y/o la notificación del mismo al servidor EA de inscripción puede ser una condición previa para aprobar el servidor As de cuentas en el SIT 1 de manera que las etapas 7 y/o 8 sean innecesarias.
Después del registro, el nodo N1 envía una solicitud de inscripción (etapa 9) al servidor EA de inscripción. Cuando el nodo N1 se identifica en base a dicha información registrada, el servidor EA de inscripción devuelve las credenciales EC de inscripción, y la cuenta correspondiente ACm en el servidor de cuentas AS se inscribe para el nodo Ni (etapa 10). Las credenciales EC de inscripción de cada nodo Ni pueden cambiarse ocasional o regularmente.
Para que se emita un ticket ATn de autorización después de la inscripción, el nodo Ni envía una solicitud TR de ticket al servidor AA de autorización en la etapa 11. La solicitud TR de ticket contiene las credenciales EC de inscripción del nodo solicitante Ni, es decir, del nodo Ni que envía la solicitud TR de ticket. Las credenciales EC de inscripción del nodo solicitante Ni están encriptadas por el nodo solicitante Ni con una clave pública Kpu del servidor EA de inscripción. La clave pública Kpu es parte de un esquema de encriptado asimétrico como se conoce en la técnica; en el mismo, los datos encriptados con dicha clave pública Kpu solo se pueden desencriptar con una clave privada respectiva Kpr del servidor EA de inscripción, clave privada Kpr - siendo "privada" - que solo conoce el servidor EA de inscripción. Por lo tanto, el servidor AA de autorización no tiene acceso a las credenciales EC de inscripción encriptadas y, en particular, no puede deducir ninguna información sobre la identidad del nodo solicitante Ni a partir de las mismas.
Después de recibir una solicitud TR de ticket, el servidor AA de autorización genera, en la etapa 12, una solicitud VR de validación que contiene las credenciales EC de inscripción codificadas del nodo solicitante Ni. En algunas realizaciones, la solicitud VR de validación contiene partes adicionales de la solicitud TR de ticket o incluso la solicitud TR de ticket completa del nodo solicitante Ni. En la etapa 12, el servidor AA de autorización también envía la solicitud VR de validación generada al servidor EA de inscripción para su validación. Tras la recepción de dicha solicitud VR de validación, el servidor EA de inscripción realiza una verificación 13 de validez.
La verificación 13 de validez comprende al menos los siguientes criterios de validez que se verifican independientemente entre sí, es decir, en cualquier secuencia y/o en paralelo. Un primer criterio se verifica en la etapa 14 y se refiere a la inscripción del nodo solicitante Ni de tal modo que el primer criterio solo se satisface cuando el nodo solicitante N¡ identificado por las credenciales de inscripción desencriptadas EC está inscrito con el servidor EA de inscripción; de lo contrario, no se pasa la verificación 13 de validez. Un segundo criterio se verifica en la etapa 15. El segundo criterio solo se satisface cuando la cuenta ACm en el servidor AS de cuentas está inscrita con el servidor EA de inscripción para el nodo solicitante Ni identificado. Pueden verificarse otros criterios en la verificación 13 de validez, por ejemplo, que el servidor AS de cuentas esté registrado con el servidor AA de autorización cuando esto no sea una condición previa en el SIT 1. Solo cuando se satisfacen todos los criterios, se pasa la verificación 13 de validez; de lo contrario, no se pasa la verificación 13 de validez.
A cada cuenta ACm inscrita con el servidor EA de inscripción se le asigna un contador CT1, CT2, ... separado, en general CTm. Cuando se pasa la verificación 13 de validez, el servidor EA de inscripción, en la etapa 16', incrementa un valor CV de contador de ese contador CTm en el servidor EA de inscripción que está asignado a la cuenta ACm inscrita con el servidor EA de inscripción para el nodo solicitante Ni. Además, el servidor EA de inscripción valida la solicitud VR de validación, por ejemplo, enviando un mensaje VM de validación al servidor AA de autorización en la etapa 16" en respuesta a la solicitud VR de validación, cuando se ha pasado la verificación 13 de validez. Cuando, por otro lado, no se haya superado la verificación 13 de validez, el servidor EA de inscripción no incrementa el contador CTm y no valida la solicitud VR de validación, por ejemplo, no enviando un mensaje al servidor AA de autorización en respuesta a la solicitud VR de validación (implícitamente), o enviando un mensaje que sea diferente del mensaje VM de validación al servidor AA de autorización en respuesta a la solicitud VR de validación (explícitamente).
Cuando el servidor AA de autorización recibe el mensaje VM de validación en respuesta a la solicitud VR de validación, es decir, cuando la solicitud VR de validación fue validada por el servidor Ea de inscripción, el servidor AA de autorización genera y emite un ticket ATn de autorización seudónimo al nodo solicitante Ni en la etapa 17. En una etapa opcional 18, el servidor AA de autorización almacena el mensaje VM de validación recibido en una base de datos 19 del mismo para una posterior verificación de plausibilidad y/o resolución de disputas.
Cabe señalar que el nodo solicitante Ni se identifica a sí mismo frente al servidor AA de autorización para la direccionabilidad, por ejemplo, por medio de un identificador de una sola vez o similar como se conoce en la técnica, de modo que la verdadera identidad del nodo Ni permanece sin revelar al servidor AA de autorización.
Después de haber recibido el ticket ATn de autorización emitido desde el servidor AA de autorización, el nodo solicitante Ni puede utilizar el ticket ATn de autorización una o varias veces para firmar y por lo tanto pseudoanonimizar mensajes M1, M2 , ..., Mk que el nodo Ni envía a otros nodos Ni 1, Ni 2 , ..., ver etapas 20 a 22.
Hasta que expire un período CP de facturación predeterminado, se repiten (flecha 23) dichos envío y recepción de solicitudes TR de ticket, solicitudes VR de validación y mensajes VM de validación y dicha emisión de tickets AT n de autorización . Una vez transcurrido el período CP de facturación, el servidor EA de inscripción envía un mensaje ME al servidor AA de autorización (etapa 24), mensaje ME que contiene el valor CV de contador del contador CTm asignado a dicha cuenta ACm y un identificador Ia c de la cuenta ACm en el servidor AS de cuentas. Se entiende que, cuando el SIT 1 tiene más de un servidor AS de cuentas, el servidor AS de cuentas que guarda dicha cuenta ACm también está indicado por el identificador Ia c .
Como el SIT 1 comprende una multiplicidad de nodos Ni, dicho mensaje ME contiene, en una realización, los valores CV de contador de algunos o todos los contadores CTm asignados respectivamente a las cuentas ACm de algunos o todos los nodos solicitantes Ni, y el identificador respectivo Ia c ; en una realización alternativa, el servidor EA de inscripción envía un mensaje ME separado para cada valor CV de contador y cuenta ACm a la que el contador CTm respectivo está asignado. Opcionalmente, el servidor EA de inscripción firma digitalmente el mensaje ME antes de enviarlo. Después de enviar dicho mensaje ME, el valor CV de contador de cada contador CT m en el servidor EA de inscripción se restablece opcionalmente para un período CP de facturación posterior.
En la etapa 25, el servidor AA de autorización calcula, a partir de cada valor CV de contador recibido, por ejemplo, por medio de un multiplicador acordado, una solicitud CR de cobro respectiva para la cuenta ACm identificada por el identificador recibido Ia c . Luego, el servidor AA de autorización envía la solicitud CR de cobro al servidor As de cuentas para realizar el cobro en cada una de dichas cuentas ACm. Por lo tanto, la emisión de tickets ATn de autorización está cobrada.
Cabe señalar que la comunicación entre nodos Ni, el servidor AA de autorización, el servidor EA de inscripción, el operador/fabricante OM y/o el servidor AS de cuentas está opcionalmente encriptada mediante claves adicionales de un esquema de encriptación simétrico o asimétrico como se conoce en la técnica. Por tanto, la materia objeto descrita no está restringida a las realizaciones específicas descritas en detalle en la presente memoria, sino que abarca todas las variantes, combinaciones y modificaciones de las mismas que caigan dentro del marco de las reivindicaciones adjuntas.

Claims (5)

REIVINDICACIONES
1. Un método para emitir tickets (ATn) de autorización seudónimos a los nodos (N¡) de un sistema inteligente SIT (1) de transporte cooperativo, , nodos (Ni) que intercambian mensajes (Mk), cada uno de los cuales está firmado con uno de dichos tickets (ATn) de autorización, comprendiendo el método:
a) recibir una solicitud (TR) de ticket de un nodo (Ni) en un servidor (AA) de autorización del SIT (1), solicitud (TR) de ticket que contiene las credenciales (EC) de inscripción del nodo solicitante (Ni), en donde las credenciales (EC) de inscripción están encriptadas con una clave pública (Kpu) de un servidor (EA) de inscripción del SIT (1), y enviar (12) una solicitud (VR) de validación que contenga las credenciales (EC) de inscripción del nodo solicitante al servidor (EA) de inscripción;
b) desencriptar las credenciales (EC) de inscripción contenidas en la solicitud (VR) de validación con una clave privada respectiva (Kpr) en el servidor (EA) de inscripción, realizar una verificación (13) de validez que solo se pasa cuando tanto el nodo solicitante (Ni) identificado por las credenciales (EC) de inscripción desencriptadas como, para el nodo solicitante (Ni), una cuenta (ACm) en un servidor (AS) de cuentas están inscritos con el servidor (EA) de inscripción y, en caso de que se apruebe la verificación (13) de validez, incrementar un valor (CV) de contador de un contador (CTm) asignado a dicha cuenta (ACm) y enviar (16) un mensaje (VM) de validación al servidor (AA) de autorización;
c) emitir (17), cuando se recibe el mensaje (VM) de validación en el servidor (AA) de autorización , un ticket (AT n) de autorización seudónimo al nodo solicitante (Ni);
d) repetir las etapas a) a c) hasta que expire un período (CP) de facturación predeterminado y, al expirar, enviar (21), desde el servidor (EA) de inscripción al servidor (AA) de autorización, un mensaje (ME) que contenga dicho valor (CV) de contador y un identificador (Ia c ) para dicha cuenta (ACm),
calcular, a partir del valor (CV) de contador recibido en el servidor (AS) de autorización, una solicitud (CR) de cobro para la cuenta (ACm) identificada por el identificador recibido (Ia c ), y enviar (22) la solicitud (CR) de cobro al servidor (AS) de cuentas para realizar el cobro en dicha cuenta (ACm).
2. El método según la reivindicación 1, en donde la cuenta (ACm) en el servidor (AS) de cuentas está inscrita con el servidor (EA) de inscripción para más de un nodo (Ni).
3. El método según la reivindicación 1, en donde la cuenta (ACm) en el servidor (AS) de cuentas está inscrita con el servidor (EA) de inscripción para un solo nodo (Ni).
4. El método según cualquiera de las reivindicaciones 1 a 3, en donde la etapa c) comprende además almacenar el mensaje (VM) de validación recibido en una base de datos (19) del servidor (Aa ) de autorización.
5. El método según cualquiera de las reivindicaciones 1 a 4, en donde el mensaje (ME) que contiene el valor (CV) de contador y el identificador (Ia c ) para la cuenta (ACm) se firma digitalmente por el servidor (EA) de inscripción antes de su envío.
ES19153722T 2019-01-25 2019-01-25 Método para emitir tickets de autorización en un sistema inteligente de transporte Active ES2866966T3 (es)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
EP19153722.4A EP3687201B1 (en) 2019-01-25 2019-01-25 Method for issuing authorisation tickets in an intelligent transport system

Publications (1)

Publication Number Publication Date
ES2866966T3 true ES2866966T3 (es) 2021-10-20

Family

ID=65268736

Family Applications (1)

Application Number Title Priority Date Filing Date
ES19153722T Active ES2866966T3 (es) 2019-01-25 2019-01-25 Método para emitir tickets de autorización en un sistema inteligente de transporte

Country Status (4)

Country Link
US (1) US11580506B2 (es)
EP (1) EP3687201B1 (es)
CA (1) CA3067085A1 (es)
ES (1) ES2866966T3 (es)

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1840779B1 (en) * 2006-03-31 2013-03-20 Irdeto Access B.V. Method and device for authorising conditional access
US8650392B2 (en) * 2010-05-21 2014-02-11 Microsoft Corporation Ticket authorization
ES2627976T3 (es) * 2013-04-19 2017-08-01 Kapsch Trafficcom Ag Procedimiento para la carga de una unidad de a bordo con un tique electrónico
US10853592B2 (en) * 2015-02-13 2020-12-01 Yoti Holding Limited Digital identity system
US9785764B2 (en) * 2015-02-13 2017-10-10 Yoti Ltd Digital identity
CN107369218B (zh) * 2017-07-21 2019-02-22 北京图森未来科技有限公司 实现车辆自动缴费的方法及系统、相关设备

Also Published As

Publication number Publication date
EP3687201B1 (en) 2021-03-03
US20200242572A1 (en) 2020-07-30
CA3067085A1 (en) 2020-07-25
EP3687201A1 (en) 2020-07-29
US11580506B2 (en) 2023-02-14

Similar Documents

Publication Publication Date Title
CN109451467B (zh) 一种基于区块链技术的车载自组织网络数据安全共享与存储系统
Zheng et al. A traceable blockchain-based access authentication system with privacy preservation in VANETs
CN107040368B (zh) 用于车辆的受保护的通信的方法
CN113114630B (zh) 一种电动汽车动态无线充电隐私保护的认证方法及系统
US20160112206A1 (en) System and Method for Vehicle Messaging Using a Public Key Infrastructure
US20150256347A1 (en) Apparatuses and methods for certificate generation, certificate revocation and certificate verification
CN109788482A (zh) 一种车联网环境下车辆间的消息匿名认证方法及系统
Terzi et al. Securing emission data of smart vehicles with blockchain and self-sovereign identities
US10706137B2 (en) Apparatus and method for using a customer device certificate on a device
EP2003813A1 (en) Method and Apparatus for Authentication
CN109660485A (zh) 一种基于区块链交易的权限控制方法及系统
CN101378315B (zh) 认证报文的方法、系统、设备和服务器
Wang et al. Secure ride-sharing services based on a consortium blockchain
CN106327184A (zh) 一种基于安全硬件隔离的移动智能终端支付系统及方法
CN103490881A (zh) 认证服务系统、用户认证方法、认证信息处理方法及系统
CN111163109B (zh) 区块链去中心式节点防仿冒方法
JPWO2018021535A1 (ja) システム、データ管理方法及びプログラム
CN111277978A (zh) 基于秘密共享和联盟链的车联网系统及方法
Benarous et al. Privacy‐preserving authentication scheme for on‐road on‐demand refilling of pseudonym in VANET
Cahyadi et al. A certificateless aggregate signature scheme for security and privacy protection in VANET
Zhang et al. A secure and efficient decentralized access control scheme based on blockchain for vehicular social networks
CN108933665A (zh) 轻量级V2I组通信身份验证协议应用在VANETs中的方法
EP1912147A1 (en) Method and apparatus for selling a digital resource
Chen et al. IOV privacy protection system based on double-layered chains
ES2866966T3 (es) Método para emitir tickets de autorización en un sistema inteligente de transporte