EP4473758A1 - Verfahren für eine netzwerkkomponente zum bereitstellen von bluetooth-kontrolldaten, computerprogramm, vorrichtung und fahrzeug - Google Patents

Verfahren für eine netzwerkkomponente zum bereitstellen von bluetooth-kontrolldaten, computerprogramm, vorrichtung und fahrzeug

Info

Publication number
EP4473758A1
EP4473758A1 EP22711491.5A EP22711491A EP4473758A1 EP 4473758 A1 EP4473758 A1 EP 4473758A1 EP 22711491 A EP22711491 A EP 22711491A EP 4473758 A1 EP4473758 A1 EP 4473758A1
Authority
EP
European Patent Office
Prior art keywords
bluetooth
vehicle
user terminal
data
control data
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.)
Pending
Application number
EP22711491.5A
Other languages
English (en)
French (fr)
Inventor
Sven Hofmann
Stefan DIEWALD
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.)
Bayerische Motoren Werke AG
Original Assignee
Bayerische Motoren Werke AG
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Bayerische Motoren Werke AG filed Critical Bayerische Motoren Werke AG
Publication of EP4473758A1 publication Critical patent/EP4473758A1/de
Pending legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/80—Services using short range communication, e.g. near-field communication [NFC], radio-frequency identification [RFID] or low energy communication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/03—Protecting confidentiality, e.g. by encryption
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/50—Secure pairing of devices
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/30—Services specially adapted for particular environments, situations or purposes
    • H04W4/40—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P]

