EP3265344A1 - Procédé d'inscription d'un utilisateur à un service de commande d'une fonctionnalité d'un véhicule au moyen d'un terminal utilisateur - Google Patents

Procédé d'inscription d'un utilisateur à un service de commande d'une fonctionnalité d'un véhicule au moyen d'un terminal utilisateur

Info

Publication number
EP3265344A1
EP3265344A1 EP15823702.4A EP15823702A EP3265344A1 EP 3265344 A1 EP3265344 A1 EP 3265344A1 EP 15823702 A EP15823702 A EP 15823702A EP 3265344 A1 EP3265344 A1 EP 3265344A1
Authority
EP
European Patent Office
Prior art keywords
vehicle
server
user
identifier
terminal
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.)
Withdrawn
Application number
EP15823702.4A
Other languages
German (de)
English (en)
Inventor
Eric Menard
Bruno Benteo
Fabienne Masson
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.)
Valeo Comfort and Driving Assistance SAS
Original Assignee
Valeo Comfort and Driving Assistance SAS
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 Valeo Comfort and Driving Assistance SAS filed Critical Valeo Comfort and Driving Assistance SAS
Publication of EP3265344A1 publication Critical patent/EP3265344A1/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • 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
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • G06Q30/0601—Electronic shopping [e-shopping]
    • G06Q30/0609—Qualifying participants for shopping transactions
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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
    • G06F21/35—User authentication involving the use of external additional devices, e.g. dongles or smart cards communicating wirelessly
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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/44—Program or device authentication
    • 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/0869—Network architectures or network communication protocols for network security for authentication of entities for achieving mutual authentication
    • 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/006—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols involving public key infrastructure [PKI] trust models
    • 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
    • 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/3271—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 using challenge-response
    • H04L9/3273—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 using challenge-response for mutual authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/04—Key management, e.g. using generic bootstrapping architecture [GBA]
    • H04W12/041—Key generation or derivation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60R—VEHICLES, VEHICLE FITTINGS, OR VEHICLE PARTS, NOT OTHERWISE PROVIDED FOR
    • B60R25/00—Fittings or systems for preventing or indicating unauthorised use or theft of vehicles
    • B60R25/20—Means to switch the anti-theft system on or off
    • B60R25/24—Means to switch the anti-theft system on or off using electronic identifiers containing a code not memorised by the user
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2103—Challenge-response
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2117—User registration
    • 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/84—Vehicles
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/18—Processing of user or subscriber data, e.g. subscribed services, user preferences or user profiles; Transfer of user or subscriber data