Definitions

  • Embodiments of the present invention relate to a method for a network component for providing Bluetooth control data, a computer program, a device and a vehicle, in particular but not exclusively to a concept for providing Bluetooth control data by synchronizing Bluetooth control data between a first user terminal and a second user terminal.
  • any user terminal can be configured through Smart Access to act as a digital key for a vehicle.
  • a digital key also known as a data key
  • the user terminal can thus be configured/authenticated in such a way that access, for example opening, starting, etc., of the vehicle is enabled via radio, for example Bluetooth or ultra-wideband technology (UWB).
  • radio for example Bluetooth or ultra-wideband technology (UWB).
  • the user terminal in order to open/start the vehicle, the user terminal must first establish a connection with the vehicle, e.g. via Bluetooth, which requires the initial establishment of a Bluetooth connection, e.g. via Bluetooth pairing.
  • the Bluetooth pairing process can generate an undesirably high data volume exchange.
  • the Bluetooth pairing process may take an inconveniently long time for a user, which may degrade a user experience.
  • the vehicle for each Bluetooth-enabled user terminal that wants to connect to the vehicle, the vehicle must first check whether there is authorization for the respective user terminal. This may unnecessarily increase power consumption of the vehicle.
  • Bluetooth control data for example Bluetooth encryption data and/or Bluetooth pairing data
  • the method, the device, the computer program and the vehicle according to the independent claims take this need into account.
  • Exemplary embodiments are based on the core idea that establishing a Bluetooth connection can be improved by Bluetooth control data, for example Bluetooth encryption data and/or Bluetooth pairing data are generated and synchronized between a first user terminal and a second user terminal.
  • Bluetooth control data for example Bluetooth encryption data and/or Bluetooth pairing data are generated and synchronized between a first user terminal and a second user terminal.
  • establishing a Bluetooth connection for the first time can be improved, e.g. B.
  • a Bluetooth pairing can be improved, for example by using the Bluetooth encryption data and / or the Bluetooth pairing data.
  • the Bluetooth pairing data means that an initial pairing can be dispensed with, for example because information required to establish a Bluetooth connection (eg a long-term key, LTK) was sent to the first user terminal and the second user terminal as a result of the synchronization.
  • LTK long-term key
  • Embodiments relate to a method for a network component including receiving information for generating Bluetooth control data for establishing an encrypted Bluetooth connection between a first user terminal and a second user terminal based on the received information. Furthermore, the method includes generating the Bluetooth control data and synchronizing the Bluetooth control data between the first user terminal and the second user terminal. As a result, establishment of a Bluetooth connection can be improved.
  • the Bluetooth control data can be Bluetooth encryption data.
  • the first user terminal can set up a Bluetooth connection to the second user terminal in a simplified form.
  • the Bluetooth encryption data can include all the necessary parameters for establishing a Bluetooth connection, so that no further exchange of information between the first user terminal and the second user terminal can be necessary to establish a Bluetooth connection.
  • establishing a Bluetooth connection for the first time which can happen at least partially unencrypted, can be improved by exchanging Bluetooth encryption data beforehand.
  • a Bluetooth pairing can be performed directly based on the Bluetooth encryption data. In this way, in particular, an information exchange based on out-of-band can be reduced and/or take place at a different point in time. As a result, security can be increased, Bluetooth connection establishment can be improved and/or data transfer can be reduced.
  • the Bluetooth control data can be Bluetooth pairing data.
  • an initial Bluetooth pairing can in particular be omitted.
  • all parameters required for a Bluetooth pairing can already be transmitted in advance to the first user terminal and the second user terminal by the synchronization.
  • the Bluetooth pairing data may include an LTK.
  • the information obtained may include an identification for at least the first user terminal or the second user terminal. In this way, in particular, an authenticated user terminal can be assigned/identified, for example a user terminal that is to be newly added and that has received a data key.
  • the network component can be an administrative platform or another user terminal.
  • an administrative platform can manage access to a vehicle and for this purpose make Bluetooth control data available to at least one user terminal and the vehicle.
  • a user terminal can manage data keys for opening the vehicle, which can be passed on to another user terminal so that it can gain access to the vehicle.
  • the first user terminal may be a vehicle.
  • a Bluetooth connection between a vehicle and a user terminal which can in particular be designed as a digital key, can be established in a simplified manner.
  • the Bluetooth control data can be generated in the vehicle.
  • the vehicle can be used without any additional infrastructure required, e.g. B. an external administrative platform, establishment of a Bluetooth connection between the vehicle and a user terminal improve.
  • the Bluetooth control data can include information about at least one parameter required for Bluetooth pairing. In this way, in particular, Bluetooth pairing between the first user terminal and the second user terminal can be improved.
  • the method may further include encrypting the Bluetooth control data for synchronization. This ensures that the Bluetooth control data cannot be read out by a third party.
  • Embodiments also provide a computer program for performing one of the methods described herein when the computer program runs on a computer, a processor, or a programmable hardware component.
  • a further exemplary embodiment is a device for a network component for providing Bluetooth control data.
  • the device includes one or more Interfaces for communication with other communication devices (e.g. the first user terminal and/or the second user terminal) and a control module which is designed to carry out at least one of the methods described herein.
  • Embodiments also provide a vehicle having a device as described herein.
  • FIG. 1 shows a schematic representation of an example of a method for providing Bluetooth control data
  • FIG. 2 shows a schematic representation of an example of a method for providing encryption data
  • FIG. 3 shows a block diagram of an embodiment of an apparatus for a network component
  • 4a and 4b show two schematic representations for the generation and exchange of Bluetooth encryption data.
  • 5a and 5b show two schematic representations for the generation and exchange of Bluetooth pairing data.
  • the method 10 includes obtaining 12 information for generating Bluetooth control data for establishing an encrypted Bluetooth connection between a first user terminal and a second user terminal based on the information obtained. Furthermore, the method 10 comprises generating 14 the Bluetooth control data and synchronizing 16 the Bluetooth control data between the first user terminal and the second user terminal.
  • the first user equipment (UE) and/or the second user equipment may be a device capable of wireless communication.
  • either the first UE or the second UE is a mobile UE, eg a UE suitable for being carried by a user.
  • the first or second UE can be, for example, a user terminal (UT) or user equipment (UE) in terms of the respective communication standards that are used for mobile communication.
  • the first or second UE can be, for example, a mobile phone, such as a smartphone, or another type of mobile communication device, such as a smart watch, a laptop, a tablet computer, autonomous augmented reality glasses, etc.
  • the first or second UE can be a digital key within the meaning of the Car Connectivity Consortium (CCC) standard.
  • CCC-TS-I01 Digital Key Technical Specification Release 3, Version 1.0.0 standard can be used for communication between the UE and the vehicle, for example as described in "Bluetooth LE Pairing & Encryption Setup Procedure", p. 347ff.
  • the generation of the Bluetooth control data can replace a known standard.
  • the in chapter 18.4.9. “Derivation of System Keys”, p. 290, described generation of the Bluetooth control data are replaced by the generation 14 of the network component.
  • the exchange of information (data) between different user terminals can be extended, for example as described in Table 19-74: 7F49 Template, S 346.
  • the exchange can be expanded in particular by synchronizing 16 the network components.
  • the network component is a backend, for example to a vehicle, an extension can be made, for example in Chapter 17.7.1.3 trackKeyResponse, p. 246, for synchronization 16 .
  • the first UE can communicate with the second UE using a wireless personal area network (WPAN), e.g. B. Bluetooth, etc. communicate.
  • WPAN wireless personal area network
  • the first UE can communicate with the second UE within the meaning of IEEE 802.15.1-2005—IEEE Standard for Information technology.
  • the synchronization 16 can in particular simplify a Bluetooth pairing and/or a password-authenticated key agreement (PAKE) authentication.
  • PAKE password-authenticated key agreement
  • the information can in particular include determining or receiving.
  • the information can be received from the first UE or the second UE.
  • the information received may differ.
  • the network component can be the first UE or the second UE.
  • the network component can be another UE.
  • the network component can be an administrative platform.
  • an administrative platform can determine the information for generating Bluetooth control data, e.g. B. based on information about renting a vehicle, in particular by checking whether payment for the rental has been made.
  • the administrative platform can therefore carry out a check before the information is determined to be generated.
  • the network component can be another UE, e.g. B. be a master device, which manages data key for access to a vehicle, such as the first UE.
  • a data key can be used to authenticate a second UE to establish a connection to the first UE.
  • the other UE can send a data key to the second UE and, for example, receive information from the second UE 12.
  • the other UE can also generate the Bluetooth control data 14 and synchronize 16 between the first UE and the second UE.
  • the synchronization 16 can then include or consist of, for example, sending the Bluetooth control data to the first UE and the second UE from the further UE.
  • the further UE can be replaced by an administrative platform, in particular for the management of a number of vehicles.
  • the network component can be the first UE, which is comprised of a vehicle, for example.
  • the vehicle or the first UE can receive information 12 from the second UE, which includes a request to use the vehicle, for example via an interposed network component, such as z. B a server.
  • the vehicle or the first UE can then generate 14 Bluetooth control data and synchronize this 16.
  • the synchronization 16 can include or consist of sending the Bluetooth control data from the first UE to the second UE.
  • the second UE for example a smartphone, can generate 14 and synchronize 16 the Bluetooth control data, in particular by sending it to the vehicle or the first UE.
  • Generating 14 the Bluetooth control data can in particular include generating all the necessary parameters for establishing a Bluetooth connection, for example required parameters from the PAKE (specifically for the owner pairing in the CCC standard) for establishing an encrypted connection, parameters from the Bluetooth pairing, etc.
  • Bluetooth encryption data and/or Bluetooth pairing data can be included in the Bluetooth encryption data.
  • the Bluetooth encryption data can relate to out-of-band communication.
  • the use of Bluetooth encryption data can simplify or even replace synchronization 16 with out-of-band communication.
  • the Bluetooth pairing data can simplify or replace an exchange of an LTK.
  • the Bluetooth control data By generating 14 the Bluetooth control data by means of the network component, these can be generated in particular on just one electronic device, for example the network component. As a result, among other things, there is no need for the first UE or the second UE to generate and transmit information that alone is not sufficient for establishing a Bluetooth connection. Furthermore, a symmetrical generation of Bluetooth control data by means of the first UE and the second UE can also be dispensed with. By receiving 12 the information and generating 14 the Bluetooth control data only by the network component, data exchange between the first UE and the second UE can thereby be reduced. In addition, a Bluetooth connection can be established in a simplified and/or improved manner.
  • Synchronizing 16 can enable a Bluetooth connection to be established between the first UE and the second UE, in particular without the need for out-of-band communication immediately before a Bluetooth connection is established for the first time.
  • a Bluetooth connection can be established for the first time without prior information being exchanged by means of out-of-band between the first UE and the second UE.
  • Bluetooth pairing can be improved, data transfer can be reduced and/or a user experience can be improved.
  • an out-of-band communication can take place in advance, so that a user does not have to carry out any further action so that a Bluetooth connection can be established for the first time. For example, there is no need to enter a PIN for the Bluetooth connection to be established.
  • a Bluetooth connection can be established between the first UE and the second UE without each UE generating its own parameters and exchanging them with the other UE.
  • a first initial Bluetooth connection can be improved or replaced by synchronizing 16 Bluetooth pairing data, for example an LTK.
  • the synchronization 16 can therefore avoid the determination of parameters required for this by the respective UE, in particular when a Bluetooth connection is first established between the first UE and in the second UE.
  • a generation of a subset of parameters for establishing a Bluetooth connection on both UEs, which requires an exchange of the subsets of parameters between the two UEs, can be replaced by synchronization 16 .
  • a symmetrical derivation of necessary parameters by both UEs based on the PAKE can be avoided.
  • a determination of an LTK can be avoided.
  • the second UE can be recognized by the first UE to be improved.
  • another UE can make a data key for the first UE available to a second UE, but not all the necessary parameters for a key exchange, ie to allow the second UE also access to the first UE. Rather, the first UE must deactivate a security protocol for the initial establishment of a Bluetooth connection to a second UE, which has received a data key, so that a connection can be established.
  • a deactivation of the security protocol can be avoided.
  • the Bluetooth control data cannot be generated by an external entity, such as an administrative platform, since these are involved in the initial establishment of the Bluetooth connection is not involved.
  • the Bluetooth control data can advantageously be generated 14 and shared or synchronized 16 by an external entity, the network component, for example an administrative platform.
  • a plurality of Bluetooth control data can be generated 14 for a plurality of user terminals, in particular by an interposed network component, such as e.g. B a backend.
  • the plurality of Bluetooth control data can then be synchronized 16 with the vehicle.
  • a plurality of Bluetooth control data can be generated 14 so that the backend for adding a new user terminal only selects Bluetooth control data that has already been generated, which in particular has already been synchronized with the vehicle.
  • the synchronization for the vehicle takes place before the synchronization for the user terminal.
  • the Bluetooth control data can be Bluetooth encryption data.
  • out-of-band communication which can be used for Bluetooth pairing, can be reduced or replaced between the first UE and the second UE.
  • the Bluetooth control data can be Bluetooth pairing data.
  • the effort involved in establishing an initial Bluetooth connection can be reduced.
  • establishing an initial Bluetooth connection can be avoided by synchronizing 16 LTK. This can change a user experience improve because in particular a waiting time until a Bluetooth connection is established between the first UE and the second UE can be reduced.
  • the received information may include an identification for at least one of the first user device and the second user device.
  • the information can include an identification for the first user device and/or the second user device.
  • the network component can be the first UE, for example comprised by a vehicle, and receive information about an identification of the second UE.
  • the vehicle can exit an energy-saving mode only after detecting a previously defined UE.
  • an attempt by a foreign UE that has no authentication for the vehicle to establish a Bluetooth connection cannot result in the vehicle ending the energy-saving mode.
  • the vehicle that is to say the first UE, can therefore in particular only end the energy-saving mode if a UE known to it, for example the second UE, is detected. This allows energy consumption of the first UE to be reduced.
  • the network component can be an administrative platform or another user terminal.
  • the additional UE can be a master device, for example, which has data keys for authenticating a UE, for example the second UE.
  • the master device can thereby provide the first UE and the second UE with all the information that is required to simplify or avoid establishing a Bluetooth connection for the first time.
  • the further UE can send the Bluetooth control data to the first UE and the second UE.
  • the further UE can send information about an identification of the first UE or second UE to the second UE or first UE.
  • the first UE can detect the second UE or the second UE can detect the first UE in a simplified manner.
  • An administrative platform can be advantageous in particular for managing a plurality of UEs, for example a plurality of first UEs (for example a number of vehicles in a car-sharing fleet).
  • the administrative platform can generate Bluetooth control data for a first UE of a plurality of UEs for the second UE. Thereby the second UE can be granted access to the first UE of the plurality of UEs.
  • the Bluetooth control data can be limited in an application, for example to a period of time, a location, usage behavior, etc.
  • the Bluetooth control data can allow a user of the second UE access to a vehicle, for example a vehicle from a car sharing fleet, which includes the first UE.
  • the Bluetooth control data can, for example, at a period of rental, a place of a rental, a number of possible uses, etc. This can prevent unwanted use of the first UE by a user of the second UE.
  • the first user terminal may be a vehicle.
  • an owner of the vehicle can have a master device, for example a smartphone, which includes at least one data key.
  • the owner can pass this data key on to a user of a second UE so that the second UE can gain access to the vehicle.
  • the master device can then provide the second UE and the first UE with all the necessary parameters for establishing a Bluetooth connection.
  • the Bluetooth control data can be generated in the vehicle.
  • the Bluetooth control data can be generated onboard.
  • the vehicle can be designed to simplify establishment of a Bluetooth connection to a UE.
  • the Bluetooth control data can be generated off-board, for example by an administrative platform or a UE.
  • the Bluetooth control data can be transmitted from the vehicle to the UE, for example by means of near-field communication, Car2x messages, etc.
  • the Bluetooth control data can include information about at least one parameter required for Bluetooth pairing.
  • the Bluetooth control data can be Bluetooth pairing data and can include an LTK.
  • the first UE and/or the second UE can receive all the parameters required for an initial Bluetooth pairing from the network component, so that this can be omitted.
  • the method 10 may further include encrypting the Bluetooth control data for synchronization. This ensures that the Bluetooth control data cannot be read by a third party.
  • the first UE and/or the second UE may be a device capable of wireless communication.
  • the first UE and/or the second UE may be a mobile user terminal, eg a user terminal suitable for being carried by a user.
  • the first UE and/or the second UE can be, for example, a user terminal (UT) or user equipment (UE) in terms of the respective communication standards that are used for mobile communication.
  • the first UE and/or the second UE can be, for example, a mobile phone, such as a smartphone, or another type of mobile communication device, such as a smart watch, a laptop, a tablet computer, autonomous augmented reality glasses, etc.
  • the network component can be, for example, a computer, a processor, a control unit, a (field) programmable logic array ((F)PLA), a (field) programmable gate array ((F)PGA), a graphics processing unit (GPU), a application specific integrated circuit (ASIC), an integrated circuit (IC) or a system on a chip (SoC).
  • the network component can be a user terminal, for example.
  • the network component can generally be a device capable of wireless communication.
  • the network component can be a device within the meaning of the respective communication standards that are used for mobile communication.
  • FIG. 1 may include one or more optional additional features corresponding to one or more aspects mentioned in connection with the proposed concept or one or more embodiments described below (e.g. Figures 2-5). .
  • FIG. 2 shows a schematic representation of an example of a method 100 for providing Bluetooth encryption data.
  • the method 100 includes obtaining 110 information for generating Bluetooth encryption data for establishing an encrypted Bluetooth connection between a first user terminal and a second user terminal based on the received information. Furthermore, the method 100 comprises generating 120 the Bluetooth encryption data and synchronizing 130 the Bluetooth encryption data between the first user terminal and the second user terminal.
  • Bluetooth can in particular include all types of Bluetooth protocols, for example Bluetooth Low Energy.
  • the first user equipment (UE) and/or the second user equipment may be a device capable of wireless communication.
  • either the first UE or the second UE is a mobile UE, eg a UE suitable for being carried by a user.
  • the first or second UE can be, for example, a user terminal (UT) or user equipment (UE) in terms of the respective communication standards that are used for mobile communication.
  • the first or second UE can be, for example, a mobile phone, such as a smartphone, or another type of mobile communication device, such as a smart watch, a laptop, a tablet computer, autonomous augmented reality glasses, etc.
  • the first or second UE can be a digital key within the meaning of the Car Connectivity Consortium (CCC) standard.
  • CCC Car Connectivity Consortium
  • the CCC-TS-101 Digital Key Technical Specification Release 3, Version 1.0.0 standard can be used for communication between the UE and the vehicle, for example as described in "Bluetooth LE Pairing & Encryption Setup Procedure", p. 347ff.
  • the generation of the Bluetooth encryption data ie the generation 120
  • the exchange of information (data) between different user terminals can be extended, for example as described in Table 19-74: 7F49 Template, S 346.
  • the exchange can be extended in particular by synchronizing 130 the network components.
  • the network component is a backend, for example to a vehicle, an extension for synchronization 130 can be made, for example in Chapter 17.7.1.3 trackKeyResponse, p.
  • the first UE can communicate with the second UE using a wireless personal area network (WPAN), e.g. B. Bluetooth, etc. communicate.
  • WPAN wireless personal area network
  • the first UE can communicate with the second UE within the meaning of IEEE 802.15.1-2005—IEEE Standard for Information technology.
  • the synchronization 130 can in particular simplify a Bluetooth pairing and/or a password-authenticated key agreement (PAKE) authentication.
  • PAKE password-authenticated key agreement
  • the information can in particular include determining or receiving.
  • the information received may differ.
  • the network component can be the first UE or the second UE.
  • the network component can be another UE.
  • the network component can be an administrative platform.
  • the network component can be another UE, e.g. B. be a master device, which manages data key for access to a vehicle, such as the first UE.
  • a data key can be used to authenticate a second UE to establish a connection to the first UE.
  • the other UE can send a data key to the second UE and, for example, receive received information from the second UE 110.
  • the other UE can also generate the Bluetooth encryption data 120 and synchronize 130 between the first UE and the second UE.
  • the synchronization 130 can then for example include or consist of sending the Bluetooth encryption data to the first UE and the second UE from the further UE.
  • the other UE by a administrative platform, in particular for the management of a large number of vehicles.
  • the network component can be the first UE, which is comprised of a vehicle, for example.
  • the vehicle or the first UE can receive information from the second UE 110, which includes a request to use the vehicle, for example via an interposed network component, such as z. B a server.
  • the vehicle or the first UE can then generate 120 Bluetooth encryption data and synchronize them 130.
  • the synchronization 130 can include or consist of sending the Bluetooth encryption data from the first UE to the second UE.
  • the second UE for example a smartphone, can generate 120 and synchronize 130 the Bluetooth encryption data, in particular by sending it to the vehicle or the first UE.
  • Generating 120 the Bluetooth encryption data can in particular include generating all the necessary parameters for establishing a Bluetooth connection, for example required parameters from the PAKE for establishing an encrypted connection, parameters from the Bluetooth pairing, etc.
  • the Bluetooth Encryption data using the network component can be generated in particular on just one electronic device. This eliminates, among other things, the generation and transmission of some parameters by the first UE or the second UE, which alone are not sufficient for establishing a Bluetooth connection.
  • a symmetrical generation of Bluetooth encryption data by means of the first UE and the second UE can also be dispensed with.
  • a data exchange between the first UE and the second UE can be reduced.
  • a Bluetooth connection can be established in a simplified and/or improved manner.
  • Synchronizing 130 can enable a Bluetooth connection to be established between the first UE and the second UE, in particular without the need for out-of-band communication, immediately before a Bluetooth connection is established for the first time.
  • a Bluetooth connection can be established for the first time without prior information being exchanged using out-of-band between the first UE and the second UE.
  • Bluetooth pairing can be improved, data transfer can be reduced and/or a user experience can be improved.
  • out-of-band communication can take place in advance, so that a user no longer has to perform any further action so that a Bluetooth connection can be established for the first time. For example, there is no need to enter a PIN for the Bluetooth connection to be established.
  • a Bluetooth connection can be established between the first UE and the second UE without each UE generating its own parameters and exchanging them with the other UE.
  • the synchronization 130 can thus avoid the determination of parameters required for this by the respective UE, in particular when a Bluetooth connection is established for the first time between the first UE and in the second UE.
  • a generation of a subset of parameters for establishing a Bluetooth connection on both UEs, which requires an exchange of the subsets of parameters between the two UEs, can be replaced by synchronization 130 .
  • a symmetrical derivation of necessary parameters by both UEs based on the PAKE can be avoided.
  • the network component that generates 120 and synchronizes 130 the Bluetooth encryption data recognition of the second UE by the first UE can be improved.
  • another UE can make a data key for the first UE available to a second UE, but not all the necessary parameters for a key exchange, ie to allow the second UE also access to the first UE. Rather, the first UE must deactivate a security protocol for the initial establishment of a Bluetooth connection to a second UE, which has received a data key, so that a connection can be established.
  • generating 120 the Bluetooth encryption data and synchronizing 130 a deactivation of the security protocol can be avoided.
  • the Bluetooth encryption data cannot be generated by an external entity, such as an administrative platform, since these are involved in the initial establishment of the Bluetooth connection is not involved.
  • the Bluetooth encryption data can advantageously be generated and shared by an external entity, the network component, for example an administrative platform.
  • the received information may include an identification for at least one of the first user device and the second user device.
  • the information can include an identification for the first user device and/or the second user device.
  • the network component can be the first UE, for example comprised by a vehicle, and receive information about an identification of the second UE.
  • the vehicle can exit an energy-saving mode only after detecting a previously defined UE.
  • an attempt by a foreign UE that has no authentication for the vehicle to establish a Bluetooth connection cannot result in the vehicle ending the energy-saving mode.
  • the vehicle that is to say the first UE, can therefore in particular only end the energy-saving mode if a UE known to it, for example the second UE, is detected. This allows energy consumption of the first UE to be reduced.
  • the network component can be an administrative platform or another user terminal.
  • the additional UE can be a master device, for example, which has data keys for authenticating a UE, for example the second UE.
  • the master device can thereby provide the first UE and the second UE with all the information that is required to simplify or avoid establishing a Bluetooth connection for the first time.
  • the further UE can send the Bluetooth encryption data to the first UE and the second UE.
  • the further UE can send information about an identification of the first UE or second UE to the second UE or first UE.
  • the first UE can detect the second UE or the second UE can detect the first UE in a simplified manner.
  • An administrative platform can be advantageous in particular for managing a plurality of UEs, for example a plurality of first UEs (for example a number of vehicles in a car-sharing fleet).
  • the administrative platform can generate Bluetooth encryption data for a first UE of a plurality of UEs for the second UE. Thereby the second UE can be granted access to the first UE of the plurality of UEs.
  • the Bluetooth encryption data can be limited in an application, for example to a period of time, a location, usage behavior, etc.
  • the Bluetooth encryption data can allow a user of the second UE access to a vehicle, for example a vehicle from a car sharing fleet, which includes the first UE.
  • the Bluetooth encryption data can be linked to a rental period, a rental location, a number of possible uses, etc., for example. This can prevent unwanted use of the first UE by a user of the second UE.
  • the first user terminal may be a vehicle.
  • an owner of the vehicle can have a master device, for example a smartphone, which includes at least one data key.
  • the owner can pass this data key on to a user of a second UE so that the second UE can gain access to the vehicle.
  • By generating 120 the Bluetooth encryption data it can The master device then provides the second UE and the first UE with all the necessary parameters for establishing a Bluetooth connection.
  • the Bluetooth encryption data can be generated in the vehicle.
  • the Bluetooth encryption data can be generated onboard.
  • the vehicle can be designed to simplify establishment of a Bluetooth connection to a UE.
  • the Bluetooth encryption data can be generated off-board, for example by an administrative platform or a UE.
  • the Bluetooth encryption data may include information about at least one parameter required for Bluetooth pairing.
  • a Bluetooth pairing between the first UE and the second UE can be improved.
  • the first UE and/or the second UE can receive all the parameters required for a Bluetooth pairing from the network component.
  • the method 100 may further include encrypting the Bluetooth encryption data for synchronization. This ensures that the Bluetooth encryption data cannot be read by a third party.
  • FIG. 2 may include one or more optional additional features corresponding to one or more aspects discussed in connection with the proposed concept or one or more embodiments described above (e.g. FIG. 1 ) and/or below (e.g. Figs. 3 - 5) have been mentioned.
  • FIG. 3 shows a block diagram of an embodiment of a device 30 for a network component.
  • the device 30 for providing Bluetooth control data comprises one or more interfaces 32 for communication with a user terminal (for example the first UE and/or the second UE).
  • the device 30 also includes a control module 34 which is designed to carry out at least one of the methods described herein, for example the method which is described with reference to FIG. 1 or FIG. 2 .
  • Further exemplary embodiments are a vehicle with a device 30.
  • the one or more interfaces 32 can, for example, have one or more inputs and/or one or more outputs for receiving and/or transmitting information correspond, e.g. in digital bit values, based on a code, within a module, between modules, or between modules of different entities.
  • the at least one or more interfaces 32 can be designed, for example, to communicate with other network components via a (radio) network or a local connection network.
  • the one or more interfaces 32 are coupled to the respective control module 34 of the device 30 .
  • device 30 may be implemented by one or more processing units, one or more processing devices, any means for processing such as a processor, a computer, or a programmable hardware component operable with appropriately adapted software.
  • the described functions of the control module 34 can also be implemented in software, which is then executed on one or more programmable hardware components.
  • Such hardware components can be a general purpose processor, a digital signal processor (DSP), a microcontroller, etc.
  • the control module 34 may be capable of controlling the one or more interfaces 32 such that any data transmission occurring over the one or more interfaces 32 and/or any interaction involving the one or more interfaces 32 may be involved , can be controlled by the control module 34.
  • control module 34 may correspond to any controller or processor or programmable hardware component.
  • the control module 34 can also be implemented as software that is programmed for a corresponding hardware component.
  • the control module 34 can be implemented as programmable hardware with appropriately adapted software.
  • Any processors, such as digital signal processors (DSPs) can be used. Exemplary embodiments are not limited to a specific type of processor. Any processors or also several processors for the implementation of the control module 34 are conceivable.
  • device 30 may include memory and at least one control module 34 operably coupled to the memory and configured to perform the method described below.
  • the one or more interfaces 32 may correspond to any means for obtaining, receiving, transmitting, or providing analog or digital signals or information, e.g. B. any port, contact, pin, register, input port, output port, conductor, trace, etc. that enables the provision or receipt of a signal or information.
  • the one or more interfaces 32 may be wireless or be wired and can be configured to communicate with other internal or external components, e.g. B. can send or receive signals or information.
  • the vehicle may correspond, for example, to a land vehicle, a watercraft, an aircraft, a rail vehicle, a road vehicle, a car, a bus, a motorcycle, an all-terrain vehicle, an automobile, or a truck.
  • the control module can be part of a control unit of the vehicle, for example.
  • the device 30 can also be used in other Bluetooth enabled electronic devices such. B. a Bluetooth speaker, a Bluetooth headset, a smartphone, etc.
  • FIG. 3 may include one or more optional additional features corresponding to one or more aspects discussed in connection with the proposed concept or one or more above (e.g. Figs. 1-2) and/or below described embodiments (z. B. Fig. 4 - 5) were mentioned.
  • FIG. 4 shows two schematic representations of the generation and exchange of Bluetooth encryption data.
  • 4a shows the prior art.
  • a symmetrical generation of required parameters takes place in FIG. 4a during the pairing process between a master device and a vehicle. These parameters must then be exchanged between the two UEs 310, 320, ie the vehicle 310 and the master device 320.
  • the master device 320 also requires further information from the vehicle 310 when the key is exchanged, so that the master device 320 can only provide all the necessary parameters to the user terminal 330 to be added after the key has been exchanged between the vehicle 310 and the master device 320 .
  • FIG. 4b shows a schematic representation of an example of a method according to the invention, for example an exemplary embodiment of a method which was described with reference to FIG.
  • the network component 340 that generates and synchronizes the Bluetooth encryption data is a vehicle backend 340.
  • the Bluetooth encryption data can be generated by the vehicle backend before an initial connection between the vehicle 310 and the user terminal to be newly added 330 trying to build for example, before performing a Bluetooth pairing.
  • the vehicle backend 340 then sends the generated Bluetooth encryption data to the vehicle 310 and the user terminal 330 to be newly added.
  • the user terminal 330 to be newly added can connect to the vehicle 310 via Bluetooth without having to set up an initial connection. For example, this can prevent a first unsecured connection before, for example, PAKE has been carried out.
  • the vehicle 310 and the user terminal 330 to be newly added can essentially synchronize the out-of-band information.
  • a Bluetooth connection can be started directly for the first time, in particular after the synchronization of the Bluetooth encryption data.
  • a Bluetooth pairing can be started without requiring a further exchange of out-of-band information between the vehicle 310 and the user terminal 330 to be added.
  • the required Bluetooth encryption data can be sent directly from the vehicle 310 to the master device 320 during a Bluetooth pairing between the master device 320 and the vehicle 310 . It may no longer be necessary for the master device 320 to generate Bluetooth encryption data.
  • the Bluetooth encryption data may be sent from the vehicle 310 to the master device 320 over a secured connection during master device pairing. It may also no longer be necessary to transmit information to the master device 320 during the key exchange.
  • the master device pairing can be used in particular to connect the master device 320 to the vehicle 310 .
  • the master device pairing can be done, for example, using WPAN, e.g. B. Bluetooth, WLAN, etc. take place.
  • the master device pairing can be done according to CCC standards, for example. For example, the standard CCC-TS-101 Digital Key Technical Specification Release 3, Version 1.0.0, Chapter 6 can be used.
  • the vehicle backend 340 can generate and synchronize new Bluetooth encryption data after each receipt of information for generating Bluetooth encryption data for establishing an encrypted Bluetooth connection between a first user terminal and a second user terminal.
  • Information received can, for example, include information about a newly generated/used data key.
  • the newly generated/used data key can in particular be generated by sharing access rights, for example by master device 320 and/or by a service data key, for example by an administrative platform such as vehicle backend 340 .
  • the vehicle backend 340 can then send this to the vehicle 310 and the user terminal 330 to be newly added.
  • the sending can in particular immediately after generating the Bluetooth encryption data takes place or as soon as a connection to the vehicle 310 and/or the user terminal 330 to be newly added can be established. This can be done, for example, by expanding the information that is sent over a secure connection during tracking of a user terminal 330 to be newly added.
  • an administrator of a car-sharing fleet can use an administrative platform to create a data key for a customer.
  • the vehicle backend 340 can be used to replace a master device 320 .
  • no master device 320 has to be present.
  • the user terminal 330 to be newly added can then receive the (service) data key from the vehicle backend 340 .
  • the (service) data key can be registered with the vehicle backend 340 .
  • the new user terminal 330 to be added can also receive the Bluetooth encryption data generated by the vehicle backend 340, for example at the same time as the (service) data key.
  • the vehicle 310 may receive the same Bluetooth encryption data.
  • the vehicle 310 can also receive the information about the (service) data key, or information that allows identification of the user terminal 330 to be newly added. This can then improve a first initial connection for a Bluetooth connection.
  • a user of a master device 320 may wish to allow a friend access to their vehicle 310 .
  • the user can use his master device 320 to send a data key to his friend's user terminal 330 to be newly added.
  • the data key can then be registered with the vehicle backend 340 .
  • the user terminal 330 to be newly added can receive the Bluetooth encryption data generated by the vehicle backend 340 .
  • the receipt of the data key can be separated from the receipt of the Bluetooth encryption data.
  • the master device 320 can also generate the Bluetooth encryption data. In this case, no vehicle backend 340 may then be present.
  • FIG. 5 shows two schematic representations of the generation and exchange of Bluetooth encryption data.
  • 5a shows the prior art.
  • the LTK is only negotiated after a first initial connection has been established between vehicle 310 and new UE 330, for example a first establishment of a Bluetooth connection has taken place. This creates unnecessary waiting times for a user of the new UE 330, which can degrade the user experience.
  • FIG. 5b shows a schematic representation of an example of a method according to the invention, for example an exemplary embodiment of a method which was described with reference to FIG.
  • the network component 340 that generates and synchronizes the Bluetooth control data is a vehicle backend 340.
  • the vehicle backend 340 generates Bluetooth pairing data, in particular comprising an LTK.
  • the Bluetooth control data can be generated by the vehicle backend before an initial connection is attempted to be established between the vehicle 310 and the user terminal 330 to be newly added, for example before a Bluetooth pairing is carried out.
  • establishing an initial Bluetooth connection by means of Bluetooth pairing can be avoided or replaced by generating and synchronizing the Bluetooth control data.
  • the vehicle backend 340 can then send the generated Bluetooth control data to the vehicle 310 and the user terminal 330 to be newly added.
  • the user terminal 330 to be newly added can connect to the vehicle 310 via Bluetooth without having to set up an initial connection, in particular without having to set up an initial Bluetooth connection, since an LTK can already be known.
  • an LTK can be synchronized directly between the vehicle 310 and the new user terminal 330 in this way.
  • a Bluetooth pairing process in particular a Bluetooth low-energy pairing process, can already be omitted when the vehicle 310 makes initial contact with the new user terminal 330 .
  • a user experience can be increased as a result.
  • a user experience upon initial contact with the vehicle can be adversely affected if the Bluetooth pairing process causes a delay in the process (e.g. unlocking the vehicle). This delay can be avoided by synchronizing the LTK beforehand.
  • a persistence of both communication partners, the vehicle 310 and the user terminal 330, of an LTK, in order to be able to establish a secure connection directly with subsequent contacts can be omitted after a Bluetooth pairing.
  • the vehicle 310 and the user terminal 330 to be newly added can essentially synchronize all information required for a Bluetooth connection.
  • the Bluetooth control data Bluetooth pairing data
  • the vehicle 310 and the new user terminal 330 can thus set up a Bluetooth connection directly. For example, persisting an LTK after Bluetooth pairing may not be necessary.
  • the required Bluetooth control data can be sent directly from the vehicle 310 to the master device 320 during a Bluetooth pairing between the master device 320 and the vehicle 310 .
  • Generation of Bluetooth control data (Bluetooth pairing data) by the master device, the vehicle 310 and the new user terminal 330 may no longer be necessary.
  • the vehicle backend 340 can generate and synchronize new Bluetooth encryption data after each receipt of information for generating Bluetooth encryption data for establishing an encrypted Bluetooth connection between a first user terminal and a second user terminal.
  • Information received can include information about a newly generated/used data key, for example.
  • the newly generated/used data key can in particular be generated by sharing access rights, for example by master device 320 and/or by a service data key, for example by an administrative platform such as vehicle backend 340 .
  • the vehicle backend 340 can then send this to the vehicle 310 and the user terminal 330 to be newly added.
  • the sending can take place in particular immediately after the generation of the Bluetooth encryption data or as soon as a connection to the vehicle 310 and/or the user terminal 330 to be newly added can be established. This can be done, for example, by expanding the information that is sent over a secure connection during tracking of a user terminal 330 to be newly added.
  • the Bluetooth control data can be defined as follows: IRK: o Used to resolve the vehicle's ADV_IND.
  • BT ADDR CAR o optional o Uses Bluetooth connection for establishment.
  • LTK o Used for a secure (transmission) channel.
  • Bluetooth control data can be synchronized between a vehicle backend and a vehicle before master device pairing.
  • the generation of the control data and the synchronization can take place according to one of the methods described above, for example as described with reference to FIG. 1 or FIG. 2 .
  • tag 0xD5 may be presented during master device pairing.
  • the tag may include an LTK determined in [OBLE-OOI].
  • tag 0xD5 may be presented during master device pairing.
  • the tag may include an LTK determined in [OBLE-OOI].
  • FIG. 5 may include one or more optional additional features corresponding to one or more aspects mentioned in connection with the proposed concept or one or more embodiments described above (e.g. Figures 1-4). .
  • FIG. 1 For exemplary embodiments, are computer programs for carrying out one of the methods described herein when the computer program runs on a computer, a processor or a programmable hardware component.
  • embodiments of the invention may be implemented in hardware or in software. Implementation may be performed using a digital storage medium such as a floppy disk, DVD, Blu-ray Disc, CD, ROM, PROM, EPROM, EEPROM or FLASH memory, hard disk or other magnetic or optical memory are performed on the electronically readable control signals are stored with a programmable Hardware components can interact in such a way or interact that the respective method is carried out.
  • CPU central processing unit
  • GPU graphics processing unit
  • ASIC application-specific integrated circuit
  • IC integrated Circuit
  • SOC System on Chip
  • FPGA Field Programmable Gate Array
  • the digital storage medium can therefore be machine or computer readable.
  • Some embodiments thus include a data carrier that has electronically readable control signals that are able to interact with a programmable computer system or a programmable hardware component in such a way that one of the methods described herein is carried out.
  • An embodiment is thus a data carrier (or a digital storage medium or a computer-readable medium) on which the program for performing one of the methods described herein is recorded.
  • embodiments of the present invention can be implemented as a program, firmware, computer program or computer program product with a program code or as data, the program code or the data being effective to carry out one of the methods when the program runs on a processor or a programmable hardware component expires.
  • the program code or the data can also be stored, for example, on a machine-readable carrier or data carrier.
  • the program code or data may be in the form of source code, machine code or byte code, as well as other intermediate code, among others.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Small-Scale Networks (AREA)

Abstract

Ausführungsbeispiele der vorliegenden Erfindung schaffen ein Verfahren (10) für eine Netzwerkkomponente umfassend Erhalten (12) einer Information zum Generieren von Bluetooth-Kontrolldaten zur Etablierung einer verschlüsselten Bluetooth-Verbindung zwischen einem ersten Benutzerendgerät und einem zweiten Benutzerendgerät basierend auf der empfangenen Information. Ferner umfasst das Verfahren Generieren (14) der Bluetooth-Kontrolldaten und Synchronisieren (16) der Bluetooth-Kontrolldaten zwischen dem ersten Benutzerendgerät und dem zweiten Benutzerendgerät.

Description

Verfahren für eine Netzwerkkomponente zum Bereitstellen von Bluetooth-Kontrolldaten, Computerprogramm, Vorrichtung und Fahrzeug
Beschreibung
Ausführungsbeispiele der vorliegenden Erfindung beziehen sich auf ein Verfahren für eine Netzwerkkomponente zum Bereitstellen von Bluetooth-Kontrolldaten, ein Computerprogramm, eine Vorrichtung und ein Fahrzeug, insbesondere aber nicht ausschließlich auf ein Konzept zum Bereitstellen von Bluetooth-Kontrolldaten durch Synchronisation von Bluetooth-Kontrolldaten zwischen einem ersten Benutzerendgerät und einem zweiten Benutzerendgerät.
Die Verwendung von Digital Keys ermöglicht es einem Nutzer eines Fahrzeugs dieses besonders einfach zu öffnen. Insbesondere kann durch einen Smart Access jedes Benutzerendgerät dazu konfiguriert werden, als Digital Key für ein Fahrzeug zu fungieren. Hierzu kann für die Konfiguration eines neuen Benutzerendgeräts ein digitaler Schlüssel, auch Datenschlüssel genannt, an ein Benutzerendgerät weitergegeben werden, bspw. von dem Fahrzeug. Damit kann das Benutzerendgerät derart konfiguriert/authentifiziert werden, dass ein Zugang, beispielsweise ein Öffnen, Starten, etc. des Fahrzeugs über Funk, bspw. Bluetooth oder Ultra-Breitband-Technologie (UWB) ermöglicht wird. Zum Öffhen/Starten des Fahrzeugs muss das Benutzerendgerät jedoch zuerst eine Verbindung mit dem Fahrzeug herstellen, bspw. über Bluetooth, wofür eine erstmalige Etablierung einer Bluetooth-Verbindung, beispielsweise über Bluetooth-Pairing erforderlich ist. Der Prozess des Bluetooth-Pairing kann hierbei ein/en ungewünscht/en hohes DatenvolumenZ-austausch erzeugen. Außerdem kann der Prozess des Bluetooth-Pairings eine für einen Nutzer unangenehm lange Zeitspanne beanspruchen, wodurch eine Nutzererfahrung verschlechtert werden kann. Ferner muss das Fahrzeug für jedes bluetoothfähige Benutzerendgerät, welches sich mit dem Fahrzeug verbinden möchte, erst überprüfen, ob eine Berechtigung für das jeweilige Benutzerendgerät vorliegt. Dies kann einen Energieverbrauch des Fahrzeugs unnötig erhöhen.
Es besteht daher ein Bedarf daran, eine Generierung von Bluetooth-Kontrolldaten, beispielsweise Bluetooth-Verschlüsselungsdaten und/oder Bluetooth-Pairingdaten, und deren Synchronisation zwischen einem ersten Benutzerendgerät und einem zweiten Benutzerendgerät, bereitzustellen. Diesem Bedarf tragen das Verfahren, die Vorrichtung, das Computerprogramm, sowie das Fahrzeug nach den unabhängigen Ansprüchen Rechnung.
Ausführungsbeispiele basieren auf dem Kemgedanken, dass eine Etablierung einer Bluetooth- Verbindung verbessert werden kann, indem Bluetooth-Kontrolldaten, beispielsweise Bluetooth- Verschlüsselungsdaten und/oder Bluetooth-Pairingdaten, generiert werden und zwischen einem ersten Benutzerendgerät und einem zweiten Benutzerendgerät synchronisiert werden. Dadurch kann beispielsweise eine erstmalige Etablierung eine Bluetooth-Verbindung verbessert werden, z. B. kann ein Bluetooth-Pairing verbessert werden, beispielsweise durch Verwendung der Bluetooth- Verschlüsselungsdaten und/oder der Bluetooth-Pairingdaten. Ferner kann durch die Bluetooth- Pairingdaten ein initiales Pairing entfallen, beispielsweise weil eine benötigte Information zur Etablierung einer Bluetooth -Verbindung (z. B. ein Long-Term-Key, LTK) dem ersten Benutzerendgerät und dem zweiten Benutzerendgerät durch die Synchronisation gesendet wurden.
Ausführungsbeispiele betreffen ein Verfahren für eine Netzwerkkomponente umfassend Erhalten einer Information zum Generieren von Bluetooth-Kontrolldaten zur Etablierung einer verschlüsselten Bluetooth-Verbindung zwischen einem ersten Benutzerendgerät und einem zweiten Benutzerendgerät basierend auf der empfangenen Information. Ferner umfasst das Verfahren Generieren der Bluetooth-Kontrolldaten und Synchronisieren der Bluetooth-Kontrolldaten zwischen dem ersten Benutzerendgerät und dem zweiten Benutzerendgerät. Dadurch kann ein Aufbau einer Bluetooth-Verbindung verbessert werden.
In einem Ausführungsbeispiel können die Bluetooth-Kontrolldaten Bluetooth- Verschlüsselungsdaten sein. Dadurch kann das erste Benutzerendgerät zu dem zweiten Benutzerendgerät in vereinfachter Form eine Bluetooth-Verbindung aufbauen. Insbesondere können die Bluetooth-Verschlüsselungsdaten alle notwendigen Parameter zur Etablierung einer Bluetooth- Verbindung umfassen, so dass kein weiterer Informationsaustausch zwischen dem ersten Benutzerendgerät und dem zweiten Benutzerendgerät zur Etablierung einer Bluetooth-Verbindung notwendig sein kann. Insbesondere kann ein erstmaliges Etablieren einer Bluetooth-Verbindung, welches zumindest teilweise unverschlüsselt passieren kann, durch einen vorherigen Austausch von Bluetooth-Verschlüsselungsdaten verbessert werden. Insbesondere kann ein Bluetooth-Pairing unmittelbar basierend auf den Bluetooth-Verschlüsselungsdaten durchgeführt werden. Dadurch kann insbesondere ein Informationsaustausch basierend auf out-of-band reduziert werden und/oder zu einem anderen Zeitpunkt erfolgen. Hierdurch kann eine Sicherheit erhöht, ein Bluetooth- Verbindungsaufbau verbessert und/oder ein Datentransfer reduziert werden.
In einem Ausführungsbeispiel können die Bluetooth-Kontrolldaten Bluetooth-Pairingdaten sein. Durch Verwendung der Bluetooth-Pairingdaten kann insbesondere ein initiales Bluetooth-Pairing entfallen. Insbesondere können alle für ein Bluetooth-Pairing benötigten Parameter durch die Synchronisation bereits im vomerein an das erste Benutzerendgerät und das zweite Benutzerendgerät übermittelt werden. Beispielsweise können die Bluetooth-Pairingdaten einen LTK umfassen. In einem Ausfühmngsbeispiel kann die erhaltene Information eine Identifikation für zumindest das erste Benutzerendgerät oder das zweite Benutzerendgerät umfassen. Dadurch kann insbesondere eine Zuordnung/Erkennung eines authentifizierten Benutzerendgeräts erfolgen, beispielsweise eines neu hinzuzufugenden Benutzerendgeräts, das einen Datenschlüssel erhalten hat.
In einem Ausführungsbeispiel kann die Netzwerkkomponente eine administrative Plattform oder ein weiteres Benutzerendgerät sein. Beispielsweise kann eine administrative Plattform einen Zugang zu einem Fahrzeug verwalten und hierfür mindestens einem Benutzerendgerät und dem Fahrzeug Bluetooth-Kontrolldaten zur Verfügung stellen. Beispiel kann ein Benutzerendgerät Datenschlüssel zum Öffnen des Fahrzeugs verwalten, welche an ein weiteres Benutzerendgerät weitergegeben werden können, damit dieses Zugang zu dem Fahrzeug erlangen kann.
In einem Ausführungsbeispiel kann das erste Benutzerendgerät ein Fahrzeug sein. Dadurch kann insbesondere eine Bluetooth -Verbindung zwischen einem Fahrzeug mit einem Benutzerendgerät, das insbesondere als Digital Key ausgebildet sein kann, vereinfacht etabliert werden.
In einem Ausführungsbeispiel können die Bluetooth-Kontrolldaten im Fahrzeug generiert werden. Dadurch kann insbesondere das Fahrzeug ohne weitere benötigte Infrastruktur, wie z. B. eine externe administrative Plattform, eine Etablierung einer Bluetooth-Verbindung zwischen dem Fahrzeug und einem Benutzerendgerät verbessern.
In einem Ausführungsbeispiel können die Bluetooth-Kontrolldaten Informationen über zumindest einen für ein Bluetooth-Pairing benötigten Parameter umfassen. Dadurch kann insbesondere ein Bluetooth-Pairing zwischen dem ersten Benutzerendgerät und dem zweiten Benutzerendgerät verbessert werden.
In einem Ausführungsbeispiel kann das Verfahren ferner umfassen Verschlüsseln der Bluetooth- Kontrolldaten zur Synchronisierung. Dadurch kann sichergestellt werden, dass die Bluetooth- Kontrolldaten nicht durch eine dritte Instanz ausgelesen werden können.
Ausführungsbeispiele schaffen auch ein Computerprogramm zur Durchführung eines der hierin beschriebenen Verfahren, wenn das Computerprogramm auf einem Computer, einem Prozessor, oder einer programmierbaren Hardwarekomponente abläuft.
Ein weiteres Ausführungsbeispiel ist eine Vorrichtung für eine Netzwerkkomponente zum Bereitstellen von Bluetooth-Kontrolldaten. Die Vorrichtung umfasst eine oder mehrere Schnitstellen zur Kommunikation mit anderen Kommunikationseinrichtungen (z. B. dem ersten Benutzerendgerät und/oder dem zweiten Benutzerendgerät) und ein Kontrollmodul, das zur Durchführung zumindest eines der hierin beschriebenen Verfahren ausgebildet ist. Ausführungsbeispiele schaffen darüber hinaus ein Fahrzeug mit einer Vorrichtung wie hierin beschrieben.
Ausführungsbeispiele werden nachfolgend bezugnehmend auf die beiliegenden Figuren näher erläutert:
Fig. 1 zeigt eine schematische Darstellung eines Beispiels eines Verfahrens zum Bereitstellen von Bluetooth-Kontrolldaten;
Fig. 2 zeigt eine schematische Darstellung eines Beispiels eines Verfahrens zum Bereitstellen von V erschlüsselungsdaten ;
Fig. 3 zeigt ein Blockdiagram eines Ausführungsbeispiels einer Vorrichtung für eine Netzwerkkomponente; und
Fig. 4a und Fig. 4b zeigen zwei schematische Darstellung zur Generierung und zum Austausch von Bluetooth-Verschlüsselungsdaten.
Fig. 5a und Fig. 5b zeigen zwei schematische Darstellung zur Generierung und zum Austausch von Bluetooth-Pairingdaten.
Verschiedene Ausführungsbeispiele werden nun ausführlicher unter Bezugnahme auf die beiliegenden Zeichnungen beschrieben, in denen einige Ausführungsbeispiele dargestellt sind. In den Figuren können die Dickenabmessungen von Linien, Schichten und/oder Regionen um der Deutlichkeit Willen übertrieben dargestellt sein.
Fig. 1 zeigt eine schematische Darstellung eines Beispiels eines Verfahrens 10 zum Bereitstellen von Bluetooth-Kontrolldaten. Das Verfahren 10 umfasst Erhalten 12 einer Information zum Generieren von Bluetooth-Kontrolldaten zur Etablierung einer verschlüsselten Bluetooth-Verbindung zwischen einem ersten Benutzerendgerät und einem zweiten Benutzerendgerät basierend auf der erhaltenen Information. Ferner umfasst das Verfahren 10 Generieren 14 der Bluetooth-Kontrolldaten und Synchronisieren 16 der Bluetooth-Kontrolldaten zwischen dem ersten Benutzerendgerät und dem zweiten Benutzerendgerät. Das erste Benutzerendgerät (UE) und/oder das zweite Benutzerendgerät kann im Allgemeinen ein Gerät sein, das in der Lage ist, drahtlos zu kommunizieren. Insbesondere ist entweder das erste UE oder das zweite UE ein mobiles UE, z.B. ein UE, das geeignet ist, von einem Nutzer mitgeführt zu werden. Das erste oder zweite UE kann z.B. ein User Terminal (UT) oder User Equipment (UE) im Sinne der jeweiligen Kommunikationsstandards sein, die für die mobile Kommunikation verwendet werden. Bei dem ersten oder zweiten UE kann es sich beispielsweise um ein Mobiltelefon, wie ein Smartphone, oder eine andere Art von mobilem Kommunikationsgerät, wie eine Smartwatch, einen Laptop, einen Tablet-Computer, eine autonome Augmented-Reality-Brille, etc. handeln. Insbesondere kann das erste oder zweite UE ein Digital Key im Sinne des Car Connectivity Consortium (CCC) Standards sein. Beispielsweise kann der Standard CCC-TS-I01 Digital Key Technical Specification Release 3, Version 1.0.0 zur Kommunikation zwischen UE und Fahrzeug verwendet werden, beispielsweise wie in “Bluetooth LE Pairing & Encryption Setup Procedure”, S. 347ff beschrieben. Insbesondere die Generierung der Bluetooth-Kontrolldaten, also das Generieren 14, kann einen bekannten Standard ersetzen. Beispielsweise kann die in Kapitel 18.4.9. “Derivation of System Keys”, S. 290, beschriebene Generierung der Bluetooth-Kontrolldaten ersetzt werden durch das Generieren 14 der Netzwerkkomponente. Ferner kann der Austausch von Informationen (Daten) zwischen verschiedenen Benutzerendgeräten erweitert werden, beispielsweise wie er in Tabelle 19-74: 7F49 Template, S 346, beschrieben ist. Der Austausch kann insbesondere durch das Synchronisieren 16 der Netzwerkkomponenten erweitert werden. Außerdem kann für den Fall, dass die Netzwerkkomponente ein Backend, beispielsweise zu einem Fahrzeug, ist, eine Erweiterung beispielsweise in Kapitel 17.7.1.3 trackKeyResponse, S. 246, für das Synchronisieren 16 vorgenommen werden.
Insbesondere kann das erste UE mit dem zweiten UE mittels eines Wireless Personal Area Networks (WPAN), z. B. Bluetooth, etc. kommunizieren. Insbesondere kann das erste UE mit dem zweiten UE im Sinne des IEEE 802.15.1-2005 - IEEE Standard for Information technology kommunizieren. Durch das Synchronisieren 16 kann dabei insbesondere ein Bluetooth-Pairing und/oder eine password-authenticated key agreement (PAKE)-Authentifizierung vereinfacht werden.
Erhalten 12 der Information kann insbesondere ein Bestimmen oder ein Empfangen umfassen. Beispielsweise kann die Information von dem ersten UE oder dem zweiten UE empfangen werden. Abhängig von der jeweiligen Funktion der Netzwerkkomponente kann die erhaltene Information verschieden sein. Beispielsweise kann die Netzwerkkomponente das erste UE oder das zweite UE sein. Alternativ kann die Netzwerkkomponente ein weiteres UE sein. Alternativ kann die Netzwerkkomponente eine administrative Plattform sein. Beispielsweise kann eine administrative Plattform die Information zum Generieren von Bluetooth-Kontrolldaten bestimmen, z. B. basierend auf einer Information über eine Anmietung eines Fahrzeugs, insbesondere durch Überprüfung, ob eine Zahlung fur die Anmietung erfolgt ist. Beispielsweise kann die administrative Plattform also eine Kontrolle durchfuhren, bevor die Information zum Generieren bestimmt wird.
Beispielsweise kann die Netzwerkkomponente ein weiteres UE, z. B. eine Mastergerät sein, welches Datenschlüssel für den Zugang zu einem Fahrzeug, beispielsweise dem ersten UE, verwaltet. Insbesondere kann durch einen Datenschlüssel ein zweites UE dazu authentifiziert werden, eine Verbindung zu dem ersten UE herzustellen. Das weitere UE kann einen Datenschlüssel an das zweite UE senden und beispielsweise eine Empfangsinformation von dem zweiten UE Erhalten 12. Das weitere UE kann ferner die Bluetooth-Kontrolldaten Generieren 14 und zwischen dem ersten UE und dem zweiten UE Synchronisieren 16. Das Synchronisieren 16 kann dann beispielsweise ein Senden der Bluetooth-Kontrolldaten an das erste UE und das zweite UE von dem weiteren UE umfassen oder daraus bestehen. Alternativ kann das weitere UE durch eine administrative Plattform, insbesondere für die Verwaltung einer Mehrzahl an Fahrzeugen, ersetzt werden.
Beispielsweise kann die Netzwerkkomponente das erste UE sein, das beispielsweise von einem Fahrzeug umfasst ist. Das Fahrzeug bzw. das erste UE kann von dem zweiten UE eine Information erhalten 12, welche eine Anfrage zur Benutzung des Fahrzeugs umfasst, beispielsweise über eine zwischengeschaltete Netzwerkkomponente, wie z. B einen Server. Das Fahrzeug bzw. das erste UE kann dann Bluetooth-Kontrolldaten Generieren 14 und dieses Synchronisieren 16. Das Synchronisieren 16 kann ein Senden der Bluetooth -Kontrolldaten von dem ersten UE an das zweite UE umfassen oder daraus bestehen. Alternativ kann das zweite UE, beispielsweise ein Smartphone, die Bluetooth -Kontrolldaten Generieren 14 und Synchronisieren 16, insbesondere durch Senden an das Fahrzeug bzw. das erste UE.
Generieren 14 der Bluetooth-Kontrolldaten kann insbesondere ein Generieren von allen notwendigen Parametern zur Etablierung einer Bluetooth-Verbindung umfassen, beispielsweise benötigte Parameter aus dem PAKE (spezifisch für das Owner Pairing im CCC-Standard) zur Etablierung einer verschlüsselten Verbindung, Parameter aus dem Bluetooth-Pairing, etc. Insbesondere können Bluetooth-Verschlüsselungsdaten und/oder Bluetooth-Pairingdaten von den Bluetooth-Verschlüsselungsdaten umfasst sein. Insbesondere können die Bluetooth- Verschlüsselungsdaten eine out-of-band-Kommunikation betreffen. Beispielsweise kann die Verwendung der Bluetooth -Verschlüsselungsdaten eine out-of-band-Kommunikation vereinfachen oder sogar durch das Synchronisieren 16 ersetzen. Insbesondere können die Bluetooth-Pairingdaten einen Austausch eines LTK vereinfachen oder ersetzen. Dadurch kann eine initiale Bluetooth- Verbindung vereinfacht hergestellt werden, wodurch beispielsweise eine Wartezeit für einen Nutzer für einen Aufbau einer Bluetooth-Verbindung verkürzt werden kann. Durch die Generierung 14 der Bluetooth-Kontrolldaten mittels der Netzwerkkomponente können diese insbesondere auf lediglich einer elektronischen Vorrichtung generiert werden, beispielsweise der Netzwerkkomponente generiert 14 werden. Dadurch kann unter anderem eine Generierung und Übertragung von einer Information entfallen, welche allein nicht hinreichend ist für die Etablierung einer Bluetooth -Verbindung, durch das erste UE oder das zweite UE. Ferner kann auch auf eine symmetrische Generierung von Bluetooth-Kontrolldaten mittels des ersten UE und des zweiten UE verzichtet werden. Durch Erhalten 12 der Information und das Generieren 14 der Bluetooth- Kontrolldaten lediglich durch die Netzwerkkomponente, kann dadurch ein Datenaustausch zwischen dem ersten UE und dem zweiten UE verringert werden. Außerdem kann eine Bluetooth-Verbindung vereinfacht und/oder verbessert hergestellt werden.
Synchronisieren 16 kann einen Aufbau einer Bluetooth-Verbindung zwischen dem ersten UE und dem zweiten UE, insbesondere ohne eine Notwendigkeit einer out-of-band-Kommunikation, unmittelbar vor einer erstmaligen Etablierung einer Bluetooth-Verbindung, ermöglichen. Ferner kann Beispielsweise kann eine erstmalige Etablierung einer Bluetooth-Verbindung gestartet werden, ohne dass ein vorheriger Informationsaustausch mittels out-of-band zwischen dem ersten UE und dem zweiten UE erfolgt. Dadurch kann insbesondere ein Bluetooth-Pairing verbessert werden, ein Datentransfer reduziert und/oder eine Nutzererfahrung verbessert werden. Beispielsweise kann eine out-of-band Kommunikation vorab erfolgen, sodass ein Nutzer keine weitere Aktion mehr ausfuhren muss, damit eine erstmalige Etablierung einer Bluetooth-Verbindung erfolgen kann. Beispielsweise kann auf die Eingabe einer PIN für die zu Etablierende Bluetooth-Verbindung verzichtet werden. Außerdem kann eine Bluetooth-Verbindung zwischen dem ersten UE und dem zweiten UE aufgebaut werden, ohne dass jedes UE seine eigenen Parameter generiert und mit dem anderen UE austauscht. Ferner kann durch ein Synchronisieren 16 von Bluetooth-Pairingdaten, beispielsweise eines LTK, eine erste initiale Bluetooth-Verbindung verbessert oder ersetzt werden.
Durch das Synchronisieren 16 kann also insbesondere bei der erstmaligen Etablierung einer Bluetooth-Verbindung zwischen dem ersten UE und im zweiten UE die Bestimmung hierfür notwendiger Parameter durch das jeweilige UE vermieden werden. Insbesondere kann dadurch eine Generierung eines Teilsatzes an Parametern zur Etablierung einer Bluetooth-Verbindung auf beiden UE, welche einen Austausch der Teilsätze an Parametern zwischen den beiden UE erfordert, durch das Synchronisieren 16 ersetzt werden. Insbesondere kann eine symmetrische Ableitung von notwendigen Parametern durch beide UE basierend auf dem PAKE vermieden werden. Insbesondere kann eine Bestimmung eines LTK vermieden werden.
Außerdem kann durch die Verwendung der Netzwerkkomponente, welche die Bluetooth- Kontrolldaten generiert 14 und synchronisiert 16, eine Erkennung des zweiten UE durch das erste UE verbessert werden. Beispielsweise kann in einem alternativen System ein weiteres UE beispielsweise einem zweiten UE einen Datenschlüssel für das erste UE zur Verfügung stellen, jedoch nicht alle notwendigen Parameter für einen Schlüsseltausch, also um dem zweiten UE auch einen Zugang zu dem ersten UE zu ermöglichen. Vielmehr muss das erste UE für eine erstmalige Etablierung einer Bluetooth-Verbindung zu einem zweiten UE, welches einen Datenschlüssel erhalten hat, ein Sicherheitsprotokoll deaktivieren, damit eine Verbindung hergestellt werden kann. Durch das Generieren 14 der Bluetooth-Kontrolldaten und das Synchronisieren 16 kann eine Deaktivierung des Sicherheitsprotokoll vermieden werden.
Ferner können in einem alternativen System, bei dem notwendige Parameter während der erstmaligen Etablierung einer Bluetooth-Verbindung generiert werden, die Bluetooth-Kontrolldaten nicht durch eine externe Instanz, beispielsweise eine administrative Plattform, generiert werden, da diese an der erstmaligen Etablierung der Bluetooth-Verbindung nicht beteiligt ist. Durch das Generieren 14 und das Synchronisieren 16 können die Bluetooth-Kontrolldaten vorteilhaft durch eine externe Instanz, die Netzwerkkomponente, beispielsweise eine administrative Plattform, generiert 14 und geteilt bzw. synchronisiert 16 werden.
Beispielsweise kann eine Mehrzahl an Bluetooth-Kontrolldaten für eine Mehrzahl an Benutzerendgeräten generiert 14 werden, insbesondere durch eine zwischengeschaltete Netzwerkkomponente, wie z. B ein Backend. Die Mehrzahl an Bluetooth-Kontrolldaten kann dann mit dem Fahrzeug synchronisiert 16 werden. Dadurch kann das Backend an eine Mehrzahl an Benutzerendgeräten Bluetooth-Kontrolldaten synchronisieren 16, ohne eine Notwendigkeit jedes Mal eine Synchronisation mit dem Fahrzeug durchzuführen. Beispielsweise kann eine Mehrzahl an Bluetooth-Kontrolldaten generiert 14 werden, so dass das Backend für ein hinzufügen eines neuen Benutzerendgeräts lediglich schon generierte Bluetooth-Kontrolldaten auswählt, welche insbesondere bereits mit dem Fahrzeug synchronisiert sind. Beispielsweise erfolgt die Synchronisierung für das Fahrzeug also vor der Synchronisierung für das Benutzerendgerät.
In einem Ausführungsbeispiel können die Bluetooth-Kontrolldaten Bluetooth- Verschlüsselungsdaten sind. Dadurch kann insbesondere eine out-of-band Kommunikation, welche für eine Bluetooth-Pairing verwendet werden kann, zwischen dem ersten UE und dem zweiten UE reduziert oder ersetzt werden.
In einem Ausführungsbeispiel können die Bluetooth-Kontrolldaten Bluetooth-Pairingdaten sind. Dadurch kann insbesondere ein Aufwand für eine Etablierung einer initialen Bluetooth-Verbindung reduziert werden. Insbesondere kann durch eine Synchronisierung 16 von LTK eine Etablierung einer initialen Bluetooth-Verbindung vermieden werden. Dadurch kann sich eine Nutzererfahrung verbessern, weil insbesondere eine Wartezeit, bis eine Bluetooth-Verbindung zwischen dem ersten UE und dem zweiten UE etabliert ist, reduziert werden kann.
In einem Ausführungsbeispiel kann die empfangene Information eine Identifikation für zumindest das erste Benutzergerät oder das zweite Benutzergerät umfassen. Insbesondere kann die Information eine Identifikation für das erste Benutzergerätes und/oder das zweite Benutzerendgerät umfassen. Beispielsweise kann die Netzwerkkomponente das erste UE sein, beispielsweise umfasst von einem Fahrzeug, und eine Information über eine Identifikation des zweiten UE erhalten. Dadurch kann das Fahrzeug einen Energiesparmodus nur nach Detektion eines vorher definierten UE verlassen. Insbesondere kann dadurch ein Versuch eines fremden UE, welches keine Authentifizierung für das Fahrzeug aufweist, eine Bluetooth-Verbindung zu etablieren, nicht dazu führen, dass das Fahrzeug den Energie sparmodus beendet. Das Fahrzeug, also das erste UE, kann also insbesondere nur dann den Energie sparmodus beenden, wenn ein ihm bekanntes UE, zum Beispiel das zweite UE, detektiert wird. Dadurch lässt sich ein Energieverbrauch des ersten UE reduzieren.
In einem Ausführungsbeispiel kann die Netzwerkkomponente eine administrative Plattform oder ein weiteres Benutzerendgerät sein. Das weitere UE kann beispielsweise ein Mastergerät sein, welches Datenschlüssel zur Authentifizierung eines UE, beispielsweise des zweiten UE, aufweist. Insbesondere kann das Mastergerät dadurch dem ersten UE und dem zweiten UE sämtliche Informationen zur Verfügung stellen, die benötigt werden, um eine erste Etablierung einer Bluetooth-Verbindung zu vereinfachen oder zu vermeiden. Beispielsweise kann das weitere UE die Bluetooth-Kontrolldaten an das erste UE und das zweiten UE senden. Optional kann das weitere UE eine Information über eine Identifikation des ersten UE bzw. zweiten UE an das zweite UE bzw. erste UE senden. Dadurch kann das erste UE das zweite UE bzw. das zweite UE das erste UE vereinfacht detektieren.
Eine administrative Plattform kann insbesondere für eine Verwaltung einer Mehrzahl an UE, beispielsweise eine Mehrzahl an ersten UE (beispielsweise mehrere Fahrzeuge einer Carsharing- Flotte), vorteilhaft sein. Die administrative Plattform kann beispielsweise Bluetooth-Kontrolldaten für ein erstes UE einer Mehrzahl an UE für das zweite UE generieren. Dadurch kann dem zweiten UE ein Zugang zu dem ersten UE der Mehrzahl an UE gewährt werden.
Insbesondere können die Bluetooth-Kontrolldaten in einer Anwendung beschränkt sein, beispielsweise auf einen Zeitraum, einen Ort, ein Nutzungsverhalten, etc. Beispielsweise können die Bluetooth-Kontrolldaten einen Nutzer des zweiten UE Zugang zu einem Fahrzeug, beispielsweise ein Fahrzeug aus einer Carsharing-Flotte, welches das erste UE umfasst, gewähren. Die Bluetooth- Kontrolldaten können beispielsweise an einen Zeitraum einer Anmietung, einen Ort einer Anmietung, eine Anzahl an möglichen Benutzungen, etc. gekoppelt sein. Dadurch kann eine ungewollte Nutzung des ersten UE durch einen Nutzer des zweiten UE verhindert werden.
In einem Ausführungsbeispiel kann das erste Benutzerendgerät ein Fahrzeug sein. Beispielsweise kann ein Eigentümer des Fahrzeugs ein Mastergerät, beispielsweise ein Smartphone, besitzen, welches zumindest einen Datenschlüssel umfasst. Diesen Datenschlüssel kann der Eigentümer an einen Nutzer eines zweiten UE weitergeben, damit das zweite UE einen Zugang zu dem Fahrzeug erlangen kann. Durch die Generierung 14 der Bluetooth-Kontrolldaten kann das Mastergerät dann dem zweiten UE und dem ersten UE alle notwendigen Parameter zur Etablierung einer Bluetooth- Verbindung zur Verfügung stellen.
In einem Ausflugsbeispiel können die Bluetooth-Kontrolldaten im Fahrzeug generiert werden. Insbesondere können die Bluetooth-Kontrolldaten OnBoard generiert werden. Dadurch kann das Fahrzeug dazu ausgebildet sein, eine Etablierung einer Bluetooth-Verbindung zu einem UE zu vereinfachen. Alternativ können die Bluetooth-Kontrolldaten OffBoard generiert werden, beispielsweise durch eine administrative Plattform oder ein UE. Insbesondere kann eine Übertragung der Bluetooth-Kontrolldaten vom Fahrzeug zum UE beispielsweise mittels Nahfeldkommunikation, Car2x-Nachrichten, etc. erfolgen.
In einem Ausführungsbeispiel können die Bluetooth-Kontrolldaten Informationen über zumindest einen für ein Bluetooth-Pairing benötigten Parameter umfassen. Dadurch kann ein Bluetooth-Pairing zwischen dem ersten UE und dem zweiten UE verbessert werden. Beispielsweise können die Bluetooth-Kontrolldaten Bluetooth-Pairingdaten sein und einen LTK umfasse. Insbesondere können das erste UE und/oder das zweite UE sämtliche benötigte Parameter für ein initiales Bluetooth- Pairing von der Netzwerkkomponente erhalten, so dass dieses Wegfällen kann.
In einem Ausführungsbeispiel kann das Verfahren 10 ferner umfassen Verschlüsseln der Bluetooth- Kontrolldaten zur Synchronisierung. Dadurch kann sichergestellt werden, dass die Bluetooth- Kontrolldaten nicht durch einen Dritten ausgelesen werden können.
Das erste UE und/oder das zweite UE kann im Allgemeinen ein Gerät sein, das in der Lage ist, drahtlos zu kommunizieren. Insbesondere kann das erste UE und/oder das zweite UE ein mobiles Benutzerendgerät sein, z.B. ein Benutzerendgerät, das geeignet ist, von einem Nutzer mitgeführt zu werden. Das erste UE und/oder das zweite UE kann z.B. ein User Terminal (UT) oder User Equipment (UE) im Sinne der jeweiligen Kommunikationsstandards sein, die für die mobile Kommunikation verwendet werden. Bei dem erste UE und/oder das zweite UE kann es sich beispielsweise um ein Mobiltelefon, wie ein Smartphone, oder eine andere Art von mobilem Kommunikationsgerät, wie eine Smartwatch, einen Laptop, einen Tablet-Computer, eine autonome Augmented-Reality-Brille, etc. handeln.
Die Netzwerkkomponente kann beispielsweise einen Computer, einen Prozessor, eine Steuereinheit, ein (feld)programmierbares Logik-Array ((F)PLA), ein (feld)programmierbares Gate-Array ((F)PGA), eine Grafikprozessoreinheit (GPU), eine anwendungsspezifische integrierte Schaltung (ASIC), eine integrierte Schaltung (IC) oder ein System-on-a-Chip-System (SoC) umfassen. Die Netzwerkkomponente kann beispielsweise ein Benutzerendgerät sein.
Die Netzwerkkomponente kann im Allgemeinen ein Gerät sein, das in der Lage ist, drahtlos zu kommunizieren. Die Netzwerkkomponente kann ein Gerät im Sinne der jeweiligen Kommunikationsstandards sein, der für die mobile Kommunikation verwendet werden.
Weitere Einzelheiten und Aspekte werden im Zusammenhang mit den unten beschriebenen Ausführungsbeispielen erwähnt. Das in Fig. 1 gezeigte Ausführungsbeispiel kann ein oder mehrere optionale zusätzliche Merkmale umfassen, die einem oder mehreren Aspekten entsprechen, die im Zusammenhang mit dem vorgeschlagenen Konzept oder einem oder mehreren unten beschriebenen Ausführungsbeispielen (z. B. Fig. 2 - 5) erwähnt wurden.
Fig. 2 zeigt eine schematische Darstellung eines Beispiels eines Verfahrens 100 zum Bereitstellen von Bluetooth-Verschlüsselungsdaten. Das Verfahren 100 umfasst Erhalten 110 einer Information zum Generieren von Bluetooth-Verschlüsselungsdaten zur Etablierung einer verschlüsselten Bluetooth-Verbindung zwischen einem ersten Benutzerendgerät und einem zweiten Benutzerendgerät basierend auf der empfangenen Information. Ferner umfasst das Verfahren 100 Generieren 120 der Bluetooth -Verschlüsselungsdaten und Synchronisieren 130 der Bluetooth- Verschlüsselungsdaten zwischen dem ersten Benutzerendgerät und dem zweiten Benutzerendgerät. Mit Bluetooth können insbesondere alle Arten von Bluetooth-Protokollen umfasst sein, beispielsweise Bluetooth Low Energy.
Das erste Benutzerendgerät (UE) und/oder das zweite Benutzerendgerät kann im Allgemeinen ein Gerät sein, das in der Lage ist, drahtlos zu kommunizieren. Insbesondere ist entweder das erste UE oder das zweite UE ein mobiles UE, z.B. ein UE, das geeignet ist, von einem Nutzer mitgeführt zu werden. Das erste oder zweite UE kann z.B. ein User Terminal (UT) oder User Equipment (UE) im Sinne der jeweiligen Kommunikationsstandards sein, die für die mobile Kommunikation verwendet werden. Bei dem ersten oder zweiten UE kann es sich beispielsweise um ein Mobiltelefon, wie ein Smartphone, oder eine andere Art von mobilem Kommunikationsgerät, wie eine Smartwatch, einen Laptop, einen Tablet-Computer, eine autonome Augmented-Reality-Brille, etc. handeln. Insbesondere kann das erste oder zweite UE ein Digital Key im Sinne des Car Connectivity Consortium (CCC) Standards sein. Beispielsweise kann der Standard CCC-TS-101 Digital Key Technical Specification Release 3, Version 1.0.0 zur Kommunikation zwischen UE und Fahrzeug verwendet werden, beispielsweise wie in “Bluetooth LE Pairing & Encryption Setup Procedure”, S. 347ff beschrieben. Insbesondere die Generierung der Bluetooth-Verschlüsselungsdaten, also das Generieren 120, einen bekannten Standard ersetzen. Beispielsweise kann die in Kapitel 18.4.9. “Derivation of System Keys”, S. 290, beschriebene Generierung der Bluetooth- Verschlüsselungsdaten ersetzt werden durch das Generieren 120 der Netzwerkkomponente. Ferner kann der Austausch von Informationen (Daten) zwischen verschiedenen Benutzerendgeräten erweitert werden, beispielsweise wie er in Tabelle 19-74: 7F49 Template, S 346, beschrieben ist. Der Austausch kann insbesondere durch das Synchronisieren 130 der Netzwerkkomponenten erweitert werden. Außerdem kann für den Fall, dass die Netzwerkkomponente ein Backend, beispielsweise zu einem Fahrzeug, ist, eine Erweiterung beispielsweise in Kapitel 17.7.1.3 trackKeyResponse, S. 246, für das Synchronisieren 130 vorgenommen werden.
Insbesondere kann das erste UE mit dem zweiten UE mittels eines Wireless Personal Area Networks (WPAN), z. B. Bluetooth, etc. kommunizieren. Insbesondere kann das erste UE mit dem zweiten UE im Sinne des IEEE 802.15.1-2005 - IEEE Standard for Information technology kommunizieren. Durch das Synchronisieren 130 kann dabei insbesondere ein Bluetooth-Pairing und/oder eine password-authenticated key agreement (PAKE)-Authentifizierung vereinfacht werden.
Erhalten 110 der Information kann insbesondere ein Bestimmen oder ein Empfangen umfassen. Abhängig von der jeweiligen Funktion der Netzwerkkomponente kann die erhaltene Information verschieden sein. Beispielsweise kann die Netzwerkkomponente das erste UE oder das zweite UE sein. Alternativ kann die Netzwerkkomponente ein weiteres UE sein. Alternativ kann die Netzwerkkomponente eine administrative Plattform sein.
Beispielsweise kann die Netzwerkkomponente ein weiteres UE, z. B. eine Mastergerät sein, welches Datenschlüssel für den Zugang zu einem Fahrzeug, beispielsweise dem ersten UE, verwaltet. Insbesondere kann durch einen Datenschlüssel ein zweites UE dazu authentifiziert werden eine Verbindung zu dem ersten UE herzustellen. Das weitere UE kann einen Datenschlüssel an das zweite UE senden und beispielsweise eine Empfangsinformation von dem zweiten UE erhalten 110. Das weitere UE kann ferner die Bluetooth-Verschlüsselungsdaten generieren 120 und zwischen dem ersten UE und dem zweiten UE synchronisieren 130. Das Synchronisieren 130 kann dann beispielsweise ein Senden der Bluetooth-Verschlüsselungsdaten an das erste UE und das zweite UE von dem weiteren UE umfassen oder daraus bestehen. Alternativ kann das weitere UE durch eine administrative Plattform, insbesondere für die Verwaltung einer Mehrzahl an Fahrzeugen, ersetzt werden.
Beispielsweise kann die Netzwerkkomponente das erste UE sein, die beispielsweise von einem Fahrzeug umfasst ist. Das Fahrzeug bzw. die erste UE kann von der zweiten UE eine Information erhalten 110, welche eine Anfrage zur Benutzung des Fahrzeugs umfasst, beispielsweise über eine zwischengeschaltete Netzwerkkomponente, wie z. B einen Server. Das Fahrzeug bzw. die erste UE kann dann Bluetooth -Verschlüsselungsdaten generieren 120 und diese synchronisieren 130. Das Synchronisieren 130 kann ein Senden der Bluetooth-Verschlüsselungsdaten von dem ersten UE an das zweite UE umfassen oder daraus bestehen. Alternativ kann das zweite UE, beispielsweise ein Smartphone, die Bluetooth-Verschlüsselungsdaten generieren 120 und synchronisieren 130, insbesondere durch Senden an das Fahrzeug bzw. das erste UE.
Generieren 120 der Bluetooth-Verschlüsselungsdaten kann insbesondere ein Generieren von allen notwendigen Parametern zur Etablierung einer Bluetooth-Verbindung umfassen, beispielsweise benötigte Parameter aus dem PAKE zur Etablierung einer verschlüsselten Verbindung, Parameter aus dem Bluetooth-Pairing, etc. Durch die Generierung 120 der Bluetooth-Verschlüsselungsdaten mittels der Netzwerkkomponente können diese insbesondere auf lediglich einer elektronischen Vorrichtung generiert werden. Dadurch entfallen unter anderem eine Generierung und Übertragung von einigen Parametern, welche allein nicht hinreichend sind für die Etablierung einer Bluetooth- Verbindung, durch das erste UE oder das zweite UE. Ferner kann auch auf eine symmetrische Generierung von Bluetooth-Verschlüsselungsdaten mittels des ersten UE und des zweiten UE verzichtet werden. Durch Erhalten 110 der Information und das Generieren 120 der Bluetooth- Verschlüsselungsdaten lediglich durch die Netzwerkkomponente kann dadurch ein Datenaustausch zwischen dem ersten UE und dem zweiten UE verringert werden. Außerdem kann eine Bluetooth- Verbindung vereinfacht und/oder verbessert hergestellt werden.
Synchronisieren 130 kann einen Aufbau einer Bluetooth-Verbindung zwischen dem ersten UE und dem zweiten UE, insbesondere ohne eine Notwendigkeit einer out-of-band-Kommunikation, unmittelbar vor einer erstmaligen Etablierung einer Bluetooth-Verbindung, ermöglichen. Beispielsweise kann eine erstmalige Etablierung einer Bluetooth-Verbindung gestartet werden, ohne dass ein vorheriger Informationsaustausch mittels out-of-band zwischen dem ersten UE und dem zweiten UE erfolgt. Dadurch kann insbesondere ein Bluetooth-Pairing verbessert werden, ein Datentransfer reduziert und/oder eine Nutzererfahrung verbessert werden. Beispielsweise kann eine out-of-band Kommunikation vorab erfolgen, sodass ein Nutzer keine weitere Aktion mehr ausführen muss, damit eine erstmalige Etablierung einer Bluetooth-Verbindung erfolgen kann. Beispielsweise kann auf die Eingabe einer PIN für die zu Etablierende Bluetooth-Verbindung verzichtet werden. Außerdem kann eine Bluetooth-Verbindung zwischen dem ersten UE und dem zweiten UE aufgebaut werden, ohne dass jedes UE seine eigenen Parameter generiert und mit dem anderen UE austauscht.
Durch das Synchronisieren 130 kann also insbesondere bei der erstmaligen Etablierung einer Bluetooth-Verbindung zwischen dem ersten UE und im zweiten UE die Bestimmung hierfür notwendiger Parameter durch das jeweilige UE vermieden werden. Insbesondere kann dadurch eine Generierung eines Teilsatzes an Parametern zur Etablierung einer Bluetooth-Verbindung auf beiden UE, welche einen Austausch der Teilsätze an Parametern zwischen den beiden UE erfordert, durch das Synchronisieren 130 ersetzt werden. Insbesondere kann eine symmetrische Ableitung von notwendigen Parametern durch beide UE basierend auf dem PAKE vermieden werden.
Außerdem kann durch die Verwendung der Netzwerkkomponente, welche die Bluetooth- Verschlüsselungsdaten generiert 120 und synchronisiert 130, eine Erkennung des zweiten UE durch das erste UE verbessert werden. Beispielsweise kann in einem alternativen System ein weiteres UE beispielsweise einem zweiten UE einen Datenschlüssel für das erste UE zur Verfügung stellen, jedoch nicht alle notwendigen Parameter für einen Schlüsseltausch, also um dem zweiten UE auch einen Zugang zu dem ersten UE zu ermöglichen. Vielmehr muss das erste UE für eine erstmalige Etablierung einer Bluetooth-Verbindung zu einem zweiten UE, welches einen Datenschlüssel erhalten hat, ein Sicherheitsprotokoll deaktivieren, damit eine Verbindung hergestellt werden kann. Durch das Generieren 120 der Bluetooth-Verschlüsselungsdaten und das Synchronisieren 130 kann eine Deaktivierung des Sicherheitsprotokoll vermieden werden.
Ferner können in einem alternativen System, bei dem notwendige Parameter während der erstmaligen Etablierung einer Bluetooth-Verbindung generiert werden, die Bluetooth- Verschlüsselungsdaten nicht durch eine externe Instanz, beispielsweise eine administrative Plattform, generiert werden, da diese an der erstmaligen Etablierung der Bluetooth-Verbindung nicht beteiligt ist. Durch das Generieren 120 und das Synchronisieren 130 können die Bluetooth- Verschlüsselungsdaten vorteilhaft durch eine externe Instanz, die Netzwerkkomponente, beispielsweise eine administrative Plattform, erzeugt und geteilt werden.
In einem Ausführungsbeispiel kann die empfangene Information eine Identifikation für zumindest das erste Benutzergerät oder das zweite Benutzergerät umfassen. Insbesondere kann die Information eine Identifikation für das erste Benutzergerätes und/oder das zweite Benutzerendgerät umfassen. Beispielsweise kann die Netzwerkkomponente das erste UE sein, beispielsweise umfasst von einem Fahrzeug, und eine Information über eine Identifikation des zweiten UE erhalten. Dadurch kann das Fahrzeug einen Energiesparmodus nur nach Detektion eines vorher definierten UE verlassen. Insbesondere kann dadurch ein Versuch eines fremden UE, welches keine Authentifizierung für das Fahrzeug aufweist, eine Bluetooth-Verbindung zu etablieren, nicht dazu führen, dass das Fahrzeug den Energie sparmodus beendet. Das Fahrzeug, also das erste UE, kann also insbesondere nur dann den Energie sparmodus beenden, wenn ein ihm bekanntes UE, zum Beispiel das zweite UE, detektiert wird. Dadurch lässt sich ein Energieverbrauch des ersten UE reduzieren.
In einem Ausführungsbeispiel kann die Netzwerkkomponente eine administrative Plattform oder ein weiteres Benutzerendgerät sein. Das weitere UE kann beispielsweise ein Mastergerät sein, welches Datenschlüssel zur Authentifizierung eines UE, beispielsweise des zweiten UE, aufweist. Insbesondere kann das Mastergerät dadurch dem ersten UE und dem zweiten UE sämtliche Informationen zur Verfügung stellen, die benötigt werden, um eine erste Etablierung einer Bluetooth-Verbindung zu vereinfachen oder zu vermeiden. Beispielsweise kann das weitere UE die Bluetooth-Verschlüsselungsdaten an das erste UE und das zweiten UE senden. Optional kann das weitere UE eine Information über eine Identifikation des ersten UE bzw. zweiten UE an das zweite UE bzw. erste UE senden. Dadurch kann das erste UE das zweite UE bzw. das zweite UE das erste UE vereinfacht detektieren.
Eine administrative Plattform kann insbesondere für eine Verwaltung einer Mehrzahl an UE, beispielsweise eine Mehrzahl an ersten UE (beispielsweise mehrere Fahrzeuge einer Carsharing- Flotte), vorteilhaft sein. Die administrative Plattform kann beispielsweise Bluetooth- Verschlüsselungsdaten für ein erstes UE einer Mehrzahl an UE für das zweite UE generieren. Dadurch kann dem zweiten UE ein Zugang zu dem ersten UE der Mehrzahl an UE gewährt werden.
Insbesondere können die Bluetooth-Verschlüsselungsdaten in einer Anwendung beschränkt sein, beispielsweise auf einen Zeitraum, einen Ort, ein Nutzungsverhalten, etc. Beispielsweise können die Bluetooth-Verschlüsselungsdaten einen Nutzer des zweiten UE Zugang zu einem Fahrzeug, beispielsweise ein Fahrzeug aus einer Carsharing-Flotte, welches das erste UE umfasst, gewähren. Die Bluetooth -Verschlüsselungsdaten können beispielsweise an einen Zeitraum einer Anmietung, einen Ort eine Anmietung, eine Anzahl an möglichen Benutzungen, etc. gekoppelt sein. Dadurch kann eine ungewollte Nutzung des ersten UE durch einen Nutzer des zweiten UE verhindert werden.
In einem Ausführungsbeispiel kann das erste Benutzerendgerät ein Fahrzeug sein. Beispielsweise kann ein Eigentümer des Fahrzeugs ein Mastergerät, beispielsweise ein Smartphone, besitzen, welches zumindest einen Datenschlüssel umfasst. Diesen Datenschlüssel kann der Eigentümer an einen Nutzer eines zweiten UE weitergeben, damit das zweite UE einen Zugang zu dem Fahrzeug erlangen kann. Durch die Generierung 120 der Bluetooth-Verschlüsselungsdaten kann das Mastergerät dann dem zweiten UE und dem ersten UE alle notwendigen Parameter zur Etablierung einer Bluetooth-Verbindung zur Verfügung stellen.
In einem Ausflugsbeispiel können die Bluetooth-Verschlüsselungsdaten im Fahrzeug generiert werden. Insbesondere können die Bluetooth-Verschlüsselungsdaten OnBoard generiert werden. Dadurch kann das Fahrzeug dazu ausgebildet sein, eine Etablierung einer Bluetooth-Verbindung zu einem UE zu vereinfachen. Alternativ können die Bluetooth -Verschlüsselungsdaten OffBoard generiert werden, beispielsweise durch eine administrative Plattform oder ein UE.
In einem Ausführungsbeispiel können die Bluetooth-Verschlüsselungsdaten Informationen über zumindest einen für ein Bluetooth-Pairing benötigten Parameter umfassen. Dadurch kann ein Bluetooth-Pairing zwischen dem ersten UE und dem zweiten UE verbessert werden. Insbesondere können das erste UE und/oder das zweite UE sämtliche benötigte Parameter für ein Bluetooth- Pairing von der Netzwerkkomponente erhalten.
In einem Ausführungsbeispiel kann das Verfahren 100 ferner umfassen Verschlüsseln der Bluetooth-Verschlüsselungsdaten zur Synchronisierung. Dadurch kann sichergestellt werden, dass die Bluetooth-Verschlüsselungsdaten nicht durch einen Dritten ausgelesen werden können.
Weitere Einzelheiten und Aspekte werden im Zusammenhang mit den unten und/oder oben beschriebenen Ausführungsbeispielen erwähnt. Das in Fig. 2 gezeigte Ausführungsbeispiel kann ein oder mehrere optionale zusätzliche Merkmale umfassen, die einem oder mehreren Aspekten entsprechen, die im Zusammenhang mit dem vorgeschlagenen Konzept oder einem oder mehreren oben (z. B. Fig. 1) und/oder unten beschriebenen Ausführungsbeispielen (z. B. Fig. 3 - 5) erwähnt wurden.
Fig. 3 zeigt ein Blockdiagram eines Ausführungsbeispiels einer Vorrichtung 30 für eine Netzwerkkomponente. Die Vorrichtung 30 zum Bereitstellen von Bluetooth-Kontrolldaten (insbesondere Bluetooth-Verschlüsselungsdaten und/oder Bluetooth-Kontrolldaten) umfasst eine oder mehrere Schnittstellen 32 zur Kommunikation mit einem Benutzerendgerät (beispielsweise das erste UE und/oder das zweite UE). Die Vorrichtung 30 umfasst ferner ein Kontrollmodul 34, das zur Durchführung zumindest eines der hierin beschriebenen Verfahren ausgebildet ist, beispielsweise das Verfahren, welches mit Bezug zu Fig. 1 oder Fig. 2 beschrieben ist. Weitere Ausführungsbeispiele sind ein Fahrzeug mit einer Vorrichtung 30.
Die eine oder mehreren Schnittstellen 32 können beispielsweise einem oder mehreren Eingängen und/oder einem oder mehreren Ausgängen zum Empfangen und/oder Übertragen von Informationen entsprechen, etwa in digitalen Bitwerten, basierend auf einem Code, innerhalb eines Moduls, zwischen Modulen, oder zwischen Modulen verschiedener Entitäten. Die zumindest eine oder mehreren Schnittstellen 32 kann beispielsweise ausgebildet sein, um über ein (Funk)-Netzwerk oder ein lokales Verbindungsnetzwerk mit anderen Netzwerkkomponenten zu kommunizieren.
Wie in Fig. 3 dargestellt, sind die eine oder mehreren Schnittstellen 32 mit dem jeweiligen Kontrollmodul 34 der Vorrichtung 30 gekoppelt. In Beispielen kann die Vorrichtung 30 durch eine oder mehrere Verarbeitungseinheiten, ein oder mehrere Verarbeitungsgeräte, ein beliebiges Mittel zur Verarbeitung, wie z.B. einen Prozessor, einen Computer oder eine programmierbare Hardwarekomponente, die mit entsprechend angepasster Software betrieben werden kann, implementiert werden. Ebenso können die beschriebenen Funktionen des Kontrollmoduls 34 auch in Software implementiert werden, die dann auf einer oder mehreren programmierbaren Hardwarekomponenten ausgeführt wird. Solche Hardwarekomponenten können ein Mehrzweckprozessor, ein digitaler Signalprozessor (DSP), ein Mikrocontroller usw. sein. Das Kontrollmodul 34 kann in der Lage sein, die eine oder mehrere Schnittstellen 32 zu steuern, so dass jede Datenübertragung, die über die eine oder mehrere Schnittstellen 32 erfolgt, und/oder jede Interaktion, an der die eine oder mehrere Schnittstellen 32 beteiligt sein können, von dem Kontrollmodul 34 gesteuert werden kann.
In Ausführungsbeispielen kann das Kontrollmodul 34 einem beliebigen Controller oder Prozessor oder einer programmierbaren Hardwarekomponente entsprechen. Beispielsweise kann das Kontrollmodul 34 auch als Software realisiert sein, die für eine entsprechende Hardwarekomponente programmiert ist. Insofern kann das Kontrollmodul 34 als programmierbare Hardware mit entsprechend angepasster Software implementiert sein. Dabei können beliebige Prozessoren, wie Digitale Signalprozessoren (DSPs) zum Einsatz kommen. Ausführungsbeispiele sind dabei nicht auf einen bestimmten Typ von Prozessor eingeschränkt. Es sind beliebige Prozessoren oder auch mehrere Prozessoren zur Implementierung des Kontrollmoduls 34 denkbar.
In einer Ausführungsform kann die Vorrichtung 30 einen Speicher und mindestens ein Kontrollmodul 34 umfassen, das funktionsfähig mit dem Speicher gekoppelt und so konfiguriert ist, dass sie das unten beschriebene Verfahren durchführt.
In Beispielen können die eine oder mehrere Schnittstellen 32 jedem Mittel zum Erhalten, Empfangen, Übertragen oder Bereitstellen von analogen oder digitalen Signalen oder Informationen entsprechen, z. B. jedem Anschluss, Kontakt, Stift, Register, Eingangsanschluss, Ausgangsanschluss, Leiter, Spur usw., der die Bereitstellung oder den Erhalt eines Signals oder einer Information ermöglicht. Die eine oder mehreren Schnittstellen 32 können drahtlos oder drahtgebunden sein und können so konfiguriert sein, dass sie mit weiteren internen oder externen Komponenten kommunizieren können, z. B. Signale oder Informationen senden oder empfangen können.
In zumindest manchen Ausfiihrungsbeispielen kann das Fahrzeug beispielsweise einem Landfahrzeug, einem Wasserfahrzeug, einem Luftfahrzeug, einem Schienenfahrzeug, einem Straßenfahrzeug, einem Auto, einem Bus, einem Motorrad, einem Geländefahrzeug, einem Kraftfahrzeug, oder einem Lastkraftfahrzeug entsprechen. Das Kontrollmodul kann beispielsweise ein Teil eines Steuergeräts des Fahrzeugs sein. Die Vorrichtung 30 kann auch in anderen bluetoothfähigen elektronischen Vorrichtungen eingesetzt werden, wie z. B. einem Bluetooth- Lautsprecher, einem Bluetooth-Kopfhörer, einem Smartphone, etc.
Weitere Einzelheiten und Aspekte werden im Zusammenhang mit den unten und/oder oben beschriebenen Ausführungsbeispielen erwähnt. Das in Fig. 3 gezeigte Ausfiihrungsbeispiel kann ein oder mehrere optionale zusätzliche Merkmale umfassen, die einem oder mehreren Aspekten entsprechen, die im Zusammenhang mit dem vorgeschlagenen Konzept oder einem oder mehreren oben (z. B. Fig. 1 - 2) und/oder unten beschriebenen Ausführungsbeispielen (z. B. Fig. 4 - 5) erwähnt wurden.
Fig. 4 zeigt zwei schematische Darstellung zur Generierung und zum Austausch von Bluetooth- Verschlüsselungsdaten. Fig. 4a zeigt den Stand der Technik. Insbesondere findet in Fig. 4a beim Pairingprozess zwischen einem Mastergerät und einem Fahrzeug eine symmetrische Generierung von benötigten Parametern, bspw. kble info und kble oob master statt. Diese Parameter müssen dann zwischen den beiden UE 310, 320, also dem Fahrzeug 310 und dem Mastergerät 320 ausgetauscht werden. Ferner benötigt das Mastergerät 320 auch beim Schlüsseltausch noch weitere Informationen vom Fahrzeug 310, so dass das Mastergerät 320 erst nach erfolgtem Schlüsseltausch zwischen Fahrzeug 310 und Mastergerät 320 dem neu hinzuzufügenden Benutzerendgerät 330 alle notwendigen Parameter zur Verfügung stellen kann.
Fig. 4b zeigt eine schematische Darstellung eines Beispiels eines erfindungsgemäßen Verfahrens, beispielsweise ein Ausführungsbeispiel eines Verfahrens, welches mit Referenz zu Fig. 1 beschrieben wurde.
In Fig. 4b ist die Netzwerkkomponente 340, welche die Bluetooth-Verschlüsselungsdaten generiert und synchronisiert ein Fahrzeug-Backend 340. Die Generation der Bluetooth-Verschlüsselungsdaten kann durch das Fahrzeug-Backend erfolgen, bevor eine erstmalige Verbindung zwischen dem Fahrzeug 310 und dem neu hinzuzufügenden Benutzerendgerät 330 versucht wird aufzubauen, beispielsweise, bevor ein Bluetooth-Pairing durchgeführt wird. Das Fahrzeug-Backend 340 sendet dann die generierten Bluetooth-Verschlüsselungsdaten an das Fahrzeug 310 und das neu hinzuzufügenden Benutzerendgerät 330. Dadurch kann das neu hinzuzufügende Benutzerendgerät 330 sich mit dem Fahrzeug 310 mittels Bluetooth verbinden, ohne eine erstmalige Verbindung aufbauen zu müssen. Beispielsweise kann dadurch eine erste ungesicherte Verbindung, bevor beispielsweise PAKE durchgeführt wurde, verhindert werden. Das Fahrzeug 310 und das neu hinzuzufügende Benutzerendgerät 330 können im Wesentlichen eine Synchronisierung der out-of- band-Information durchführen. Dadurch kann insbesondere nach dem Synchronisieren der Bluetooth-Verschlüsselungsdaten eine erstmalige Etablierung einer Bluetooth-Verbindung direkt gestartet werden. Beispielsweise kann ein Bluetooth-Pairing gestartet werden, ohne dass ein weiterer Austausch von out-of-band-Information zwischen dem Fahrzeug 310 und dem hinzuzufügenden Benutzerendgerät 330 erforderlich ist.
Optional können während eines Bluetooth-Pairing zwischen dem Mastergerät 320 und dem Fahrzeug 310 die benötigten Bluetooth-Verschlüsselungsdaten direkt vom Fahrzeug 310 an das Mastergerät 320 gesendet werden. Eine Generierung von Bluetooth-Verschlüsselungsdaten durch das Mastergerät 320 kann nicht mehr erforderlich sein. Insbesondere können die Bluetooth- Verschlüsselungsdaten von dem Fahrzeug 310 an das Mastergerät 320 über eine gesicherte Verbindung während des Mastergerät-Pairings gesendet werden. Auch kann keine Informationsübermittlung während des Schlüsselaustausch an das Mastergerät 320 mehr notwendig sein. Das Mastergerät-Pairing kann insbesondere zum Anlemen des Mastergeräts 320 an das Fahrzeug 310 dienen. Das Mastergerät-Pairing kann beispielsweise mittels WPAN, z. B. Bluetooth, WLAN, etc. erfolgen. Das Mastergerät-Pairing kann beispielsweise nach CCC Standards erfolgen. Beispielsweise kann der Standard CCC-TS-101 Digital Key Technical Specification Release 3, Version 1.0.0, Kapitel 6 verwendet werden.
Das Fahrzeug-Backend 340 kann insbesondere nach jedem Erhalt einer Information zum Generieren von Bluetooth-Verschlüsselungsdaten zur Etablierung einer verschlüsselten Bluetooth-Verbindung zwischen einem ersten Benutzerendgerät und einem zweiten Benutzerendgerät neue Bluetooth- Verschlüsselungsdaten generieren und synchronisieren. Eine erhaltene Information kann beispielsweise Informationen über einen neuen generierten/verwendeten Datenschlüssel umfassen. Der neue generierte/verwendete Datenschlüssel kann insbesondere über ein Teilen von Zugriffsrechten, beispielsweise durch das Mastergerät 320 und/oder durch einen Service- Datenschlüssel, beispielsweise durch eine administrative Plattform wie das Fahrzeug-Backend 340, erzeugt werden. Das Fahrzeug-Backend 340 kann dann nach Erhalt der Information und generieren der Bluetooth-Verschlüsselungsdaten, diese an das Fahrzeug 310 und das neu hinzuzufügende Benutzerendgerät 330 senden. Das Senden kann dabei insbesondere sofort nach dem Generieren der Bluetooth-Verschlüsselungsdaten erfolgen bzw. sobald eine Verbindung zu dem Fahrzeug 310 und/oder dem neu hinzuzufügenden Benutzerendgerät 330 aufgebaut werden kann. Dies kann beispielsweise durch ein Erweitern der Informationen, welche über eine sichere Verbindung während eines Tracking eines neu hinzuzufügenden Benutzerendgeräts 330 gesendet werden, erfolgen.
Beispielsweise kann ein Verwalter einer Carsharing-Flotte mittels einer administrativen Plattform, einen Datenschlüssel für einen Kunden erstellen. Beispielsweise kann das Fahrzeug-Backend 340 verwendet werden, um ein Mastergerät 320 zu ersetzen. Insbesondere muss also kein Mastergerät 320 vorhanden sein. Das neu hinzuzufügenden Benutzerendgerät 330 kann dann von dem Fahrzeug- Backend 340 den (Service-)Datenschlüssel erhalten. Der (Service-)Datenschlüssel kann beim Fahrzeug-Backend 340 registriert werden. Ferner kann das neu hinzuzufügenden Benutzerendgerät 330 auch die von dem Fahrzeug-Backend 340 generierten Bluetooth-Verschlüsselungsdaten erhalten, bspw. zeitgleich mit dem (Service-)Datenschlüssel. Dieselben Bluetooth- Verschlüsselungsdaten kann das Fahrzeug 310 erhalten. Zusätzlich kann das Fahrzeug 310 auch die Information über den (Service-)Datenschlüssel erhalten, bzw. eine Information, die eine Identifikation des neu hinzuzufügenden Benutzerendgeräts 330 erlaubt. Dadurch kann dann eine erste erstmalige Verbindung für eine Bluetooth-Verbindung verbessert werden.
Beispielsweise kann ein Nutzer eines Mastergeräts 320 einem Freund einen Zugang zu seinem Fahrzeug 310 ermöglichen wollen. Hierfür kann der Nutzer mittels seines Mastergeräts 320 dem neu hinzuzufügenden Benutzerendgeräts 330 seines Freunds einen Datenschlüssel senden. Der Datenschlüssel kann dann bei dem Fahrzeug-Backend 340 registriert werden. Ferner kann das neu hinzuzufügenden Benutzerendgerät 330 die von dem Fahrzeug-Backend 340 generierten Bluetooth- Verschlüsselungsdaten erhalten. In diesem Fall kann der Erhalt des Datenschlüssels von dem Erhalt der Bluetooth-Verschlüsselungsdaten separiert sein. Alternativ kann auch das Mastergerät 320 die Bluetooth-Verschlüsselungsdaten generieren. In diesem Fall kann dann kein Fahrzeug-Backend 340 vorhanden sein.
Weitere Einzelheiten und Aspekte werden im Zusammenhang mit den unten und/oder oben beschriebenen Ausführungsbeispielen erwähnt. Das in Fig. 4 gezeigte Ausführungsbeispiel kann ein oder mehrere optionale zusätzliche Merkmale umfassen, die einem oder mehreren Aspekten entsprechen, die im Zusammenhang mit dem vorgeschlagenen Konzept oder einem oder mehreren oben (z. B. Fig. 1 - 3) und/oder unten beschriebenen Ausführungsbeispielen (z. B. Fig. 5) erwähnt wurden. Fig. 5 zeigt zwei schematische Darstellung zur Generierung und zum Austausch von Bluetooth- Verschlüsselungsdaten. Fig. 5a zeigt den Stand der Technik. Wie im Stand der Technik zu erkennen ist, erfolgt eine Aushandlung des LTK erst nachdem eine erste initiale Verbindung zwischen Fahrzeug 310 und neuem UE 330 etabliert ist, beispielsweise eine erste Etablierung einer Bluetooth- Verbindung erfolgt ist. Dadurch entstehen für einen Nutzer des neuen UE 330 unnötige Wartezeiten, welche eine Nutzererfahrung verschlechtern können.
Fig. 5b zeigt eine schematische Darstellung eines Beispiels eines erfmdungsgemäßen Verfahrens, beispielsweise ein Ausführungsbeispiel eines Verfahrens, welches mit Referenz zu Fig. 1 beschrieben wurde.
In Fig. 5b ist die Netzwerkkomponente 340, welche die Bluetooth-Kontrolldaten generiert und synchronisiert ein Fahrzeug-Backend 340. Insbesondere generiert das Fahrzeug-Backend 340 Bluetooth-Pairingdaten, insbesondere umfassend einen LTK. Die Generation der Bluetooth- Kontrolldaten kann durch das Fahrzeug-Backend erfolgen, bevor eine erstmalige Verbindung zwischen dem Fahrzeug 310 und dem neu hinzuzufügenden Benutzerendgerät 330 versucht wird aufzubauen, beispielsweise, bevor ein Bluetooth-Pairing durchgeführt wird. Insbesondere kann eine Etablierung einer initialen Bluetooth-Verbindung mittels Bluetooth-Pairing durch die Generierung und Synchronisierung der Bluetooth-Kontrolldaten vermieden bzw. ersetzt werden.
Das Fahrzeug-Backend 340 kann dann die generierten Bluetooth- Kontrolldaten an das Fahrzeug 310 und das neu hinzuzufügenden Benutzerendgerät 330 senden. Dadurch kann das neu hinzuzufügende Benutzerendgerät 330 sich mit dem Fahrzeug 310 mittels Bluetooth verbinden, ohne eine erstmalige Verbindung aufbauen zu müssen, insbesondere ohne eine initiale Bluetooth- Verbindung aufbauen zu müssen, da ein LTK bereits bekannt sein kann. Beispielsweise kann dadurch ein LTK direkt zwischen Fahrzeug 310 und neuen Benutzerendgerät 330 synchronisiert werden. Dadurch kann bei einem ersten Kontakt zwischen Fahrzeug 310 und neuen Benutzerendgerät 330 bereits ein Bluetooth-Pairing Prozess, insbesondere ein Bluetooth-Low- Energy-Pairing Prozess, entfallen. Insbesondere kann dadurch eine Nutzererfahrung erhöht werden. Eine Nutzererfahrung bei Erstkontakt mit dem Fahrzeug kann negativ beeinträchtigt werden kann, wenn durch den Bluetooth-Pairing Prozess eine Verzögerung im Ablauf (z. B. einem Entriegeln des Fahrzeugs) entsteht. Durch die vorherige Synchronisation des LTK kann diese Verzögerung vermieden werden. Insbesondere kann ein Persistieren beider Kommunikationspartner, des Fahrzeugs 310 und des Benutzerendgeräts 330, eines LTK, um bei nachfolgenden Kontakten eine sichere Verbindung direkt aufbauen zu können, nach einem Bluetooth-Pairing entfallen. Das Fahrzeug 310 und das neu hinzuzufugende Benutzerendgerät 330 können im Wesentlichen eine Synchronisierung aller für eine Bluetooth-Verbindung benötigten Information durchfuhren. Dadurch kann insbesondere nach dem Synchronisieren der Bluetooth-Kontrolldaten (Bluetooth-Pairingdaten) eine erstmalige Etablierung einer Bluetooth-Verbindung entfallen. Das Fahrzeug 310 und das neue Benutzerendgerät 330 können sich also direkt eine Bluetooth-Verbindung aufbauen. Beispielsweise kann ein Persistieren eines LTK nach einem Bluetooth-Pairing nicht notwendig sein.
Optional können während eines Bluetooth-Pairing zwischen dem Mastergerät 320 und dem Fahrzeug 310 die benötigten Bluetooth-Kontrolldaten (Bluetooth-Pairingdaten) direkt vom Fahrzeug 310 an das Mastergerät 320 gesendet werden. Eine Generierung von Bluetooth-Kontrolldaten (Bluetooth-Pairingdaten) durch das Mastergerät das Fahrzeug 310 und das neue Benutzerendgerät 330 kann nicht mehr erforderlich sein.
Das Fahrzeug-Backend 340 kann insbesondere nach jedem Erhalt einer Information zum Generieren von Bluetooth-Verschlüsselungsdaten zur Etablierung einer verschlüsselten Bluetooth-Verbindung zwischen einem ersten Benutzerendgerät und einem zweiten Benutzerendgerät neue Bluetooth- Verschlüsselungsdaten generieren und synchronisieren. Eine erhaltene Information kann beispielsweise eine Information über einen neu generierten/verwendeten Datenschlüssel umfassen. Der neue generierte/verwendete Datenschlüssel kann insbesondere über ein Teilen von Zugriffsrechten, beispielsweise durch das Mastergerät 320 und/oder durch einen Service- Datenschlüssel, beispielsweise durch eine administrative Plattform wie das Fahrzeug-Backend 340, erzeugt werden. Das Fahrzeug-Backend 340 kann dann nach Erhalt der Information und Generieren der Bluetooth-Verschlüsselungsdaten, diese an das Fahrzeug 310 und das neu hinzuzufügende Benutzerendgerät 330 senden. Das Senden kann dabei insbesondere sofort nach dem Generieren der Bluetooth-Verschlüsselungsdaten erfolgen bzw. sobald eine Verbindung zu dem Fahrzeug 310 und/oder dem neu hinzuzufügenden Benutzerendgerät 330 aufgebaut werden kann. Dies kann beispielsweise durch ein Erweitern der Informationen, welche über eine sichere Verbindung während eines Tracking eines neu hinzuzufügenden Benutzerendgeräts 330 gesendet werden, erfolgen.
Eine beispielhafte Generierung der Bluetooth-Kontrolldaten ist folgend näher dargestellt.
Bezug wird genommen auf den CCC-Standard Digital Key Technical Specification Release 3 vl.0.0, [CCC-R3], [CCC-R3] beschreibt aktuell lediglich ein Konzept der CCC-Spezifikationen. Es beschreibt jedoch keine Möglichkeit der Implementierung von Bluetooth-Kontrolldaten.
Die Bluetooth-Kontrolldaten können beispielsweise wie folgt definiert sein: IRK: o Verwendet um die ADV_IND des Fahrzeugs aufzulösen.
• BT ADDR CAR: o optional o Verwendet für eine Etablierung eine Bluetooth-Verbindung.
• LTK: o Verwendet für einen sichere (Übertragungs)kanal.
Generell können gewisse Parameter, wie z. B. [OBLE-OOl] benötigt werden. Zuerst kann ein Bedarf bestehen bei einem Schlüsseltausch, dass die Bluetooth-Kontrolldaten synchronisiert werden, beispielsweise zwischen einem Fahrzeug-Backend und dem Fahrzeug.
Folgende Änderungen können beim Mastergerät-Pairing durchgeführt werden:
General:
[OBLE-201]: Um [OBLE-OOl] sicherzustellen, können die Bluetooth-Kontrolldaten zwischen einem Fahrzeug-Backend und einem Fahrzeug synchronisiert werden, und zwar bevor ein Mastergerät- Pairing erfolgt. Die Generierung der Kontrolldaten und die Synchronisierung kann dabei nach einem der oben beschriebenen Verfahren erfolgen, beispielsweise wie mit Bezug zu Fig. 1 oder Fig. 2 beschrieben.
7F49 Template:
[OBLE-202] 7F49 Template: Hinzufugen eines Tags 0xD5 so dass:
• Wenn das Fahrzeug einen Abruf der Bluetooth-Kontrolldaten unterstützt, kann während des Mastergeräts-Pairing der Tag 0xD5 präsentiert werden. Der Tag kann einen LTK umfassen, welchen in [OBLE-OOl] bestimmt wurde.
Bluetooth Pairing
[OBLE-203] “Bluetooth LE Pairing & Encryption Setup Procedure” (wie beschrieben auf 347ff. [CCC-R3]) kann übersprungen werden. Die generierten/synchronisierten LTK können dann genutzt werden, um eine sichere Bluetooth-Verbindung aufzubauen.
Ferner können Änderungen beim Schlüsseltausch vorgenommen werden.
7F49 Template:
[OBLE-204] 7F49 Template: Hinzufügen eines Tags 0xD5 so dass:
• Wenn das Fahrzeug einen Abruf der Bluetooth-Kontrolldaten unterstützt, kann während des Mastergeräts-Pairing der Tag 0xD5 präsentiert werden. Der Tag kann einen LTK umfassen, welchen in [OBLE-OOl] bestimmt wurde.
Erste initiale Verbindung beim Bluetooth-Pairing [OBLE-205] Die “Bluetooth LE Pairing & Encryption Setup Procedure” (wie beschrieben auf 347ff. [CCC-R3]) kann übersprungen werden. Die generierten/synchronisierten LTK können dann genutzt werden, um eine sichere Bluetooth-Verbindung aufzubauen.
Weiterhin können Änderungen beim Tracking eines Schlüssels durchgeführt werden: trackKey Response (): [OBLE-206] Hinzufügen des folgenden Parameters zu trackKey Response ()
[OBLE-207] Kapitel hinzufügen "Unencrypted Vehicle-BLE-Key Fields" mit dem folgenden Inhalt:
Weitere Einzelheiten und Aspekte werden im Zusammenhang mit den oben beschriebenen Ausführungsbeispielen erwähnt. Das in Fig. 5 gezeigte Ausführungsbeispiel kann ein oder mehrere optionale zusätzliche Merkmale umfassen, die einem oder mehreren Aspekten entsprechen, die im Zusammenhang mit dem vorgeschlagenen Konzept oder einem oder mehreren oben (z. B. Fig. 1 - 4) beschriebenen Ausführungsbeispielen erwähnt wurden.
Weitere Ausführungsbeispiele sind Computerprogramme zur Durchführung eines der hierin beschriebenen Verfahren, wenn das Computerprogramm auf einem Computer, einem Prozessor, oder einer programmierbaren Hardwarekomponente abläuft. Je nach bestimmten Implementierungsanforderungen können Ausführungsbeispiele der Erfindung in Hardware oder in Software implementiert sein. Die Implementierung kann unter Verwendung eines digitalen Speichermediums, beispielsweise einer Floppy-Disk, einer DVD, einer Blu-Ray Disc, einer CD, eines ROM, eines PROM, eines EPROM, eines EEPROM oder eines FLASH-Speichers, einer Festplatte oder eines anderen magnetischen oder optischen Speichers durchgeführt werden, auf dem elektronisch lesbare Steuersignale gespeichert sind, die mit einer programmierbaren Hardwarekomponente derart Zusammenwirken können oder Zusammenwirken, dass das jeweilige Verfahren durchgeführt wird.
Eine programmierbare Hardwarekomponente kann durch einen Prozessor, einen Computerprozessor (CPU = Central Processing Unit), einen Grafikprozessor (GPU = Graphics Processing Unit), einen Computer, ein Computersystem, einen anwendungsspezifischen integrierten Schaltkreis (ASIC = Application-Specific Integrated Circuit), einen integrierten Schaltkreis (IC = Integrated Circuit), ein Ein-Chip -System (SOC = System on Chip), ein programmierbares Logikelement oder ein feldprogrammierbares Gatterarray mit einem Mikroprozessor (FPGA = Field Programmable Gate Array) gebildet sein.
Das digitale Speichermedium kann daher maschinen- oder computerlesbar sein. Manche Ausführungsbeispiele umfassen also einen Datenträger, der elektronisch lesbare Steuersignale aufweist, die in der Lage sind, mit einem programmierbaren Computersystem oder einer programmierbare Hardwarekomponente derart zusammenzuwirken, dass eines der hierin beschriebenen Verfahren durchgeführt wird. Ein Ausführungsbeispiel ist somit ein Datenträger (oder ein digitales Speichermedium oder ein computerlesbares Medium), auf dem das Programm zum Durchführen eines der hierin beschriebenen Verfahren aufgezeichnet ist.
Allgemein können Ausführungsbeispiele der vorliegenden Erfindung als Programm, Firmware, Computerprogramm oder Computerprogrammprodukt mit einem Programmcode oder als Daten implementiert sein, wobei der Programmcode oder die Daten dahin gehend wirksam ist bzw. sind, eines der Verfahren durchzuführen, wenn das Programm auf einem Prozessor oder einer programmierbaren Hardwarekomponente abläuft. Der Programmcode oder die Daten kann bzw. können beispielsweise auch auf einem maschinenlesbaren Träger oder Datenträger gespeichert sein. Der Programmcode oder die Daten können unter anderem als Quellcode, Maschinencode oder Bytecode sowie als anderer Zwischencode vorliegen.
Die oben beschriebenen Ausführungsbeispiele stellen lediglich eine Veranschaulichung der Prinzipien der vorliegenden Erfindung dar. Es versteht sich, dass Modifikationen und Variationen der hierin beschriebenen Anordnungen und Einzelheiten anderen Fachleuten einleuchten werden. Deshalb ist beabsichtigt, dass die Erfindung lediglich durch den Schutzumfang der nachstehenden Patentansprüche und nicht durch die spezifischen Einzelheiten, die anhand der Beschreibung und der Erläuterung der Ausführungsbeispiele hierin präsentiert wurden, beschränkt sei. Bezugszeichenliste
30 Vorrichtung 32 Schnittstelle
34 Kontrollmodul
100 Verfahren zum Bereitstellen von Bluetooth-Verschlüsselungsdaten
110 Erhalten einer Information
120 Generieren der Bluetooth-Verschlüsselungsdaten 130 Synchronisieren der Bluetooth-Verschlüsselungsdaten
310 Fahrzeug
320 Mastergerät
330 Neu hinzuzufügendes Benutzerendgerät
340 Fahrzeug-Backend