Definitions

  • Method of registering a user with a service of ordering a functionality of a vehicle by means of a user terminal
  • the present invention relates to the control of functionalities of a vehicle by means of a user terminal, such as a mobile phone.
  • the invention is particularly advantageous in the case where this feature is the unlocking of the vehicle doors.
  • a virtual key stored in the user terminal is used and an electronic control unit of the vehicle checks the validity before controlling the unlocking of the doors.
  • Such virtual keys are distributed only to those who have subscribed to a functionality control service by means of the user terminal.
  • the present invention proposes a method for registering a user with a service for controlling at least one feature of a vehicle by means of a user terminal, characterized in that it comprises the following steps :
  • Registration of the vehicle to the service, in association with the identifier user is thus achieved only when an electronic unit of the vehicle designated by the communicated identifier has authenticated with the server.
  • the authentication comprises a step of use by the server of a cryptographic key stored in association with a reference of the electronic unit;
  • authentication comprises data exchanges between the server and the electronic unit via the user terminal;
  • the authentication step is part of a mutual authentication process between the server and the electronic control unit;
  • the registration method comprises a step of detecting a user action on a physical object related to the vehicle;
  • the detection step is implemented only in the case of successful authentication
  • the registration method comprises, in the event of successful detection, a step of transmission by the electronic unit of a service launch message to the server, said registration being carried out by the server upon receipt of the launch message. service;
  • the method comprises, following said registration, a step of transmitting a virtual key to the terminal;
  • the physical object is a physical key able to control the unlocking of the vehicle doors
  • the physical object is a manual control of the vehicle
  • the identifier of the user is an identifier of the user terminal
  • the method further comprises, in the event of successful authentication, a step of initializing a counter within the server and within the electronic unit;
  • the counter is initialized at the initialization step with an initialization value stored within the server and within the electronic unit;
  • the counter is incremented periodically with a period stored within the server and within the electronic unit;
  • the communication step is performed by transmission, for example by means of the user terminal, of the identifier of the user and the identifier associated with the vehicle;
  • the communication step is performed by entering, at the server, the identifier of the user and the identifier associated with the vehicle.
  • the registration process may further include the steps of:
  • the functionality is for example the unlocking or locking of the vehicle doors, or the locking or unlocking of the trunk of the vehicle, or the locking or unlocking of the glove box of the vehicle, or the start or stop of the engine of the vehicle. vehicle.
  • FIG. 1 represents an exemplary context in which the invention may be implemented, notably comprising a vehicle and a user terminal;
  • FIG. 2 schematically shows components useful for understanding the invention, the vehicle and the user terminal of Figure 1;
  • FIG. 3 shows the main steps of a method of registration with a service of control of functionalities of the vehicle by means of the user terminal;
  • FIG. 4 presents the main steps of an exemplary method of controlling a vehicle functionality by means of the user terminal.
  • FIG. 5 shows the main steps of another exemplary method of registration with a service of control of functionalities of the vehicle by means of the user terminal.
  • FIG. 1 represents an example of context in which the invention can be implemented.
  • a vehicle 10 comprises an electronic control unit 11 (or ECU for "Electronic Control Unit") which can communicate via a wireless link with a user terminal 20, for example a mobile phone (or cell phone ), possibly of "smart phone” or “smartphone” type according to the commonly used English name, in order to exchange data with this user terminal 20, for example with a view to controlling the functionalities of the vehicle 10 by means of the terminal user 20 (such a feature can be for example the unlocking of the doors of the vehicle 10), as explained below.
  • ECU Electronic Control Unit
  • the wireless link used to communicate between the electronic control unit 1 1 and the user terminal 20 is for example of the Bluetooth type.
  • the user terminal 20 is furthermore designed to connect to a mobile telephone network 30 which notably comprises a base station 32 in communication via a radio link with the user terminal 20 and a gateway 34 for connection to a public network 40, for example. example the Internet network.
  • a mobile telephone network 30 which notably comprises a base station 32 in communication via a radio link with the user terminal 20 and a gateway 34 for connection to a public network 40, for example. example the Internet network.
  • a server 50 is also connected to the public network 40 so that the user terminal 20 and the server 50 can communicate and exchange data via the mobile telephone network 30 and the public network 40.
  • the server 50 is here managed by the manufacturer of the electronic control unit 1 1.
  • FIG. 2 diagrammatically represents components useful for understanding the invention, the vehicle 10 and the user terminal 20.
  • the vehicle 10 comprises in particular the electronic control unit
  • an actuator 15 here designed to allow the unlocking of vehicle doors 10
  • an actuator 17 designed to allow the vehicle to start
  • a wireless communication module 16 and a user interface 18.
  • An identification number VID is assigned to the vehicle 10 and a serial number N is assigned to the electronic control unit 11.
  • the association between the identification number VID of a vehicle 10 and the serial number N of the electronic control unit 11 which equips this vehicle 10 is stored in a database D managed by the server 50 (which can be the constructor of the vehicle 10 or a supplier).
  • the electronic control unit comprises a processor 12 and a storage unit 14, for example a rewritable non-volatile memory or a hard disk.
  • the storage unit 14 stores in particular computer programs comprising instructions whose execution by the processor 12 allows the implementation by the electronic control unit 11 of the processes described below.
  • the storage unit 14 also stores data used in the context of the methods described below, in particular a cryptographic key PrK (for example a private key) and a root key (or master key) MK, used as explained in the following. .
  • PrK for example a private key
  • MK root key
  • the cryptographic key PrK and / or the root key MK are for example written in the storage unit 14 during the manufacture of the electronic control unit 1 1, before mounting of this electronic control unit 1 1 in the vehicle 10 .
  • the cryptographic key PrK and the root key MK are also stored at the server 50 (which is recalled that it is managed by the manufacturer of the electronic control unit 1 1), in association with the serial number N of the electronic control unit 1 1.
  • the storage unit 14 also stores construction information of a diversified counter, for example an initial value I of the counter and a duration of step P. This information can also be written in the storage unit 14 during the manufacture of the electronic control unit 1 1, before mounting this electronic control unit 1 1 in the vehicle 10, and stored elsewhere at the server 50, in association with the number N series of the electronic control unit 1 1.
  • This counter is diversified in the sense that the construction information of the counter (here the initial value I and the duration of the pitch P) differ from one electronic control unit to another, and therefore from one vehicle to another .
  • each electronic control unit (and therefore each vehicle) stores counter construction information of its own.
  • the server S thus memorizes, as already indicated, this construction information counter in combination with each electronic control unit serial number.
  • the user terminal 20 comprises a processor 22, a memory 24 (for example a non-volatile memory rewritable), a wireless communication module 26 and a communication module 28 on the mobile telephone network 30.
  • the wireless communication module 26 of the user terminal 20 makes it possible to establish a wireless link (here of the Bluetooth type as already indicated) with the wireless communication module 16 of the vehicle 10 through which the processor 12 of the electronic unit control 1 1 and the processor 22 of the user terminal 20 can exchange data, especially as explained below.
  • the communication module 28 allows the user terminal 20 (and specifically the processor 22 equipping this user terminal 20) to exchange, as already indicated, data with other devices connected to the mobile telephone network 30 or the public network 40, particularly with the server 50.
  • the communication module may comprise a smart card that stores connection data associated with a subscription to the mobile telephone service and making it possible to establish the connection on the mobile telephone network 30.
  • FIG. 3 shows the main steps of a registration (or enrollment) process to a vehicle function control service 10 by means of the user terminal 20.
  • the user terminal 20 is not specifically prepared for controlling the functionalities of the vehicle 10 and does not include any data associated with the vehicle 10. It may therefore be for example the mobile phone commonly used by the vehicle owner 10.
  • the user terminal 20 is unknown to the vehicle 10 which is therefore not aware of any data associated with this user terminal 20.
  • a user U (according to one embodiment: the owner of the vehicle 10; in another embodiment, a person in charge of putting into operation the vehicle 10) has access to the vehicle 10 (also referenced V in FIG. 3) by conventional means (for example a physical key).
  • the user U carries and uses the user terminal 20 which, as described above, is in communication on the one hand with the electronic control unit 1 1 via a wireless link (for example). example of the Bluetooth type) and secondly with the server 50 (referenced S in FIG. 3) via a radio link to the base station 31, then via the mobile telephone network 30 and the public network 40.
  • a wireless link for example. example of the Bluetooth type
  • the server 50 referenced S in FIG. 3
  • the user terminal 20 can thus be used, in the embodiment described here, as a gateway allowing a data exchange between the vehicle V (specifically the electronic control unit 11) and the server S, as described hereinabove. after.
  • a communication module (sometimes called the "Telematic Control Unit") fitted to the vehicle. V and designed to establish a (direct) communication between the vehicle V and the mobile telephone network 30.
  • the method of FIG. 3 starts at the step E2 to which the user U communicates to the server S (referenced 50 in FIG. 1) a user ID UID and a identifier VID of the vehicle V (referenced 10 in FIG. 1).
  • the user U connects to do this to the server S (for example by entering the http address of the server S in a browser executed by the processor 22 of the user terminal 20) and for example captures the identifiers aforementioned UID, VID in a form then transmitted to the server S.
  • an application previously installed on the user terminal 20 asks the user U to enter the identifiers and transmits them to the server 50.
  • the user ID UID and the identifier VID of the vehicle V may have been previously entered at the server S, for example when the vehicle V was purchased.
  • the user ID UID includes, for example, the last name and first name (s) of the user, as well as possibly his date of birth.
  • the user identifier could be an email address, a number of telephone (for example, the number assigned to the mobile phone service subscription, such as a MSISDN number) or a U user user terminal identifier (such as an IMEI number).
  • the VID identifier of the vehicle is for example of the "Vehicle Identification Numbei" type. However, it would be possible alternatively to use another identifier associated with the vehicle 10, in particular the serial number N of the electronic control unit 11 of the vehicle 10.
  • the server S receives the user identifier U and the vehicle identifier VID in the step E4 and stores these identifiers, at this stage in a zone dedicated to the vehicles for which the registration to the service of control of functionalities of the vehicle by means of the user terminal is in progress.
  • the serial number N of the electronic control unit 11 is for example communicated by the user U to the server S, for example during the step E2. To do this, the serial number N is provided in advance to the user: it is for example printed on a label stuck in the user manual of the vehicle and / or accessible by the user through the user interface. 18.
  • the server S can thus determine in step E10 the cryptographic key PrK stored (as described above) in association with this serial number N.
  • the server S then generates a challenge (in English "challenge"), for example random number RND (step E12).
  • the server S can thus emit at step E16 the challenge RND and a part of the response RESP, here a low weight word LSB (for "Least Significant Byte”) forming part of the response RESP, to the vehicle V, precisely of the electronic control unit 1 1.
  • LSB for "Least Significant Byte”
  • the server S (referenced 50 in FIG. 1) communicates here with the electronic control unit 11 via the user terminal 20.
  • the electronic control unit 1 1 then verifies in step E20 that the LSB 'part (corresponding to the part of the RESP response received, here the least significant word) of the response RESP' calculated in step E18 is well equal to the LSB response part received from the server S.
  • step E21 terminates the registration process. Indeed, this means that the cryptographic key used in the calculation of step E14 differs from that used in the calculation of step E18 and that an error has therefore occurred (for example because of the sending of an erroneous vehicle identifier in step E2). An error message can then for example be displayed on the user interface 18 of the vehicle V.
  • step E22 another part of the response RESP 'calculated in step E18, here a most significant word MSB' (for "Most Significant Byte "), to the server S.
  • the server S receives this other part MSB 'of the response RESP' and verifies in the step E24 that the part MSB (corresponding to the part MSB 'of the response RESP' received, here the most significant word) of the response RESP calculated in step E14 is equal to the response part MSB 'received from the electronic control unit 11.
  • step E25 terminates the registration processor. Indeed, this means that the partner of the server S in the communication was not able to calculate the expected response, presumably because the partner is not the expected vehicle and therefore does not hold the cryptographic key PrK.
  • the server S then triggers the continuation of the registration process by sending to the electronic control unit 1 1 a command CMD for checking the presence of the user U in the vehicle V (step E26).
  • the electronic control unit 1 1 control in step E28 the generation by the user interface 18 of an indication requesting the user U to perform one or more action (s) ACT.
  • This indication may be a visual indication (for example a light signal or a display on a screen of the user interface 18) and / or sound (for example a particular sound or a voice message).
  • the requested action (s) can understand the use of the physical key (for example, the support, possibly simultaneous, on one or more buttons of the physical key, or the start and / or the stopping the engine with the physical key) and / or an action of the user U on the vehicle V, for example pressing a button of the user interface 18, opening and / or closing of the door, and / or starting and / or stopping the engine.
  • the user performs the ACT action (s) requested at step
  • the electronic control unit 1 1 detects in step E32 whether the action performed by the user U corresponds to the requested action ACT (leaving for example a predetermined duration to the user to perform the action) .
  • the electronic control unit 1 1 proceeds to the step E34 which ends to the registration process.
  • An error message may further be displayed on the user interface 18 of the vehicle V.
  • a single-use code can be sent by the server 50, to the user terminal 20, via the public network 40, for example during the execution of the application allowing, in certain embodiments, the seizure identifiers in step E2, as indicated above.
  • the one-time code could be transmitted (eg as a short message or SMS, for "Short Message System") to the user terminal 20 using the telephone number (MSISDN number) associated with the subscription used by the user terminal 20, in particular when this number forms the user identifier, as also envisaged above.
  • the server 50 is designed to transmit data over the telephone network.
  • the counter is initialized to the initial value I and incremented periodically with the period P (step E36).
  • the counter is reset during an incrementation resulting in an overflow (or "overflow" according to the English name sometimes used) of the maximum value (determined by the number of bits). counter).
  • the electronic control unit 1 1 also sends to the server S a message indicating that the presence of the user has been detected (by the ACT actions that he has performed at the request of the electronic control unit 1 1) and that the service can be started (step E38).
  • the server S receives this message and, in the case where a counter is used, also starts the counter within it (step E40), in association with the vehicle identifier VID and on the basis of the construction information stored in association with the serial number N of the electronic control unit 1 1, here the initial value I and the incrementation period P of the counter.
  • the counter therefore evolves in parallel within the control unit 1 1 and within the server S, possibly with a very small offset between the counter stored in the control electronic unit 1 1 and the counter stored in the server 50 (Due in particular to the short time between steps E36 and E40), which is however not detrimental.
  • the server S can then decide on the definitive registration of the user U to the service and memorizes to do this in combination, in a storage area of the subscribers of the service, the user identifier UID, the vehicle identifier VID and, in the case where a counter is used, the current value of the counter (which will be incremented periodically with the period P), and possibly the serial number N (step E42).
  • the user ID UID and the vehicle identifier VID stored in association can be considered as an electronic certificate of ownership of the vehicle for the proposed service.
  • the server S can then communicate to the user U rights of access to the control service of the functionalities of the vehicle, for example by transmitting to the user terminal 20 a virtual key VK authorizing the user terminal 20 to control these functionalities (eg the opening the vehicle doors), as in the examples presented below.
  • the virtual key VK is stored in the user terminal 20 (step E44).
  • the virtual key VK can be transmitted from the server 50 to an application previously downloaded into the memory 24 of the user terminal 20 and executable by the processor 22 of the user terminal 20, for example the application allowing the implementation of the step E2 as envisaged above.
  • the virtual key VK could be transmitted to the user terminal 20 by using the telephone number (MSISDN number) associated with the subscription used by the user terminal 20, in particular when this number forms the user identifier, as is also envisaged. above.
  • FIG. 4 shows the main steps of an exemplary method of controlling a function of the vehicle V (referenced 10 in FIG. 1) by means of the user terminal T (of the type of that referenced in FIG. 1).
  • control method described here is particularly well suited to the case where the vehicle V is rented to a user for a predefined period of time.
  • a temporary virtual key VK is used, derived taking into account the value NB1 of the counter (installed in parallel in the control unit 1 1 of the vehicle V and in the server S as indicated above) at the beginning. the rental period and the NB2 value of the meter at the end of the rental period.
  • the server S receives for example from the vehicle renter the vehicle identifier VID, the rental start time and the end time of rental and determines, on the basis of the construction information of counter read in the storage unit 14, the value NB1 of the counter set up in the electronic control unit 1 1 concerned (whose number of N series is associated with the vehicle identifier VID received, for example following the method of Figure 3) and corresponding to the rental start time, and NB2 value of this counter corresponding to the end of rental time.
  • the server S then transmits the virtual key VK and the values NB1, NB2 to the usual terminal T (for example a mobile phone) of the user (renter of the vehicle), for example after a verification step that this usual terminal T is well. eligible for service (based on a terminal identifier, such as an IMEI number, and / or a subscriber number associated with the terminal, such as a MSISDN number); the virtual key VK and the values NB1, NB2 are then stored within the terminal T. (Note that the terminal T used here is therefore not generally the one used in the context of FIG.
  • the terminal T issues in step E102 a request for implementation of the functionality, accompanied by the start value NB1 and the end value NB2, to the control electronic unit 1 1 of the vehicle V (step E102).
  • the electronic control unit 1 1 checks in step E104 that the current value of the counter which it implements is indeed between the value NB1 and the value NB2 (which means, according to the construction described here above NB1 and NB2 values, that the current time is included in the rental period).
  • step E106 the electronic control unit 11 terminates the process in step E106 without performing the required functionality (i.e., without unlocking the vehicle doors V).
  • a failure message may possibly be transmitted to the terminal T for display on the terminal T of a corresponding indication.
  • the electronic control unit 1 1 then generates in step E1 10 a challenge, for example a random number RND ', and issues this challenge to the user terminal T.
  • a challenge for example a random number RND '
  • the user terminal T receives this challenge in step E1 12.
  • Other data may possibly be used in the calculations performed at this step, for example the vehicle identifier VID.
  • the user terminal T transmits the expected response R (calculated in step E1 14) to the electronic control unit 11 (step E1 16).
  • the electronic control unit 1 1 then checks in step E1 18 that the response R received from the user terminal T is equal to the expected response R ', to which the electronic control unit 11 can consider that the user terminal T holds the virtual key VK which gives a right of access to the vehicle.
  • step E1 18 If the verification at step E1 18 fails (which is not the case in the normal operation described above, but may be the case when a malicious person tries to access the vehicle without knowing the virtual key VK), the electronic control unit 120 terminates the method in step E120 without performing the required functionality (that is to say here without unlocking the doors of the vehicle V).
  • a failure message may possibly be transmitted to the terminal T for display on the terminal T of a corresponding indication.
  • step E122 is carried out at which the unit electronic control performs the requested functionality, here the unlocking of the doors of the vehicle, by issuing a corresponding command to the actuator 15 (or, in the case of starting the vehicle, to the actuator 17).
  • a temporary virtual key VK is used, particularly suitable for renting vehicles.
  • step E102 it is possible to use a fixed virtual key VK, for example stored in the storage unit 14 instead of the root key MK.
  • the user terminal where the virtual key VK is stored may in this case be the user terminal used in the method of FIG. 3.
  • the counter mentioned above may possibly not be used, in which case the steps E36, E40 and E104 to E108 are omitted, and step E102 consists of a simple request to implement the functionality, without appended counter values.
  • FIG. 5 shows the main steps of another exemplary method of registering a vehicle function control service 10 by means of the user terminal 20.
  • step E200 the user U (usually the owner of the vehicle V) communicates the serial number N of the electronic control unit 1 1 and its UID identifier (for example an identifier of the terminal user 20, such as the IMEI number or the associated subscriber number MSISDN) to the server S.
  • the user U usually the owner of the vehicle V
  • the serial number N of the electronic control unit 1 1 and its UID identifier for example an identifier of the terminal user 20, such as the IMEI number or the associated subscriber number MSISDN
  • serial number N is used as the identifier associated with the vehicle 10.
  • the user U connects for example to a website associated with the server S and can then enter the information N, UID in a form subsequently transmitted to the server S.
  • These operations can possibly be carried out using of the terminal 20, but also by means of a personal computer of the user U.
  • the server S receives the information N, UID in the step E202 and stores them, for example in a storage area dedicated to the vehicles for which the registration with the service of control of functionalities of the vehicle by means of the user terminal is in Classes.
  • this information N, UID could be entered at the level of the server S at the time of the purchase of the vehicle V (the user U then providing the information concerning him to the organization managing the server S).
  • the server S then prepares in step E204 an APP application intended for the terminal 20 and which contains a specific message MSG (designed to be read only by the electronic control unit 11 whose serial number N has been received at the terminal. step E202) and a derivation key K specific to the APP application.
  • the server S notably stores the derivation key K in association with the previously stored information N, UID.
  • the server S for example transmits an https link to the terminal 20 (for example by using the subscriber number MSISDN supplied at the step E200 as an identifier UID, or provided at the step E200 in addition to the identifier UID), link then used by the user U to perform the download of the APP application on the terminal T.
  • step E208 (which may be separated from step E206 by a longer or shorter time), the user U starts the execution of the APP application on the terminal T.
  • the APP application After a phase of initialization of the wireless link between the wireless communication module 16 of the vehicle V and the wireless communication module 26 of the terminal T, the APP application causes the transmission of the specific message MSG to the terminal. electronic control unit 1 1 of the vehicle V.
  • the specific message MSG is received in step E210 by the electronic control unit 11, which verifies that this specific message MSG is intended for it. If this verification is not done correctly, the registration process is terminated.
  • the electronic control unit 11 sends in step E210 an authentication request to the server S, accompanied by example of its serial number N (or another identifier of the electronic control unit 1 1).
  • a request is, for example, transmitted from the electronic control unit 11 to the server S via the terminal T (as already explained with regard to the embodiment of FIG. 3).
  • the APP application embeds, for example, an IP address of the server 50 and transmits to this address the response it receives from the electronic control unit 11.
  • this request could be transmitted by means of a vehicle communication module V.
  • the server S receives the authentication request and the serial number N and then transmits in step E212 a challenge X to the terminal T (whose associated identifier or subscription number is stored as already indicated at the S server in association with the identifier associated with the vehicle, here the serial number N).
  • the derived data Y is transmitted from the terminal T to the electronic control unit 1 1 of the vehicle V via the wireless link established as indicated above in step E208.
  • the electronic control unit 1 1 sends the response Z calculated in step E216 to the server S, for example via the terminal T as indicated above (or alternatively by means of a communication module fitted to the vehicle V).
  • the server S receives the response Z and can thus verify in step E218 that this response Z is the expected response f (d (X, K), PrK). Indeed, the server S stores, in association with the serial number N of the electronic control unit 11, the cryptographic key PrK (as described above with reference to FIG. 2) and the derivation key K ( see above step E204); the server S is also aware of the challenge X that it issued in step E212. If the response Z received from the electronic control unit 11 does not correspond to the expected response f (d (X, K), PrK), the registration process is terminated.
  • the terminal T and the electronic control unit 1 1 of the vehicle V which each participated in the production of the response Z (each using information specific to them), are those respectively associated with the user U (identified by his UID identifier) and with the vehicle V (identified here by the serial number N): the server S has thus been able to authenticate the terminal T and the electronic control unit 1 1.
  • the server S decides on the definitive enrollment of the user U in the service control service of the vehicle V by means of the terminal T and stored for this purpose in step E220, in a storage area of the subscribers of the service, in association with the user identifier UID (for example, as already indicated, an identifier associated with the terminal T) and the identifier associated with the vehicle (here the serial number N).
  • the server S can then communicate to the user U rights of access to the control service of the functionalities of the vehicle, for example by transmitting (step E222) to the terminal T a virtual key VK allowing the terminal T to control these functions, such as in the examples presented above.
  • the virtual key VK can thus be stored in the user terminal T (step E224).
  • the access rights are not transmitted immediately after the definitive registration, but subsequently, for example after transmission of an electronic message to the user U (to an electronic address entered for example). during the step E200) and confirmation of the activation of the service by the user U in response to this electronic message, for example by entering the terminal T of a code mentioned in the electronic message.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Business, Economics & Management (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computing Systems (AREA)
  • Finance (AREA)
  • Accounting & Taxation (AREA)
  • Software Systems (AREA)
  • General Business, Economics & Management (AREA)
  • Strategic Management (AREA)
  • Marketing (AREA)
  • Economics (AREA)
  • Development Economics (AREA)
  • Lock And Its Accessories (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Selective Calling Equipment (AREA)
  • Telephone Function (AREA)
  • Telephonic Communication Services (AREA)

Abstract

Un procédé d'inscription d'un utilisateur à un service de commande d'au moins une fonctionnalité d'un véhicule (10) au moyen d'un terminal utilisateur (20) comprend les étapes suivantes : - communication d'un identifiant de l'utilisateur et d'un identifiant associé au véhicule (10) à un serveur (50); - authentification d'une unité électronique (11) du véhicule (10) par le serveur (50); - en cas d'authentification réussie, inscription de l'identifiant de l'utilisateur et de l'identifiant associé au véhicule (10) en association au niveau du serveur (50).

Description

« Procédé d'inscription d'un utilisateur à un service de commande d'une fonctionnalité d'un véhicule au moyen d'un terminal utilisateur »
DOMAINE TECHNIQUE AUQUEL SE RAPPORTE L'INVENTION La présente invention concerne la commande de fonctionnalités d'un véhicule au moyen d'un terminal utilisateur, tel qu'un téléphone portable.
Elle concerne plus particulièrement un procédé d'inscription d'un utilisateur à un service de commande d'une fonctionnalité d'un véhicule au moyen d'un terminal utilisateur.
L'invention s'applique particulièrement avantageusement dans le cas où cette fonctionnalité est le déverrouillage des portes du véhicule.
ARRIERE-PLAN TECHNOLOGIQUE
On a proposé de commander certaines fonctionnalités d'un véhicule automobile, telles que le déverrouillage des portes du véhicule, au moyen d'un terminal utilisateur, par exemple un téléphone portable couramment, utilisé par l'utilisateur du véhicule.
Afin de ne permettre cette commande qu'aux personnes effectivement autorisées, on utilise une clé virtuelle mémorisée dans le terminal utilisateur et dont une unité électronique de commande du véhicule vérifie la validité avant de commander le déverrouillage des portes.
De telles clés virtuelles sont distribuées aux seules personnes ayant souscrit à un service de commande des fonctionnalités au moyen du terminal utilisateur.
OBJET DE L'INVENTION
Dans ce contexte, la présente invention propose un procédé d'inscription d'un utilisateur à un service de commande d'au moins une fonctionnalité d'un véhicule au moyen d'un terminal utilisateur, caractérisé en ce qu'il comprend les étapes suivantes :
- communication d'un identifiant de l'utilisateur et d'un identifiant associé au véhicule à un serveur ;
- authentification d'une unité électronique du véhicule par le serveur ;
- en cas d'authentification réussie, inscription de l'identifiant de l'utilisateur et de l'identifiant associé au véhicule en association au niveau du serveur.
L'inscription du véhicule au service, en association avec l'identifiant utilisateur (qui peut être par exemple un identifiant de son terminal utilisateur), n'est ainsi réalisée que lorsqu'une unité électronique du véhicule désigné par l'identifiant communiqué s'est authentifiée auprès du serveur.
D'autres caractéristiques optionnelles, et donc non limitatives, sont les suivantes :
- l'authentification comprend une étape d'utilisation par le serveur d'une clé cryptographique mémorisée en association avec une référence de l'unité électronique ;
- l'authentification comprend des échanges de données entre le serveur et l'unité électronique via le terminal utilisateur ;
- l'étape d'authentification fait partie d'un processus d'authentification mutuelle entre le serveur et l'unité électronique de commande ;
- le procédé d'inscription comprend une étape de détection d'une action de l'utilisateur sur un objet physique lié au véhicule ;
- l'inscription est conditionnée non seulement par l'authentification réussie, mais en outre par la détection précitée ;
- l'étape de détection est mise en œuvre seulement en cas d'authentification réussie ;
- le procédé d'inscription comprend, en cas de détection réussie, une étape d'émission par l'unité électronique d'un message de lancement du service à destination du serveur, ladite inscription étant effectuée par le serveur à réception du message de lancement du service ;
- le procédé comprend, suite à ladite inscription, une étape d'émission d'une clé virtuelle à destination du terminal ;
- l'objet physique est une clé physique apte à commander le déverrouillage des portes du véhicule ;
- l'objet physique est une commande manuelle du véhicule ;
- l'identifiant de l'utilisateur est un identifiant du terminal utilisateur ;
- le procédé comprend en outre, en cas d'authentification réussie, une étape d'initialisation d'un compteur au sein du serveur et au sein de l'unité électronique ;
- le compteur est initialisé à l'étape d'initialisation avec une valeur d'initialisation mémorisée au sein du serveur et au sein de l'unité électronique ;
- le compteur est incrémenté périodiquement avec une période mémorisée au sein du serveur et au sein de l'unité électronique ;
- l'étape de communication est réalisée par transmission, par exemple au moyen du terminal utilisateur, de l'identifiant de l'utilisateur et de l'identifiant associé au véhicule ;
- l'étape de communication est réalisée par saisie, au niveau du serveur, de l'identifiant de l'utilisateur et de l'identifiant associé au véhicule.
Le procédé d'inscription peut en outre comprendre les étapes suivantes :
- téléchargement, du serveur au terminal, d'une application (par exemple pré-personnalisée) contenant un message spécifique destiné à une entité électronique de commande correspondant à l'identifiant associé au véhicule ;
- transmission, du fait de l'exécution de l'application sur le terminal, du message spécifique à l'unité de commande du véhicule.
La fonctionnalité est par exemple le déverrouillage ou le verrouillage des portes du véhicule, ou le verrouillage ou déverrouillage du coffre du véhicule, ou bien le verrouillage ou déverrouillage de la boîte à gant du véhicule, ou encore le démarrage ou l'arrêt du moteur du véhicule.
DESCRIPTION DÉTAILLÉE D'UN EXEMPLE DE RÉALISATION La description qui va suivre en regard des dessins annexés, donnés à titre d'exemples non limitatifs, fera bien comprendre en quoi consiste l'invention et comment elle peut être réalisée.
Sur les dessins annexés :
- la figure 1 représente un exemple de contexte dans lequel peut-être mise en œuvre l'invention, comprenant notamment un véhicule et un terminal utilisateur ;
- la figure 2 représente schématiquement des composants, utiles à la compréhension de l'invention, du véhicule et du terminal utilisateur de la figure 1 ;
- la figure 3 présente les étapes principales d'un procédé d'inscription à un service de commande de fonctionnalités du véhicule au moyen du terminal utilisateur ;
- la figure 4 présente les étapes principales d'un exemple de procédé de commande d'une fonctionnalité du véhicule au moyen du terminal utilisateur ; et
- la figure 5 présente les étapes principales d'un autre exemple de procédé d'inscription à un service de commande de fonctionnalités du véhicule au moyen du terminal utilisateur. La figure 1 représente un exemple de contexte dans lequel peut être mise en œuvre l'invention.
Dans ce contexte, un véhicule 10 comprend une unité électronique de commande 1 1 (ou ECU pour "Electronic Control Unit") qui peut entrer en communication via une liaison sans fil avec un terminal utilisateur 20, par exemple un téléphone portable (ou téléphone cellulaire), éventuellement de type "téléphone intelligent' ou "smartphone" selon la dénomination anglo-saxonne couramment utilisée, afin d'échanger des données avec ce terminal utilisateur 20, par exemple en vue de la commande de fonctionnalités du véhicule 10 au moyen du terminal utilisateur 20 (une telle fonctionnalité pouvant être par exemple le déverrouillage des portes du véhicule 10), comme expliqué plus bas.
La liaison sans fil utilisée pour communiquer entre l'unité électronique de commande 1 1 et le terminal utilisateur 20 est par exemple de type Bluetooth.
Le terminal utilisateur 20 est par ailleurs conçu pour se connecter à un réseau de téléphonie mobile 30 qui comprend notamment une station de base 32 en communication via une liaison radio avec le terminal utilisateur 20 et une passerelle 34 de connexion à un réseau public 40, par exemple le réseau Internet.
Un serveur 50 est également connecté au réseau public 40 de sorte que le terminal utilisateur 20 et le serveur 50 peuvent entrer en communication et échanger des données via le réseau de téléphonie mobile 30 et le réseau public 40. Le serveur 50 est ici géré par le fabricant de l'unité électronique de commande 1 1 .
La figure 2 représente schématiquement des composants, utiles à la compréhension de l'invention, du véhicule 10 et du terminal utilisateur 20.
Le véhicule 10 comprend notamment l'unité électronique de commande
1 1 déjà mentionnée, un actionneur 15 (conçu ici pour permettre le déverrouillage des portes du véhicule 10), un actionneur 17 (conçu pour permettre le démarrage du véhicule), un module de communication sans fil 16 et une interface utilisateur 18.
Un numéro d'identification VID est attribué au véhicule 10 et un numéro de série N est attribué à l'unité électronique de commande 1 1 . L'association entre le numéro d'identification VID d'un véhicule 10 et le numéro de série N de l'unité électronique de commande 1 1 qui équipe ce véhicule 10 est conservée dans une base de données D gérée par le serveur 50 (qui peut être le constructeur du véhicule 10 ou un fournisseur).
L'unité électronique de commande comprend un processeur 12 et une unité de mémorisation 14, par exemple une mémoire non-volatile réinscriptible ou un disque dur.
L'unité de mémorisation 14 mémorise notamment des programmes d'ordinateur comprenant des instructions dont l'exécution par le processeur 12 permet la mise en œuvre par l'unité électronique de commande 1 1 des procédés décrits ci-dessous.
L'unité de mémorisation 14 mémorise également des données utilisées dans le cadre des procédés décrits ci-dessous, notamment une clé cryptographique PrK (par exemple une clé privée) et une clé racine (ou clé maître) MK, utilisées comme expliqué dans la suite.
La clé cryptographique PrK et/ou la clé racine MK sont par exemple écrites dans l'unité de mémorisation 14 lors de la fabrication de l'unité électronique de commande 1 1 , avant montage de cette unité électronique de commande 1 1 dans le véhicule 10.
La clé cryptographique PrK et la clé racine MK sont également mémorisées au niveau du serveur 50 (dont on rappelle qu'il est géré par le fabricant de l'unité électronique de commande 1 1 ), en association avec le numéro de série N de l'unité électronique de commande 1 1 .
Dans certaines applications décrites dans la suite, l'unité de mémorisation 14 mémorise en outre des informations de construction d'un compteur diversifié, par exemple une valeur initiale I du compteur et une durée de pas P. Ces informations peuvent elles aussi être écrites dans l'unité de mémorisation 14 lors de la fabrication de l'unité électronique de commande 1 1 , avant montage de cette unité électronique de commande 1 1 dans le véhicule 10, et mémorisées par ailleurs au niveau du serveur 50, en association avec le numéro de série N de l'unité électronique de commande 1 1 .
Ce compteur est diversifié dans le sens où les informations de construction du compteur (ici la valeur initiale I et la durée du pas P) diffèrent d'une unité électronique de commande à l'autre, et donc d'un véhicule à l'autre. Autrement dit, chaque unité électronique de commande (et donc chaque véhicule) mémorise des informations de construction du compteur qui lui sont propres. Le serveur S mémorise ainsi, comme déjà indiqué, ces informations de construction du compteur en association avec chaque numéro de série d'unité électronique de commande.
Le terminal utilisateur 20 comprend un processeur 22, une mémoire 24 (par exemple une mémoire non-volatile réinscriptible), un module de communication sans fil 26 et un module 28 de communication sur le réseau de téléphonie mobile 30.
Le module de communication sans fil 26 du terminal utilisateur 20 permet d'établir une liaison sans fil (ici de type Bluetooth comme déjà indiqué) avec le module de communication sans fil 16 du véhicule 10 à travers laquelle le processeur 12 de l'unité électronique de commande 1 1 et le processeur 22 du terminal utilisateur 20 peuvent échanger des données, notamment comme exposé plus loin.
Le module de communication 28 permet au terminal utilisateur 20 (et précisément au processeur 22 équipant ce terminal utilisateur 20) d'échanger comme déjà indiqué des données avec d'autres dispositifs connectés au réseau de téléphonie mobile 30 ou au réseau public 40, notamment avec le serveur 50. Dans certains modes de réalisation, le module de communication peut comprendre une carte à puce qui mémorise des données de connexion associées à un abonnement au service de téléphonie mobile et permettant d'établir la connexion sur le réseau de téléphonie mobile 30.
La figure 3 présente les étapes principales d'un procédé d'inscription (ou enrôlement) à un service de commande de fonctionnalités du véhicule 10 au moyen du terminal utilisateur 20.
On remarque qu'avant la mise en œuvre d'un tel procédé, le terminal utilisateur 20 n'est pas spécifiquement préparé pour la commande de fonctionnalités du véhicule 10 et ne comprend aucune donnée associée avec le véhicule 10. Il peut donc s'agir par exemple du téléphone portable couramment utilisé par le propriétaire du véhicule 10.
De même, avant la mise en œuvre du procédé, le terminal utilisateur 20 est inconnu du véhicule 10 qui n'a donc connaissance d'aucune donnée associée à ce terminal utilisateur 20.
On considère que, pour la mise en œuvre du procédé de la figure 3, un utilisateur U (selon un mode de réalisation : le propriétaire du véhicule 10 ; dans un autre mode de réalisation, une personne chargée de la mise en service du véhicule 10) a accès au véhicule 10 (également référencé V en figure 3) par des moyens classiques (par exemple une clé physique).
Dans le mode de réalisation décrit ici, l'utilisateur U porte et utilise le terminal utilisateur 20 qui, comme décrit ci-dessus, est en communication d'une part avec l'unité électronique de commande 1 1 via une liaison sans fil (par exemple de type Bluetooth) et d'autre part avec le serveur 50 (référencé S en figure 3) via une liaison radio jusqu'à la station de base 31 , puis via le réseau de téléphonie mobile 30 et le réseau public 40.
Le terminal utilisateur 20 peut ainsi être utilisé, dans le mode de réalisation décrit ici, en tant que passerelle permettant un échange de données entre le véhicule V (précisément l'unité électronique de commande 1 1 ) et le serveur S, comme décrit ci-après.
En variante, on pourrait utiliser d'autres moyens de communication entre le véhicule V (i.e. l'unité électronique de commande 1 1 ) et le serveur S, par exemple un module de communication (parfois dénommé "Telematic Control Unit") équipant le véhicule V et conçu pour établir une communication (directe) entre le véhicule V et le réseau de téléphonie mobile 30.
Le procédé de la figure 3 débute à l'étape E2 à laquelle l'utilisateur U communique au serveur S (référencé 50 en figure 1 ) un identifiant utilisateur UID et un identifiant VID du véhicule V (référencé 10 en figure 1 ). Dans un mode de réalisation envisageable, l'utilisateur U se connecte pour ce faire au serveur S (par exemple en saisissant l'adresse http du serveur S dans un navigateur exécuté par le processeur 22 du terminal utilisateur 20) et saisit par exemple les identifiants précités UID, VID dans un formulaire ensuite transmis au serveur S. Dans un autre mode de réalisation envisageable, une application préalablement installée sur le terminal utilisateur 20 demande à l'utilisateur U la saisie des identifiants et les transmet au serveur 50.
En variante, l'identifiant utilisateur UID et l'identifiant VID du véhicule V peuvent avoir été saisis au préalable au niveau du serveur S, par exemple lors de l'achat du véhicule V.
L'identifiant utilisateur UID comprend par exemple les nom et prénom(s) de l'utilisateur, ainsi qu'éventuellement sa date de naissance. On pourrait toutefois utiliser en variante un autre type de donnée pour identifier l'utilisateur ; ainsi, l'identifiant utilisateur pourrait être une adresse électronique, un numéro de téléphone (par exemple le numéro attribué à l'abonnement au service de téléphonie mobile, tel qu'un numéro MSISDN) ou un identifiant du terminal utilisateur de l'utilisateur U (tel qu'un numéro IMEI).
L'identifiant VID du véhicule est par exemple de type "Vehicle Identification Numbei". On pourrait toutefois utiliser en variante un autre identifiant associé au véhicule 10, notamment le numéro de série N de l'unité électronique de commande 1 1 du véhicule 10.
Le serveur S reçoit l'identifiant utilisateur U et l'identifiant véhicule VID à l'étape E4 et mémorise ces identifiants, à cette étape dans une zone dédiée aux véhicules pour lesquels l'inscription au service de commande de fonctionnalités du véhicule au moyen du terminal utilisateur est en cours.
Le numéro de série N de l'unité électronique de commande 1 1 est par exemple communiqué par l'utilisateur U au serveur S, par exemple lors de l'étape E2. Pour ce faire, le numéro de série N est fourni au préalable à l'utilisateur : il est par exemple imprimé sur une étiquette collée dans le manuel d'utilisation du véhicule et/ou accessible par l'utilisateur au moyen de l'interface utilisateur 18.
Le serveur S peut ainsi déterminer à l'étape E10 la clé cryptographique PrK mémorisée (comme décrit ci-dessus) en association avec ce numéro de série N.
Le serveur S génère alors un défi (en anglais "challenge"), par exemple nombre aléatoire RND (étape E12).
Le serveur S calcule alors à l'étape E14 une réponse RESP associée à ce défi par application d'une fonction cryptographique f utilisant la clé cryptographique PrK, ce que l'on peut écrire : RESP = f(RND,PrK).
Le serveur S peut ainsi émettre à l'étape E16 le défi RND et une partie de la réponse RESP, ici un mot de poids faible LSB (pour "Least Significant Byte") formant partie de la réponse RESP, à destination du véhicule V, précisément de l'unité électronique de commande 1 1 .
On rappelle comme déjà indiqué que le serveur S (référencé 50 en figure 1 ) communique ici avec l'unité électronique de commande 1 1 par l'intermédiaire du terminal utilisateur 20.
L'unité électronique de commande 1 1 reçoit le défi RND et la partie de réponse LSB et calcule à son tour à l'étape E18 la réponse attendue RESP' par application au défi RND reçu de la fonction cryptographique f utilisant la clé cryptographique PrK mémorisée comme indiqué plus haut dans l'unité de mémorisation 14 : RESP' = f(RND,PrK).
L'unité électronique de commande 1 1 vérifie alors à l'étape E20 que la partie LSB' (correspondant à la partie de la réponse RESP reçue, ici le mot de poids faible) de la réponse RESP' calculée à l'étape E18 est bien égale à la partie de réponse LSB reçue en provenance du serveur S.
Si cette égalité n'est pas vérifiée, l'unité électronique de commande 1 1 procède à l'étape E21 qui met fin au processus d'inscription. En effet, cela signifie que la clé cryptographique utilisée dans le calcul de l'étape E14 diffère de celle utilisée dans le calcul de l'étape E18 et qu'une erreur s'est donc produite (par exemple du fait de l'envoi d'un identifiant véhicule erroné à l'étape E2). Un message d'erreur peut alors par exemple être affiché sur l'interface utilisateur 18 du véhicule V.
Si l'égalité est vérifiée, l'unité électronique de commande 1 1 émet à l'étape E22 une autre partie de la réponse RESP' calculée à l'étape E18, ici un mot de poids fort MSB' (pour "Most Significant Byte"), à destination du serveur S.
Le serveur S reçoit cette autre partie MSB' de la réponse RESP' et vérifie à l'étape E24 que la partie MSB (correspondant à la partie MSB' de la réponse RESP' reçue, ici le mot de poids fort) de la réponse RESP calculée à l'étape E14 est bien égale à la partie de réponse MSB' reçue en provenance de l'unité électronique de commande 1 1 .
Si cette égalité n'est pas vérifiée, le serveur procède à l'étape E25 qui met fin au processeur d'inscription. En effet, cela signifie que le partenaire du serveur S dans la communication n'a pas été en mesure de calculer la réponse attendue, vraisemblablement du fait que le partenaire n'est pas le véhicule attendu et ne détient donc pas la clé cryptographique PrK.
En fonctionnement normal, l'égalité est vérifiée et une authentification mutuelle a ainsi été réalisée entre le serveur S et l'unité électronique de commande 1 1 .
Le serveur S déclenche alors la poursuite du procédé d'inscription en émettant à destination de l'unité électronique de commande 1 1 une commande CMD de vérification de la présence de l'utilisateur U dans le véhicule V (étape E26).
À réception de la commande CMD, l'unité électronique de commande 1 1 commande à l'étape E28 la génération par l'interface utilisateur 18 d'une indication demandant à l'utilisateur U d'effectuer une ou plusieurs action(s) ACT.
Cette indication peut être une indication visuelle (par exemple un signal lumineux ou un affichage sur un écran de l'interface utilisateur 18) et/ou sonore (par exemple un son particulier ou un message vocal). L'action ou les actions demandée(s) peu(ven)t comprendre l'utilisation de la clé physique (par exemple l'appui, éventuellement simultané, sur un ou plusieurs boutons de la clé physique, ou le démarrage et/ou l'arrêt du moteur avec la clé physique) et/ou une action de l'utilisateur U sur le véhicule V, par exemple un appui sur un bouton de l'interface utilisateur 18, une ouverture et/ou une fermeture de porte, et/ou un démarrage et/ou un arrêt du moteur.
L'utilisateur effectue l'action (ou les actions) demandée(s) ACT à l'étape
E30.
L'unité électronique de commande 1 1 détecte à l'étape E32 si l'action effectuée par l'utilisateur U correspond bien à l'action demandée ACT (en laissant par exemple une durée prédéterminée à l'utilisateur pour accomplir l'action).
En cas d'échec (c'est-à-dire si l'utilisateur U n'effectue pas les actions demandées dans le laps de temps imparti), l'unité électronique de commande 1 1 procède à l'étape E34 qui met fin au processus d'inscription. Un message d'erreur peut en outre être affiché sur l'interface utilisateur 18 du véhicule V.
En revanche, si l'utilisateur effectue correctement les actions demandées ACT dans le temps imparti, on considère que toutes les conditions requises pour effectuer l'inscription sont remplies et que le service de commande de fonctionnalités du véhicule au moyen du terminal utilisateur peut être lancé.
On remarque qu'il est possible d'envisager d'autres conditions de validation de l'inscription, par exemple la saisie au niveau de l'interface utilisateur 18 du véhicule 10 d'un code à usage unique reçu et affiché par le terminal utilisateur 20. Un tel code à usage unique peut être émis par le serveur 50, à destination du terminal utilisateur 20, via le réseau public 40, par exemple lors de l'exécution de l'application permettant, dans certains modes de réalisation, la saisie des identifiants à l'étape E2, comme indiqué ci-dessus. En variante, le code à usage unique pourrait être transmis (par exemple sous forme de message court ou SMS, pour "Short Message System") au terminal utilisateur 20 en utilisant le numéro de téléphone (numéro MSISDN) associé à l'abonnement utilisé par le terminal utilisateur 20, en particulier lorsque ce numéro forme l'identifiant utilisateur, comme également envisagé ci-dessus. Dans ce dernier cas, le serveur 50 est conçu pour émettre des données sur le réseau téléphonique.
Dans certains modes de réalisation, on peut alors procéder au lancement d'un compteur au sein de l'unité électronique de commande 1 1 , en utilisant les informations de construction mémorisées dans l'unité de mémorisation 14 comme déjà indiqué : dans le mode de réalisation décrit ici, le compteur est initialisé à la valeur initiale I et incrémenté périodiquement avec la période P (étape E36). Lorsque le compteur est mémorisé sur un nombre de bits donné, il est remis à zéro lors d'une incrémentation entraînant un dépassement (ou "overflow" selon la dénomination anglo-saxonne parfois utilisée) de la valeur maximale (déterminée par le nombre de bits du compteur).
L'unité électronique de commande 1 1 émet par ailleurs à destination du serveur S un message indiquant que la présence de l'utilisateur a été détecté (par les actions ACT qu'il a effectué à la demande de l'unité électronique de commande 1 1 ) et que le service peut donc être lancé (étape E38).
Le serveur S reçoit ce message et, dans le cas où un compteur est utilisé, lance également le compteur en son sein (étape E40), en association avec l'identifiant véhicule VID et sur la base des informations de construction mémorisées en association avec le numéro de série N de l'entité électronique de commande 1 1 , ici la valeur initiale I et la période P d'incrémentation du compteur.
Le compteur évolue donc en parallèle au sein de l'unité de commande 1 1 et au sein du serveur S, avec éventuellement un très faible décalage entre le compteur mémorisé dans l'unité électronique de commande 1 1 et le compteur mémorisé dans le serveur 50 (dû notamment à la courte durée séparant les étapes E36 et E40), ce qui n'est toutefois pas préjudiciable.
Le serveur S peut alors décider de l'inscription définitive de l'utilisateur U au service et mémorise pour ce faire en association, dans une zone de mémorisation des souscripteurs du service, l'identifiant utilisateur UID, l'identifiant véhicule VID et, dans le cas où un compteur est utilisé, la valeur courante du compteur (qui sera incrémentée périodiquement avec la période P), ainsi qu'éventuellement le numéro de série N (étape E42). L'identifiant utilisateur UID et l'identifiant véhicule VID mémorisés en association peuvent être considérés comme un certificat électronique de propriété du véhicule pour le service proposé. Le serveur S peut alors communiquer à l'utilisateur U des droits d'accès au service de commande des fonctionnalités du véhicule, par exemple en transmettant au terminal utilisateur 20 une clé virtuelle VK autorisant le terminal utilisateur 20 à commander ces fonctionnalités (e.g. l'ouverture des portes du véhicule), comme dans les exemples présentés ci-dessous. La clé virtuelle VK est mémorisée dans le terminal utilisateur 20 (étape E44). En pratique, la clé virtuelle VK peut être transmise du serveur 50 à une application préalablement téléchargée dans la mémoire 24 du terminal utilisateur 20 et exécutable par le processeur 22 du terminal utilisateur 20, par exemple l'application permettant la mise en œuvre de l'étape E2 comme envisagé ci-dessus. En variante, la clé virtuelle VK pourrait être transmise au terminal utilisateur 20 en utilisant le numéro de téléphone (numéro MSISDN) associé à l'abonnement utilisé par le terminal utilisateur 20, en particulier lorsque ce numéro forme l'identifiant utilisateur, comme également envisagé ci-dessus.
La figure 4 présente les étapes principales d'un exemple de procédé de commande d'une fonctionnalité du véhicule V (référencé 10 en figure 1 ) au moyen du terminal utilisateur T (du type de celui référencé 20 en figure 1 ).
D'autres étapes que celles décrites ci-dessous peuvent naturellement être mises en œuvre en pratique, en particulier au préalable afin d'établir un canal de communication entre l'unité électronique de commande 1 1 du véhicule 10 et le terminal utilisateur 20.
Le procédé de commande décrit ici est particulièrement bien adapté au cas où le véhicule V est loué à un utilisateur pour une période de temps prédéfinie.
On utilise pour ce faire une clé virtuelle VK temporaire, dérivée en prenant en compte la valeur NB1 du compteur (installé en parallèle dans l'unité électronique de commande 1 1 du véhicule V et dans le serveur S comme indiqué ci-dessus) au début de la période de location et la valeur NB2 du compteur en fin de période de location.
Afin de générer la clé virtuelle VK, le serveur S reçoit par exemple du loueur de véhicule l'identifiant véhicule VID, l'heure de début de location et l'heure de fin de location et détermine, sur la base des informations de construction de compteur lues dans l'unité de mémorisation 14, la valeur NB1 du compteur mis en place dans l'unité électronique de commande 1 1 concernée (dont le numéro de série N est associé à l'identifiant véhicule VID reçu, suite par exemple au procédé de la figure 3) et correspondant à l'heure de début de location, et la valeur NB2 de ce compteur correspondant à l'heure de fin de location.
La clé virtuelle VK est alors générée en utilisant la clé racine MK (mémorisée comme indiqué ci-dessus en association avec le numéro de série N), la valeur de début NB1 et la valeur de fin NB2, par exemple par application d'une fonction de dérivation g à ces éléments : VK = g(MK,NB1 ,NB2).
Le serveur S transmet alors la clé virtuelle VK et les valeurs NB1 , NB2 au terminal usuel T (par exemple un téléphone portable) de l'utilisateur (locataire du véhicule), par exemple après une étape de vérification que ce terminal usuel T est bien éligible au service (sur la base d'un identifiant du terminal, tel qu'un numéro IMEI, et/ou d'un numéro d'abonné associé au terminal, tel qu'un numéro MSISDN) ; la clé virtuelle VK et les valeurs NB1 , NB2 sont alors mémorisées au sein du terminal T. (On remarque que le terminal T utilisé ici n'est donc pas généralement celui utilisé dans le cadre de la figure 3.)
On peut alors procéder à la commande de fonctionnalité du véhicule V au moyen du terminal T.
Pour ce faire, le terminal T émet à l'étape E102 une requête de mise en œuvre de la fonctionnalité, accompagnée de la valeur de début NB1 et de la valeur de fin NB2, à destination de l'unité électronique de commande 1 1 du véhicule V (étape E102).
L'unité électronique de commande 1 1 vérifie alors à l'étape E104 que la valeur courante du compteur qu'elle met en œuvre est bien comprise entre la valeur NB1 et la valeur NB2 (ce qui signifie, d'après la construction décrite ci- dessus des valeurs NB1 et NB2, que l'instant courant est compris dans la période de location).
Dans la négative, l'unité électronique de commande 1 1 met fin au procédé à l'étape E106 sans effectuer la fonctionnalité requise (c'est-à-dire ici sans déverrouiller les portes du véhicule V). Un message d'échec peut éventuellement être transmis au terminal T pour affichage sur le terminal T d'une indication correspondante.
En cas de vérification positive à l'étape E104, le procédé se poursuit à l'étape E108 à laquelle l'unité électronique de commande 1 1 calcule la clé virtuelle VK sur la base de la clé racine MK (mémorisée comme indiqué ci-dessus dans l'unité de mémorisation 14), la valeur de début NB1 et la valeur de fin NB2, selon le même calcul que celui effectué comme indiqué ci-dessus au sein du serveur S, ici par application de la fonction de dérivation g à ces éléments : l'unité électronique de commande 1 1 calcule dans ce cas VK = g(MK,NB1 ,NB2).
L'unité électronique de commande 1 1 génère alors à l'étape E1 10 un défi, par exemple un nombre aléatoire RND', et émet ce défi à destination du terminal utilisateur T.
Le terminal utilisateur T reçoit ce défi à l'étape E1 12.
À l'étape E1 14, le terminal utilisateur T (c'est-à-dire en pratique son processeur) applique au défi reçu RND' une fonction cryptographique h utilisant la clé virtuelle VK (reçue du serveur S au préalable comme indiqué ci-dessus) et obtient ainsi une réponse R : R = h(RND',VK). D'autres données peuvent éventuellement être utilisées dans les calculs effectués à cette étape, par exemple l'identifiant véhicule VID.
En parallèle, l'unité électronique de commande effectue à l'étape E1 15 un calcul identique (en fonctionnement normal) afin d'obtenir de son côté la réponse attendue ; on note ici R' le résultat de ce calcul : R' = h(RND',VK).
Le terminal utilisateur T émet la réponse attendue R (calculée à l'étape E1 14) à destination de l'unité électronique de commande 1 1 (étape E1 16).
L'unité électronique de commande 1 1 vérifie alors à l'étape E1 18 que la réponse R reçue du terminal utilisateur T est bien égale à la réponse attendue R', auquel l'unité électronique de commande 1 1 peut considérer que le terminal utilisateur T détient bien la clé virtuelle VK qui donne un droit d'accès au véhicule.
En cas d'échec de la vérification à l'étape E1 18 (ce qui n'est pas le cas dans le fonctionnement normal décrit ci-dessus, mais peut-être le cas lorsqu'une personne malintentionnée tente d'accéder au véhicule sans connaître la clé virtuelle VK), l'unité électronique de commande 120 met fin au procédé à l'étape E120 sans effectuer la fonctionnalité requise (c'est-à-dire ici sans déverrouiller les portes du véhicule V). Un message d'échec peut éventuellement être transmis au terminal T pour affichage sur le terminal T d'une indication correspondante.
Lorsque l'égalité entre la réponse R reçue du terminal utilisateur T et la réponse attendue R' calculée par l'unité électronique de commande 1 1 est vérifiée à l'étape E1 18, on procède à l'étape E122 à laquelle l'unité électronique de commande effectue la fonctionnalité demandée, ici le déverrouillage des portes du véhicule, en émettant une commande correspondante à destination de l'actionneur 15 (ou, dans le cas du démarrage du véhicule, à l'actionneur 17).
Dans l'exemple qui vient d'être décrit, une authentification simple est utilisée ; on peut toutefois prévoir en variante d'utiliser une authentification mutuelle, par exemple lorsque la fonctionnalité souhaitée est le démarrage du véhicule.
Par ailleurs, dans le cas qui vient d'être décrit, on utilise une clé virtuelle VK temporaire, particulièrement adaptée à la location de véhicules.
Dans d'autres modes de réalisation, on pourrait utiliser une clé virtuelle VK fixe, par exemple mémorisée dans l'unité de mémorisation 14 en lieu et place de la clé racine MK. Les étapes E102 et E1 10 à E122 décrites ci-dessus, permettant la commande de la fonctionnalité du véhicule avec le terminal utilisateur, peuvent alors être mises en œuvre en utilisant cette clé virtuelle fixe. Le terminal utilisateur où est mémorisée la clé virtuelle VK peut être dans ce cas le terminal utilisateur utilisé lors du procédé de la figure 3. Par ailleurs, on peut éventuellement ne pas utiliser le compteur mentionné ci-dessus, auquel cas les étapes E36, E40 et E104 à E108 sont omises, et l'étape E102 consiste en une simple requête de mise en œuvre de la fonctionnalité, sans valeurs de compteur annexées.
La figure 5 présente les étapes principales d'un autre exemple de procédé d'inscription à un service de commande de fonctionnalités du véhicule 10 au moyen du terminal utilisateur 20.
Ce procédé débute à l'étape E200 au cours de laquelle l'utilisateur U (généralement le propriétaire du véhicule V) communique le numéro de série N de l'unité électronique de commande 1 1 et son identifiant UID (par exemple un identifiant du terminal utilisateur 20, tel que le numéro IMEI ou le numéro d'abonné associé MSISDN) au serveur S.
On comprend que, dans le présent mode de réalisation, le numéro de série N est utilisé en tant qu'identifiant associé au véhicule 10.
Pour communiquer ces informations au serveur S, l'utilisateur U se connecte par exemple sur un site Internet associé au serveur S et peut alors saisir les informations N, UID dans un formulaire transmis ensuite au serveur S. Ces opérations peuvent éventuellement être réalisées au moyen du terminal 20, mais également au moyen d'un ordinateur personnel de l'utilisateur U. Le serveur S reçoit les informations N, UID à l'étape E202 et mémorise celles-ci, par exemple dans une zone de mémorisation dédiée aux véhicules pour lesquels l'inscription au service de commande de fonctionnalités du véhicule au moyen du terminal utilisateur est en cours.
On remarque qu'en variante, ces informations N, UID pourraient être saisies au niveau du serveur S au moment de l'achat du véhicule V (l'utilisateur U fournissant alors les informations le concernant à l'organisation gérant le serveur S).
Le serveur S prépare alors à l'étape E204 une application APP destinée au terminal 20 et qui contient un message spécifique MSG (conçu pour être lu uniquement par l'unité électronique de commande 1 1 dont le numéro de série N a été reçu à l'étape E202) et une clé de dérivation K spécifique à l'application APP. Le serveur S mémorise notamment la clé de dérivation K en association avec les informations N, UID précédemment mémorisées.
L'application APP est téléchargée et installée sur le terminal 20 (désigné ci-après terminal T) à l'étape E206. Pour ce faire, le serveur S transmet par exemple un lien https au terminal 20 (par exemple en utilisant le numéro d'abonné MSISDN fourni à l'étape E200 en tant qu'identifiant UID, ou fourni à l'étape E200 en complément de l'identifiant UID), lien utilisé ensuite par l'utilisateur U pour effectuer le téléchargement de l'application APP sur le terminal T.
Lors d'une étape E208 ultérieure (qui peut être séparée de l'étape E206 d'un temps plus ou moins long), l'utilisateur U lance l'exécution de l'application APP sur le terminal T.
Après une phase d'initialisation de la liaison sans fil entre le module de communication sans fil 16 du véhicule V et le module de communication sans fil 26 du terminal T, l'application APP provoque l'émission du message spécifique MSG à destination de l'unité électronique de commande 1 1 du véhicule V.
Le message spécifique MSG est reçu à l'étape E210 par l'unité électronique de commande 1 1 , qui vérifie que ce message spécifique MSG lui est bien destiné. Si cette vérification ne s'effectue pas correctement, il est mis fin au processus d'inscription.
Si l'unité électronique de commande 1 1 est bien le destinataire prévu du message spécifique MSG, l'unité électronique de commande 1 1 émet à l'étape E210 une demande d'authentification auprès du serveur S, accompagnée par exemple de son numéro de série N (ou d'un autre identifiant de l'unité électronique de commande 1 1 ). Une telle demande est par exemple transmise de l'unité électronique de commande 1 1 au serveur S via le terminal T (comme déjà expliqué à propos du mode de réalisation de la figure 3). Pour ce faire, l'application APP embarque par exemple une adresse IP du serveur 50 et transmet à cette adresse la réponse qu'elle reçoit de l'unité électronique de commande 1 1 . En variante, cette demande pourrait être transmise au moyen d'un module de communication du véhicule V.
Le serveur S reçoit la demande d'authentification et le numéro de série N et transmet alors à l'étape E212 un défi X à destination du terminal T (dont un identifiant ou un numéro d'abonnement associé est mémorisé comme déjà indiqué au niveau du serveur S en association avec l'identifiant associé au véhicule, ici le numéro de série N).
Le terminal T reçoit le défi X et applique à ce défi X (étape E214) une fonction cryptographique d utilisant la clé de dérivation K, préalablement reçue avec l'application APP (voir l'étape E206 décrite ci-dessus), ce qui permet d'obtenir une donnée dérivée Y : Y = d(X,K).
La donnée dérivée Y est transmise du terminal T à l'unité électronique de commande 1 1 du véhicule V via la liaison sans fil établie comme indiqué ci-dessus à l'étape E208.
L'unité électronique de commande 1 1 reçoit la donnée dérivée Y et calcule à l'étape E216 une réponse Z en appliquant à cette donnée dérivée Y une fonction cryptographique f utilisant la clé cryptographique PrK mémorisée comme indiqué plus haut dans l'unité de mémorisation 14 : Z = f(Y,PrK).
L'unité électronique de commande 1 1 émet la réponse Z calculée à l'étape E216 à destination du serveur S, par exemple via le terminal T comme indiqué ci-dessus (ou en variante au moyen d'un module de communication équipant le véhicule V).
Le serveur S reçoit la réponse Z et peut ainsi vérifier à l'étape E218 que cette réponse Z est bien la réponse attendue f(d(X,K),PrK). En effet, le serveur S mémorise, en association avec le numéro de série N de l'unité électronique de commande 1 1 , la clé cryptographique PrK (comme décrit ci-dessus en référence à la figure 2) et la clé de dérivation K (voir ci-dessus l'étape E204) ; le serveur S a par ailleurs connaissance du défi X qu'il a émis à l'étape E212. Si la réponse Z reçue en provenance de l'unité électronique de commande 1 1 ne correspond pas à la réponse attendue f(d(X,K),PrK), il est mis fin au processus d'inscription.
Si la réponse Z reçue en provenance de l'unité électronique de commande 1 1 correspond à la réponse attendue f(d(X,K),PrK), cela signifie que le terminal T et l'unité électronique de commande 1 1 du véhicule V, qui ont chacun participé à la production de la réponse Z (en utilisant chacun une information qui leur est spécifique), sont bien ceux respectivement associés à l'utilisateur U (identifié par son identifiant UID) et au véhicule V (identifié ici par le numéro de série N) : le serveur S a ainsi pu authentifier le terminal T et l'unité électronique de commande 1 1 .
Le serveur S décide alors de l'inscription définitive de l'utilisateur U au service de commande de fonctionnalités du véhicule V au moyen du terminal T et mémorise pour ce faire à l'étape E220, dans une zone de mémorisation des souscripteurs du service, en association l'identifiant utilisateur UID (par exemple, comme déjà indiqué, un identifiant associé au terminal T) et l'identifiant associé au véhicule (ici le numéro de série N).
Le serveur S peut alors communiquer à l'utilisateur U des droits d'accès au service de commande des fonctionnalités du véhicule, par exemple en transmettant (étape E222) au terminal T une clé virtuelle VK autorisant le terminal T à commander ces fonctionnalités, comme dans les exemples présentés plus haut. La clé virtuelle VK peut ainsi être mémorisée dans le terminal utilisateur T (étape E224).
On peut prévoir dans certains modes de réalisation que les droits d'accès ne soient pas transmis immédiatement après l'inscription définitive, mais ultérieurement, par exemple après transmission d'un message électronique à l'utilisateur U (à une adresse électronique renseignée par exemple lors de l'étape E200) et confirmation de l'activation du service par l'utilisateur U en réponse à ce message électronique, par exemple par saisie au niveau du terminal T d'un code mentionné dans le message électronique.

Claims

REVENDICATIONS
1 . Procédé d'inscription d'un utilisateur (U) à un service de commande d'au moins une fonctionnalité d'un véhicule (10 ; V) au moyen d'un terminal utilisateur (20 ; T), caractérisé en ce qu'il comprend les étapes suivantes :
- communication d'un identifiant (UID) de l'utilisateur (U) et d'un identifiant (VID ; N) associé au véhicule (10 ; V) à un serveur (50 ; S) ;
- authentification d'une unité électronique (1 1 ) du véhicule (10 ; V) par le serveur (50 ; S) ;
- en cas d'authentification réussie, inscription de l'identifiant (UID) de l'utilisateur (U) et de l'identifiant (VID ; N) associé au véhicule (10 ; V) en association au niveau du serveur (50 ; S).
2. Procédé d'inscription selon la revendication 1 , dans lequel l'authentification comprend une étape (E14) d'utilisation par le serveur (50 ; S) d'une clé cryptographique mémorisée en association avec une référence (N) de l'unité électronique (1 1 ).
3. Procédé d'inscription selon la revendication 1 ou 2, dans lequel l'authentification comprend des échanges (E16, E22) de données entre le serveur (50 ; S) et l'unité électronique (1 1 ) via le terminal utilisateur (20 ; T).
4. Procédé d'inscription selon l'une des revendications 1 à 3, dans lequel l'étape d'authentification fait partie d'un processus d'authentification mutuelle entre le serveur (50 ; S) et l'unité électronique de commande (1 1 ).
5. Procédé d'inscription selon l'une des revendications 1 à 4, comprenant une étape de détection d'une action de l'utilisateur (U) sur un objet physique lié au véhicule (10 ; V), l'inscription étant en outre conditionnée par ladite détection.
6. Procédé d'inscription selon la revendication 5, dans lequel l'étape de détection (E32) est mise en œuvre seulement en cas d'authentification réussie.
7. Procédé d'inscription selon la revendication 6, comprenant, en cas de détection réussie, une étape d'émission (E38) par l'unité électronique (1 1 ) d'un message de lancement du service à destination du serveur (50 ; S), ladite inscription (E42) étant effectuée par le serveur (50 ; S) à réception du message de lancement du service.
8. Procédé selon l'une des revendications 5 à 7, dans lequel l'objet physique est une clé physique apte à commander le déverrouillage des portes du véhicule (10 ; V).
9. Procédé selon l'une des revendications 1 à 8, comprenant les étapes suivantes :
- téléchargement (E206), du serveur (50 ; S) au terminal (20 ; T), d'une application (APP) contenant un message spécifique (MSG) destiné à une entité électronique de commande correspondant à l'identifiant (VID ; N) associé au véhicule (10 ; V) ;
- transmission (E208), du fait de l'exécution de l'application (APP) sur le terminal (20 ; T), du message spécifique à l'unité de commande (1 1 ) du véhicule (V).
10. Procédé selon l'une des revendications 1 à 9, dans lequel l'identifiant (UID) de l'utilisateur (U) est un identifiant du terminal utilisateur (20 ; T).
1 1 . Procédé selon l'une des revendications 1 à 10, comprenant en outre, en cas d'authentification réussie, une étape d'initialisation (E36 ; E40) d'un compteur au sein du serveur (50 ; S) et au sein de l'unité électronique (1 1 ).
12. Procédé selon la revendication 1 1 , dans lequel le compteur est initialisé à l'étape d'initialisation (E36 ; 40) avec une valeur d'initialisation mémorisée au sein du serveur (50 ; S) et au sein de l'unité électronique (1 1 ), et dans lequel le compteur est incrémenté périodiquement avec une période mémorisée au sein du serveur (50 ; S) et au sein de l'unité électronique (1 1 ).
13. Procédé d'inscription selon l'une des revendications 1 à 12, comprenant, suite à ladite inscription, une étape d'émission d'une clé virtuelle (VK) à destination du terminal (20 ; T).
14. Procédé selon l'une des revendications 1 à 13, dans lequel l'étape de communication est réalisée par transmission, au moyen du terminal utilisateur
(20 ; T), de l'identifiant (UID) de l'utilisateur (U) et de l'identifiant (VID ; N) associé au véhicule (10 ; V) au serveur (50 ; S).
15. Procédé selon l'une des revendications 1 à 13, dans lequel l'étape de communication est réalisée par saisie, au niveau du serveur (50 ; S), de l'identifiant (UID) de l'utilisateur (U) et de l'identifiant (VID ; N) associé au véhicule (10 ; V).
EP15823702.4A 2014-12-30 2015-12-22 Procédé d'inscription d'un utilisateur à un service de commande d'une fonctionnalité d'un véhicule au moyen d'un terminal utilisateur Withdrawn EP3265344A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1463430A FR3031268B1 (fr) 2014-12-30 2014-12-30 Procede d’inscription d’un utilisateur a un service de commande d’une fonctionnalite d’un vehicule au moyen d’un terminal utilisateur
PCT/FR2015/053719 WO2016108012A1 (fr) 2014-12-30 2015-12-22 Procédé d'inscription d'un utilisateur à un service de commande d'une fonctionnalité d'un véhicule au moyen d'un terminal utilisateur

Publications (1)

Publication Number Publication Date
EP3265344A1 true EP3265344A1 (fr) 2018-01-10

Family

ID=52627497

Family Applications (1)

Application Number Title Priority Date Filing Date
EP15823702.4A Withdrawn EP3265344A1 (fr) 2014-12-30 2015-12-22 Procédé d'inscription d'un utilisateur à un service de commande d'une fonctionnalité d'un véhicule au moyen d'un terminal utilisateur

Country Status (6)

Country Link
US (1) US11004124B2 (fr)
EP (1) EP3265344A1 (fr)
JP (1) JP2018508858A (fr)
CN (1) CN107211002B (fr)
FR (1) FR3031268B1 (fr)
WO (1) WO2016108012A1 (fr)

Families Citing this family (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2017209310A1 (fr) * 2016-06-03 2017-12-07 株式会社ミックウェア Système de traitement d'informations, terminal de traitement d'informations, procédé de traitement d'informations et programme de traitement d'informations
JP6846991B2 (ja) * 2016-07-05 2021-03-24 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカＰａｎａｓｏｎｉｃ Ｉｎｔｅｌｌｅｃｔｕａｌ Ｐｒｏｐｅｒｔｙ Ｃｏｒｐｏｒａｔｉｏｎ ｏｆ Ａｍｅｒｉｃａ 異常検知電子制御ユニット、車載ネットワークシステム及び異常検知方法
US10189443B2 (en) * 2016-11-10 2019-01-29 GM Global Technology Operations LLC Virtual key for vehicle servicing
US10771450B2 (en) 2018-01-12 2020-09-08 Blackberry Limited Method and system for securely provisioning a remote device
JP6640906B2 (ja) * 2018-04-24 2020-02-05 株式会社東海理化電機製作所 鍵情報生成システム及び鍵情報生成方法
US10715471B2 (en) * 2018-08-22 2020-07-14 Synchronoss Technologies, Inc. System and method for proof-of-work based on hash mining for reducing spam attacks
KR102690274B1 (ko) * 2019-04-12 2024-07-30 현대자동차주식회사 이동체에 복수 개의 식별 디바이스를 이용하는 방법 및 장치
CN110239484B (zh) * 2019-06-28 2020-09-25 江苏恒宝智能系统技术有限公司 车辆锁远程安全控制系统和方法
CN110391913B (zh) * 2019-08-05 2022-08-23 斑马网络技术有限公司 车辆的绑定方法及装置
JP7322732B2 (ja) * 2020-02-03 2023-08-08 トヨタ自動車株式会社 認証システム
US11049342B1 (en) 2020-09-03 2021-06-29 LockState, Inc. Intelligent lock credential validation
US11438158B2 (en) * 2021-01-05 2022-09-06 Toyota Motor North America, Inc. Provisioning of external functionality to transports
CN113162999A (zh) * 2021-04-08 2021-07-23 上海七十迈数字科技有限公司 一种基于电动自行车的信息推送方法及设备
CN113163000A (zh) * 2021-04-08 2021-07-23 上海七十迈数字科技有限公司 一种基于电动自行车的信息推送方法及设备
CN113791802B (zh) * 2021-09-07 2024-02-27 东风汽车有限公司东风日产乘用车公司 车辆升级方法、装置、设备及存储介质
US20230298417A1 (en) * 2022-03-16 2023-09-21 Capital One Services, Llc Using identity credentials as a key for securely controlling a lock connected to a wireless network
JP7717665B2 (ja) * 2022-07-12 2025-08-04 Kddi株式会社 認証システム、コネクテッドカー及び認証方法
JP7685974B2 (ja) * 2022-07-14 2025-05-30 Kddi株式会社 認証システム、認証装置及び認証プログラム
JP7743825B2 (ja) * 2022-09-29 2025-09-25 トヨタ自動車株式会社 情報処理システム
DE102024130385A1 (de) * 2024-10-18 2026-04-23 Bayerische Motoren Werke Aktiengesellschaft Verfahren und Vorrichtung zur Erzeugung eines digitalen Zugangsschlüssels für ein Kraftfahrzeug

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5715905A (en) * 1995-11-09 1998-02-10 Products Research, Inc. Vehicle access controller
EP1847969B1 (fr) * 2006-04-19 2011-11-30 Mobility Genossenschaft Systèmes et méthodes de contrôle d'accès au véhicule

Family Cites Families (30)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6253980B1 (en) * 1999-07-07 2001-07-03 Honda Giken Kogyo Kabushiki Kaisha Shared vehicle system and method with system for carrying a first vehicle with a second vehicle
US20030034873A1 (en) * 2000-02-16 2003-02-20 Robin Chase Systems and methods for controlling vehicle access
DE50201846D1 (de) * 2002-09-16 2005-01-27 Swisscom Ag Bern Computergestütztes Fahrzeugreservationssystem und Verfahren für ein computergestütztes Fahrzeugreservationssystem
JP4068512B2 (ja) * 2003-06-10 2008-03-26 株式会社東芝 通信装置、携帯端末装置、通信システム、通信制御プログラム及び通信制御方法
JP4041090B2 (ja) * 2004-04-06 2008-01-30 本田技研工業株式会社 車両用遠隔施錠解錠制御装置
US7482142B1 (en) * 2004-05-07 2009-01-27 Roche Molecular Systems, Inc. High-risk human papillomavirus detection
JP2007004499A (ja) * 2005-06-24 2007-01-11 Mazda Motor Corp プログラムデータ配信システム
JP4554473B2 (ja) * 2005-08-26 2010-09-29 パナソニック株式会社 コンテンツサーバ装置
DE102006015212B4 (de) * 2006-03-30 2017-05-04 Bundesdruckerei Gmbh Verfahren zum Schutz eines beweglichen Gutes, insbesondere eines Fahrzeugs, gegen unberechtigte Nutzung
JP4923974B2 (ja) * 2006-09-05 2012-04-25 株式会社デンソー 無線通信システム及び車載装置
WO2008044093A1 (fr) * 2006-10-11 2008-04-17 Renault Trucks Dispositif d'identification de client, système d'accès sans clé pour un véhicule, système de partage de véhicule comprenant un tel dispositif et procédés utilisant un tel dispositif
JP2009127285A (ja) * 2007-11-22 2009-06-11 Toyota Motor Corp 電子キーシステム、車両用電子キー装置、解錠方法
JP5120059B2 (ja) * 2008-05-09 2013-01-16 トヨタ自動車株式会社 携帯端末、通信方法及びプログラム並びにサービス提供方法
JP4636171B2 (ja) * 2008-12-17 2011-02-23 トヨタ自動車株式会社 車両用生体認証システム
JP5574611B2 (ja) * 2009-03-26 2014-08-20 株式会社Ｊｓｏｌ 電子解錠システム、サーバ、利用者端末、電気錠端末、及び情報処理方法
JP5788636B2 (ja) * 2009-12-16 2015-10-07 ソニー株式会社 電動移動体、管理装置、駆動管理方法、及び充電装置
JP5120437B2 (ja) * 2010-10-19 2013-01-16 トヨタ自動車株式会社 車載機、車両用認証システム及びデータ通信方法
DK177237B1 (en) * 2010-12-30 2012-07-30 Jcdecaux Sa Procedure for the rental of bicycles and facilities for use in the exercise thereof.
JP2012172325A (ja) * 2011-02-18 2012-09-10 Kddi Corp 車両のスマートキーシステム、スマートキーによる車両の操作方法およびプログラム
JP2012221224A (ja) * 2011-04-08 2012-11-12 Tokai Rika Co Ltd カーシェアシステム
JP5479408B2 (ja) * 2011-07-06 2014-04-23 日立オートモティブシステムズ株式会社 車載ネットワークシステム
JP5950225B2 (ja) * 2012-01-10 2016-07-13 クラリオン株式会社 サーバ装置、車載端末、情報通信方法および情報配信システム
JP5996872B2 (ja) * 2012-01-11 2016-09-21 株式会社東海理化電機製作所 貸与システム
JP5729337B2 (ja) * 2012-03-21 2015-06-03 株式会社デンソー 車両用認証装置、及び車両用認証システム
US8768565B2 (en) * 2012-05-23 2014-07-01 Enterprise Holdings, Inc. Rental/car-share vehicle access and management system and method
JP2014235537A (ja) * 2013-05-31 2014-12-15 Ｊｘ日鉱日石エネルギー株式会社 運転者ごとに供給情報及び車両情報を蓄積可能なシステム
JP6190188B2 (ja) * 2013-07-05 2017-08-30 クラリオン株式会社 情報配信システムおよびそれに用いるサーバ、車載端末、通信端末
US8646060B1 (en) * 2013-07-30 2014-02-04 Mourad Ben Ayed Method for adaptive authentication using a mobile device
CN103746969A (zh) * 2013-12-24 2014-04-23 深圳市领华卫通数码科技有限公司 车载终端认证的方法及认证服务器
DE102014200116A1 (de) * 2014-01-08 2015-07-09 Robert Bosch Gmbh Verfahren und Vorrichtung zur Freigabe von Funktionen eines Steuergerätes

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5715905A (en) * 1995-11-09 1998-02-10 Products Research, Inc. Vehicle access controller
EP1847969B1 (fr) * 2006-04-19 2011-11-30 Mobility Genossenschaft Systèmes et méthodes de contrôle d'accès au véhicule

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of WO2016108012A1 *

Also Published As

Publication number Publication date
US20180012272A1 (en) 2018-01-11
US11004124B2 (en) 2021-05-11
JP2018508858A (ja) 2018-03-29
FR3031268A1 (fr) 2016-07-01
FR3031268B1 (fr) 2017-01-13
CN107211002A (zh) 2017-09-26
WO2016108012A1 (fr) 2016-07-07
CN107211002B (zh) 2021-05-18

Similar Documents

Publication Publication Date Title
WO2016108012A1 (fr) Procédé d'inscription d'un utilisateur à un service de commande d'une fonctionnalité d'un véhicule au moyen d'un terminal utilisateur
EP3271901B1 (fr) Unité électronique, procédé mis en oeuvre dans une telle unité électronique, procédé de partage d'une base de temps entre un serveur et une unité électronique, et procédé de synchronisation d'un serveur et d'une unité électronique
EP2284803B1 (fr) Système sécurisé de programmation de dispositifs de serrure à commande électronique par accréditations acoustiques chiffrées
EP3348085B1 (fr) Procédé de chargement d'une clé virtuelle au sein d'un terminal utilisateur et terminal utilisateur associé
EP3547270B1 (fr) Procédé de vérification d'une authentification biométrique
EP2306407B1 (fr) Système de gestion sécurisée de serrures à commande numérique, adapté à un fonctionnement par accréditations acoustiques chiffrées
EP3269108A1 (fr) Procédé de transmission sécurisée d'une clé virtuelle et méthode d'authentification d'un terminal mobile
EP3474583B1 (fr) Procédés de chargement d'un profil dans un élément sécurisé, gestionnaire et élément sécurisé personnalisable
EP3168769A1 (fr) Procédé d'aide à l'authentification d'un utilisateur, serveur et programme d'ordinateur correspondants
WO2015092261A1 (fr) Système et procédé pour fournir un service a l'utilisateur d'un terminal mobile
EP3857413B1 (fr) Procede de traitement d'une transaction, dispositif, systeme et programme correspondant
EP3308564B1 (fr) Procédé de chargement d'une clé virtuelle et terminal utilisateur associé
EP2741466A1 (fr) Procédé et système de gestion d'un élément sécurisé intégré eSE
FR3025377A1 (fr) Gestion de tickets electroniques
WO2016102833A1 (fr) Entité électronique sécurisée, appareil électronique et procédé de vérification de l'intégrité de données mémorisées dans une telle entité électronique sécurisée
WO2018130486A1 (fr) Procédé d'authentification en deux étapes, dispositif et programme d'ordinateur correspondant
WO2017207894A1 (fr) Procédé pour renseigner des informations personnelles d'un utilisateur demandées par un service en ligne donné
FR3033204A1 (fr) Procede de securisation d'un service permettant la commande de vehicules automobiles au moyen de terminaux mobiles
WO2018029564A1 (fr) Systeme et procede d'authentification sans mot de passe d'un utilisateur d'un systeme applicatif par un serveur central
FR2913551A1 (fr) Methode d'authentification mutuelle et recurrente sur internet.
FR3071945B1 (fr) Securisation de l'acces a un service
FR3042362A1 (fr) Moyens de gestion d'acces a des donnees

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20171114

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

AX Request for extension of the european patent

Extension state: BA ME

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

17Q First examination report despatched

Effective date: 20190731

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20220628