Claims

Patentansprüche
1. Ein Verfahren (10) für eine Netzwerkkomponente zum Bereitstellen von Bluetooth-Kontrolldaten, umfassend:
Erhalten (12) einer Information zum Generieren von Bluetooth-Kontrolldaten zur Etablierung einer verschlüsselten Bluetooth-Verbindung zwischen einem ersten Benutzerendgerät und einem zweiten Benutzerendgerät basierend auf der erhaltenen Information;
Generieren (14) der Bluetooth-Kontrolldaten; und
Synchronisieren (16) der Bluetooth-Kontrolldaten zwischen dem ersten Benutzerendgerät und dem zweiten Benutzerendgerät.
2. Das Verfahren (10) nach Anspruch 1, wobei die erhaltene Information eine Identifikation für zumindest das erste Benutzerendgerät oder das zweite Benutzerendgerät umfasst.
3. Das Verfahren (10) nach Anspruch 1 oder 2, wobei die Bluetooth-Kontrolldaten Bluetooth-Verschlüsselungsdaten sind.
4. Das Verfahren (10) nach einem der vorangegangenen Ansprüche, wobei die Bluetooth-Kontrolldaten Bluetooth-Pairingdaten sind.
5. Das Verfahren (10) nach einem der vorangegangenen Ansprüche, wobei die erhaltene Information eine Identifikation für zumindest das erste Benutzerendgerät oder das zweite Benutzerendgerät umfasst.
6. Das Verfahren (10) nach einem der vorangegangenen Ansprüche, wobei die Netzwerkkomponente eine administrative Plattform oder ein weiteres Benutzerendgerät ist.
7. Das Verfahren (10) nach einem der vorangegangenen Ansprüche, ferner umfassend Verschlüsseln der Bluetooth-Kontrolldaten zur Synchronisierung.
8. Ein Computerprogramm zur Durchführung eines der Verfahren (10) nach einem der vorangegangenen Ansprüche, wenn das Computerprogramm auf einem Computer, einem Prozessor, oder einer programmierbaren Hardwarekomponente abläuft.
9. Eine Vorrichtung (30) fur eine Netzwerkkomponente zum Bereitstellen von Bluetooth- Kontrolldaten, umfassend eine oder mehrere Schnittstellen (32) zur Kommunikation mit einem Benutzerendgerät; und ein Kontrollmodul (34), das zur Durchführung zumindest eines der Verfahren (10) nach einem der Ansprüche 1 - 7 ausgebildet ist.
10. Fahrzeug mit einer Vorrichtung (30) gemäß Anspruch 9.
EP22711491.5A 2022-01-31 2022-02-18 Verfahren für eine netzwerkkomponente zum bereitstellen von bluetooth-kontrolldaten, computerprogramm, vorrichtung und fahrzeug Pending EP4473758A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102022102156.4A DE102022102156A1 (de) 2022-01-31 2022-01-31 Verfahren für eine Netzwerkkomponente zum Bereitstellen von Bluetooth-Verschlüsselungsdaten, Computerprogramm, Vorrichtung und Fahrzeug
PCT/EP2022/054144 WO2023143750A1 (de) 2022-01-31 2022-02-18 Verfahren für eine netzwerkkomponente zum bereitstellen von bluetooth-kontrolldaten, computerprogramm, vorrichtung und fahrzeug

Publications (1)

Publication Number Publication Date
EP4473758A1 true EP4473758A1 (de) 2024-12-11

Family

ID=80820239

Family Applications (1)

Application Number Title Priority Date Filing Date
EP22711491.5A Pending EP4473758A1 (de) 2022-01-31 2022-02-18 Verfahren für eine netzwerkkomponente zum bereitstellen von bluetooth-kontrolldaten, computerprogramm, vorrichtung und fahrzeug

Country Status (5)

Country Link
US (2) US20250097681A1 (de)
EP (1) EP4473758A1 (de)
CN (2) CN118511561A (de)
DE (1) DE102022102156A1 (de)
WO (2) WO2023143750A1 (de)

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060075075A1 (en) * 2004-10-01 2006-04-06 Malinen Jouni I Method and system to contextually initiate synchronization services on mobile terminals in an enterprise environment

Family Cites Families (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2004187096A (ja) * 2002-12-04 2004-07-02 Toshiba Corp キーレスエントリシステムおよびキーレスエントリ方法
US8432260B2 (en) * 2010-02-26 2013-04-30 GM Global Technology Operations LLC Simplified vehicle bluetooth pairing employing near field communication tags
DE102015214336A1 (de) * 2015-07-29 2017-02-02 Hella Kgaa Hueck & Co. Vorrichtungen, Verfahren und Computerprogramme zum Herstellen einer Funkverbindung basierend auf Proximitätsinformation
US10437977B2 (en) * 2015-10-13 2019-10-08 Etas Embedded Systems Canada Inc. System and method for digital key sharing for access control
US10231123B2 (en) * 2015-12-07 2019-03-12 GM Global Technology Operations LLC Bluetooth low energy (BLE) communication between a mobile device and a vehicle
FR3048320B1 (fr) * 2016-02-29 2019-05-31 Dura Operating, Llc Methode et systeme d'echange de donnees entre utilisateurs d'un vehicule
KR102275564B1 (ko) * 2017-04-14 2021-07-12 삼성전자주식회사 전자 장치 및 전자 장치에서 인증 정보 전송 및 수신 방법
US20190190703A1 (en) * 2017-12-18 2019-06-20 Auton, Inc. Systems and methods for using an out-of-band security channel for enhancing secure interactions with automotive electronic control units
US10538220B1 (en) 2018-09-06 2020-01-21 GM Global Technology Operations LLC User activated/deactivated short-range wireless communications (SRWC) auxiliary key fob
KR102737088B1 (ko) * 2018-11-02 2024-12-02 삼성전자주식회사 이모빌라이저 토큰 관리 시스템
US11330429B2 (en) * 2019-04-20 2022-05-10 Ksmartech Co., Ltd Vehicle digital key sharing service method and system
US10589719B1 (en) * 2019-05-30 2020-03-17 Hyundai Autoever Method for managing digital key of mobile device for vehicle-sharing and key server using the same
CN112351390A (zh) * 2019-08-09 2021-02-09 华为技术有限公司 蓝牙设备互识或互信的方法
DE102019121578A1 (de) 2019-08-09 2021-02-11 Bayerische Motoren Werke Aktiengesellschaft Steuerung der Nutzung einer Einrichtung
US10924924B1 (en) * 2019-09-09 2021-02-16 Ford Global Technologies, Llc Out-of-band key sharing using near-field communication
US11516025B2 (en) * 2020-03-19 2022-11-29 Ford Global Technologies, Llc Advance mobile device and vehicle profile pairing
US12184628B2 (en) * 2021-06-24 2024-12-31 Evq Technologies Private Limited Cloud-based sharing of digital keys

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060075075A1 (en) * 2004-10-01 2006-04-06 Malinen Jouni I Method and system to contextually initiate synchronization services on mobile terminals in an enterprise environment

Also Published As

Publication number Publication date
CN118511560A (zh) 2024-08-16
US20250097681A1 (en) 2025-03-20
US20250113182A1 (en) 2025-04-03
DE102022102156A1 (de) 2023-08-03
CN118511561A (zh) 2024-08-16
WO2023143760A1 (de) 2023-08-03
WO2023143750A1 (de) 2023-08-03

Similar Documents

Publication Publication Date Title
DE102013224330B4 (de) Verfahren und System zum Erkennen von Annäherung eines Endgeräts an ein Fahrzeug, das auf der Information über eine Signalstärke basiert, die über einen Bluetooth-Sendekanal von geringer Energie (BLE) empfangen wird
DE102016123276B4 (de) Verfahren zur kommunikation über eine bluetooth low energy (ble)-verbindung in einem fahrzeug
DE102018122746A1 (de) Fahrzeug als öffentlicher drahtlos-hotspot
DE102017102388A1 (de) Regeln des fahrzeugzugangs unter verwendung kryptografischer verfahren
DE102018129843A1 (de) Einrichten einer sicheren drahtlosen Nahbereichs-Kommunikationsverbindung an einem Fahrzeug
DE102021110171A1 (de) System zum steuern von vorgängen eines fahrzeugs unter verwendung von mobilen vorrichtungen und verwandte verfahren davon
DE102014224481A1 (de) Fernsteuerung von Fahrzeugfunktionalitäten mittels eines mobilen Endgeräts
EP3395085B1 (de) Vorrichtungen, verfahren und computerprogramm zum herstellen einer kommunikationsverbindung zwischen einem informationssystem eines fahrzeugs und einem mobilgerät
DE112017002032T5 (de) Verfahren und Vorrichtung zur Verwendung einer biometrischen Vorlage zum Steuern des Zugangs zu einer Benutzeranmeldeinformation für ein gemeinsam genutztes drahtloses Kommunikationsgerät
DE112019005795T5 (de) Zeitstempelbasiertes Einbindungsverfahren für Drahtlosgeräte
DE102015223512A1 (de) System und Verfahren zum Zusammenwirken zwischen Fahrzeugsteuerung und externer Ressource
DE202016107182U1 (de) Drahtlose Benutzerschnittstellenprojektion für Fahrzeuge
DE102018106017A1 (de) Verfahren und gerät zum effizienten berichten von fahrzeugdaten
EP3580942B1 (de) Verfahren zur erfassung von signalstärken für eine signalstärkenbasierte positionsbestimmung eines mobilen ble-geräts
EP3306891B1 (de) Verfahren zum kommunizieren und kommunikationsmodul für ein kraftfahrzeug
DE102016116909A1 (de) Verfahren und Vorrichtung für eine sichere Paarung basierend auf Fernbedienungsanwesenheit
DE112017002902B4 (de) Gerätepaarung unter Nutzung einer Sicherheitszone
DE102024115609A1 (de) Kommunikationssystem, Authentifizierungsverfahren und Speichermedium
DE102018131242A1 (de) Verfahren und vorrichtung zum fahrzeugzugriff über wechselcode
WO2023143750A1 (de) Verfahren für eine netzwerkkomponente zum bereitstellen von bluetooth-kontrolldaten, computerprogramm, vorrichtung und fahrzeug
DE102014114072B4 (de) Verfahren und Systeme zur sicheren Kommunikation zwischen drahtlosen elektronischen Geräten und Fahrzeugen
EP3782415B1 (de) Kommunikationseinrichtung, kontrollkomponente, verfahren und computerprogramm zur konfiguration einer lokalen drahtlosen kommunikation zwischen der kommunikationseinrichtung und einem fahrzeugnahen mobilgerät
DE102013100756B3 (de) Verfahren und Vorrichtung zur Authentifizierung eines Nutzers
DE102015224837A1 (de) Vorrichtungen, Verfahren und Computerprogramm zum Herstellen einer Kommunikationsverbindung zwischen einem Informationssystem und einem Mobilgerät
DE102013202426A1 (de) Verfahren zum Ermöglichen einer Datenkommunikation zwischen einer Kommunikationseinrichtung eines Kraftfahrzeugs und einem Internetserver und entsprechendes System

Legal Events

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

Free format text: STATUS: UNKNOWN

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: 20240705

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

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: 20251006