WO2021043396A1 - Dispositif et procédé pour faire fonctionner un dispositif - Google Patents

Dispositif et procédé pour faire fonctionner un dispositif Download PDF

Info

Publication number
WO2021043396A1
WO2021043396A1 PCT/EP2019/073607 EP2019073607W WO2021043396A1 WO 2021043396 A1 WO2021043396 A1 WO 2021043396A1 EP 2019073607 W EP2019073607 W EP 2019073607W WO 2021043396 A1 WO2021043396 A1 WO 2021043396A1
Authority
WO
WIPO (PCT)
Prior art keywords
preferred embodiments
further preferred
data
vehicle
hash value
Prior art date
Application number
PCT/EP2019/073607
Other languages
English (en)
Inventor
Steven Arnold
Jack Murfett
Uwe HOLLATZ
Ewen Christopher
Original Assignee
Robert Bosch Gmbh
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Robert Bosch Gmbh filed Critical Robert Bosch Gmbh
Priority to PCT/EP2019/073607 priority Critical patent/WO2021043396A1/fr
Publication of WO2021043396A1 publication Critical patent/WO2021043396A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/06—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols the encryption apparatus using shift registers or memories for block-wise or stream coding, e.g. DES systems or RC4; Hash functions; Pseudorandom sequence generators
    • H04L9/0643—Hash functions, e.g. MD5, SHA, HMAC or f9 MAC
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60R—VEHICLES, VEHICLE FITTINGS, OR VEHICLE PARTS, NOT OTHERWISE PROVIDED FOR
    • B60R25/00—Fittings or systems for preventing or indicating unauthorised use or theft of vehicles
    • B60R25/20—Means to switch the anti-theft system on or off
    • B60R25/24—Means to switch the anti-theft system on or off using electronic identifiers containing a code not memorised by the user
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60R—VEHICLES, VEHICLE FITTINGS, OR VEHICLE PARTS, NOT OTHERWISE PROVIDED FOR
    • B60R25/00—Fittings or systems for preventing or indicating unauthorised use or theft of vehicles
    • B60R25/20—Means to switch the anti-theft system on or off
    • B60R25/24—Means to switch the anti-theft system on or off using electronic identifiers containing a code not memorised by the user
    • B60R25/241—Means to switch the anti-theft system on or off using electronic identifiers containing a code not memorised by the user whereby access privileges are related to the identifiers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/06—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols the encryption apparatus using shift registers or memories for block-wise or stream coding, e.g. DES systems or RC4; Hash functions; Pseudorandom sequence generators
    • H04L9/065—Encryption by serially and continuously modifying data stream elements, e.g. stream cipher systems, RC4, SEAL or A5/3
    • H04L9/0656—Pseudorandom key sequence combined element-for-element with data sequence, e.g. one-time-pad [OTP] or Vernam's cipher
    • H04L9/0662—Pseudorandom key sequence combined element-for-element with data sequence, e.g. one-time-pad [OTP] or Vernam's cipher with particular pseudorandom sequence generator
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/10—Integrity
    • H04W12/106—Packet or message integrity
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60R—VEHICLES, VEHICLE FITTINGS, OR VEHICLE PARTS, NOT OTHERWISE PROVIDED FOR
    • B60R2325/00—Indexing scheme relating to vehicle anti-theft devices
    • B60R2325/10—Communication protocols, communication systems of vehicle anti-theft devices
    • B60R2325/101—Bluetooth
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60R—VEHICLES, VEHICLE FITTINGS, OR VEHICLE PARTS, NOT OTHERWISE PROVIDED FOR
    • B60R2325/00—Indexing scheme relating to vehicle anti-theft devices
    • B60R2325/10—Communication protocols, communication systems of vehicle anti-theft devices
    • B60R2325/108—Encryption
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/84—Vehicles
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/30—Services specially adapted for particular environments, situations or purposes
    • H04W4/40—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P]
    • 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

Definitions

  • Exemplary embodiments relate to a method of operating a first device, wherein said first device is configured to wirelessly transmit data to a second device.
  • FIG. 1 For exemplary embodiments, exemplary embodiments relate to a first device, wherein said first device is configured to wirelessly transmit data to a second device.
  • Exemplary preferred embodiments relate to a method of operating a first device, wherein said first device is configured to wirelessly transmit data to a second device, preferably using a wireless personal area network, WPAN, communications technology, wherein said method comprises: determining a random number (or a pseudorandom number), determining a hash value depending on said random number and first data, transmitting said hash value and said random number to said second device.
  • determining a random number or a pseudorandom number
  • determining a hash value depending on said random number and first data transmitting said hash value and said random number to said second device.
  • such transmissions of said first device and/or the first device itself cannot be tracked by a third party such as e.g. an attacker that monitors data transmissions between the first device and the second device.
  • a third party such as e.g. an attacker that monitors data transmissions between the first device and the second device.
  • an attacker may monitor conventional data transmissions and may detect several conventional data transmissions in which said same first data may be used by a transmitting device, which may be used to track such transmitting device. This is efficiently prevented by the approach according to preferred embodiments, and the first data is kept secret.
  • said first data is associated with at least one of: said first device, said second device, a target system for said first device, a target system for said second device, wherein preferably said target system for said first device is a mobile device such as e.g. a mobile phone, particularly smart phone, or a tablet computer, wherein preferably said target system for said second device is a control unit for a vehicle, preferably a control unit for a car, wherein preferably said first data characterizes or is a vehicle identification number, VIN.
  • a mobile device such as e.g. a mobile phone, particularly smart phone, or a tablet computer
  • preferably said target system for said second device is a control unit for a vehicle, preferably a control unit for a car
  • VIN vehicle identification number
  • a mobile phone may comprise the first device and/or may implement a functionality of said first device
  • a control unit of a vehicle such as a car may comprise said second device and/or may implement a functionality of said second device.
  • WPAN-based communication e.g. within a distance range of 0 meters (m) and 20 m, preferably between 0 m and 5m between said first and second device.
  • said method further comprises using at least one of the following hash functions for determining said hash value: SHA- 224, S HA-256, SHA-384, SHA-512, SHA-512/224 und SHA-512/256. Further details regarding these hash functions may be found at https://doi.orq/10.6028/NIST.FIPS.180-4. According to further preferred embodiments, other types of hash functions may also be used.
  • said step of determining said hash value further comprises: combining said random number with said first data to obtain a combination, applying a or said hash function (e.g., SHA-256) to said combination to obtain a hash function output, using at least a portion of said hash function output as said hash value.
  • a or said hash function e.g., SHA-256
  • said portion of said hash function output used as said hash value comprises twelve bytes, preferably the twelve most significant bytes of said hash function output.
  • said random number comprises four bytes.
  • combining said random number with said first data to obtain a combination may comprise at least one of: a) adding said random number to said first data (wherein said first data may e.g. also be considered to characterize a number), b) logically combining said random number with said first data, e.g. by using an AND or an XOR function or the like, c) concatenating said random number and said first data.
  • said concatenating may be performed by appending said random number to said first data.
  • said WPAN communications technology is based on a) the Bluetooth Low Energy, BLE, specification version 4.2 and/or on b) a specification at least partly compatible with the BLE specification version 4.2, particularly the Bluetooth Core Specification version 5.1 or higher.
  • BLE specifications are available at https://www.bluetooth.com/specifications/archived-specifications/.
  • said method further comprises: constructing an advertising message comprising a data field suitable for receiving a universally unique identifier, UUID, according to BLE specification version 4.2 (or a specification at least partly compatible with the BLE specification version 4.2, particularly the Bluetooth Core Specification version 5.1 or higher), and providing said hash value and said random number in said data field.
  • said first device may provide said hash value and said random number in the data field originally provided for receiving a plain text UUID according to the abovementioned BLE specification(s). I.e., according to further preferred embodiments, said first device "replaces" a plain text UUID value with said hash value and said random number.
  • said determining of said second hash value may be similar or identical to said determining of said hash value at the first device.
  • said second hash value (as obtained by the second device) is identical with said received hash value from said first device, it may be concluded that said first device possesses and/or has used first data for building said hash value which is identical to said reference data of said second device.
  • said first device uses a specific VI N together with a specific random number (e.g.
  • said second device determines the hash value to be transmitted to the second device, and if said second device also uses said same specific VIN (e.g., provided locally at the second device in form of its reference data) together with the specific random number as received from the first device, said second hash value is identical with said hash value as determined by and received from said first device.
  • said same specific VIN e.g., provided locally at the second device in form of its reference data
  • said reference data may be local data of said second device and/or a shared information, especially shared secret, known to both the first device and the second device, which enables the second device to efficiently evaluate the hash value received from said first device.
  • said reference data may be identical to said first data.
  • said reference data is associated with at least one of: said first device, said second device, a target system for said first device, a target system for said second device, wherein preferably, as mentioned above, said target system for said first device is a mobile device such as e.g. a mobile phone, particularly smart phone, or a tablet computer, wherein preferably said target system for said second device is a control unit for a vehicle, preferably a control unit for a car, wherein preferably said reference data characterizes or is a vehicle identification number, VIN.
  • a mobile device such as e.g. a mobile phone, particularly smart phone, or a tablet computer
  • said target system for said second device is a control unit for a vehicle, preferably a control unit for a car
  • VIN vehicle identification number
  • a second device configured to perform the method according to the embodiments.
  • the second device or its functionality may e.g. be integrated into a control unit for and/or of the vehicle.
  • Further preferred embodiments relate to a data carrier signal carrying the computer program according to the embodiments. Further preferred embodiments relate to a system comprising at least one first device according to the embodiments and at least one second device according to the embodiments.
  • Further preferred embodiments relate to a method of operating a system comprising at least one first device according to the embodiments and at least one second device according to the embodiments.
  • Further preferred embodiments relate to a use of the method according to the embodiments and/or of the first device according to the embodiments and/or of the second device according to the embodiments and/or of the computer program according to the embodiments and/or of the system according to the embodiments for at least one of: a) transmitting one or more messages, particularly advertising messages, preferably Bluetooth advertising messages according to the Bluetooth Low Energy, BLE, specification version 4.2 and/or above and/or a compatible specification, b) preventing tracking of said first device, c) improving privacy protection of said first device, d) establishing vehicle ownership, particularly when using said second device in said vehicle as a target system, e) gaining access to a vehicle, particularly when using said second device in said vehicle as a target system, preferably for automatic passive entry, APE, to said vehicle and/or for triggered passive entry, TPE, to said vehicle, and/or for remote keyless entry, RKE, to said vehicle, f) unlocking a vehicle, particularly when using said second device in said vehicle as a target system
  • the principle according to the embodiments may be used for setting up an initial WPAN, for example Bluetooth Low Energy (BLE), connection between two devices, i.e. the first device and the second device, e.g. based on a name and/or identifier ("id"), e.g. a VIN, preferably to identify, particularly uniquely identify, each other.
  • This identifier e.g. the VIN
  • VIN advertising message may be part of an (e.g., BLE) advertising message ("VIN advertising message”), wherein said first device may e.g. be configured to transmit such (BLE) advertising message upon a first connection with said second device.
  • said hash value can be created by the first device out of the identifier and a random number, as explained above.
  • the hash value and the random number may be sent within the advertising message (e.g., instead of a plain text UUID) from the first device to the second device.
  • an attacker is therefore not able to resolve out of the hash value and the random number the identifier, e.g. VIN.
  • the identifier is kept secret to the public.
  • only the second device can verify such an advertising message as provided by said first device, e.g. by creating out of the received random number within the advertising message and the known identifier (e.g., reference data) the second hash value for comparison with the received hash value of the advertising message.
  • Fig. 1 schematically depicts a simplified block diagram of devices according to preferred embodiments
  • FIG. 2A schematically depicts a simplified flow chart of a method according to further preferred embodiments
  • Fig. 2B schematically depicts a simplified flow chart of a method according to further preferred embodiments
  • FIG. 3 schematically depicts a simplified block diagram of an operational scenario according to further preferred embodiments
  • Fig. 4 schematically depicts a simplified block diagram of data according to further preferred embodiments
  • Fig. 5 schematically depicts a simplified block diagram of a first device according to further preferred embodiments
  • Fig. 6 schematically depicts a simplified flow chart of a method according to further preferred embodiments
  • Fig. 7 schematically depicts a simplified flow chart of a method of operating a second device according to further preferred embodiments
  • Fig. 8 schematically depicts a simplified flow chart of a method of operating a second device according to further preferred embodiments
  • Fig. 9 schematically depicts a simplified flow chart of a method of operating a system according to further preferred embodiments.
  • Fig. 10 schematically depicts a simplified block diagram according to further preferred embodiments
  • Fig. 11 Aschematically depicts a simplified block diagram of a data format according to further preferred embodiments,
  • Fig. 11 Bschematically depicts a simplified block diagram of a data format according to further preferred embodiments.
  • Fig. 12 to 24 each schematically depicts a simplified flow chart and/or state diagram according to further preferred embodiments.
  • Figure 1 schematically depicts a simplified block diagram of devices according to preferred embodiments.
  • a first device 100 is provided which is configured to wirelessly transmit data to a second device 200, cf. the arrow AM of Fig. 1.
  • both devices 100, 200 may be configured to wirelessly exchange data with each other.
  • said first device 100 may be configured to wirelessly transmit data to the second device and/or to wirelessly receive data from said second device 200.
  • said second device 200 may be configured to wirelessly receive data from said first device 100 and/or to wirelessly transmit data to the first device 100.
  • a wireless personal area network, WPAN communications technology
  • said WPAN communications technology is based on radio frequency signals that may be exchanged between said devices 100, 200 as known in the art.
  • said devices 100, 200 may form a system 1000, particularly communications system, preferably a WPAN communications system.
  • FIG. 1 Further preferred embodiments relate to a method of operating the first device 100, cf. Figure 2A, wherein said method comprises: determining 300 a random number RN, determining 302 a hash value HV depending on said random number RN and first data D1 , transmitting 304 said hash value HV and said random number RN to said second device 200 (Fig. 1).
  • This enables to securely transmit a representation of said first data D1 , in the form of the hash value HV, without requiring to directly transmit the first data D1 itself, i.e. as a plain text or plain data, respectively, to the second device 200.
  • a third party such as e.g.
  • an attacker that monitors data transmissions AM (Fig. 1) between the first device 100 and the second device 200.
  • AM data transmissions
  • an attacker may monitor conventional data transmissions and may detect several conventional data transmissions in which said same first data may be used by a transmitting device, which may be used to track such transmitting device. This is efficiently prevented by the approach according to preferred embodiments, and the first data is kept secret.
  • said first data D1 is associated with at least one of: said first device 100, said second device 200, a target system for said first device 100, a target system for said second device 200, wherein preferably said target system for said first device 100 is a mobile device 10, cf. Fig. 3, such as e.g. a mobile phone, particularly smart phone, or a tablet computer, wherein preferably said target system 20 for said second device 200 is a control unit for a vehicle, preferably a control unit for a car, or a car 20 with such control unit, wherein preferably said first data D1 characterizes or is a vehicle identification number, VIN, preferably of said vehicle 20.
  • a mobile device 10 cf. Fig. 3
  • said target system 20 for said second device 200 is a control unit for a vehicle, preferably a control unit for a car, or a car 20 with such control unit
  • VIN vehicle identification number
  • a mobile phone 10 may comprise the first device 100 and/or may implement a functionality of said first device, and a control unit of a vehicle such as a car or the car 20 (together with such control unit, not shown in Fig. 3) may comprise said second device 200 and/or may implement a functionality of said second device 200.
  • a control unit of a vehicle such as a car or the car 20
  • said second device 200 may implement a functionality of said second device 200.
  • WPAN-based communication e.g. within a distance range of 0 meters (m) and 20 m, preferably between 0 m and 5 m between said first and second device, said distance symbolically being indicated by double arrow D of Fig. 3.
  • said method further comprises using at least one of the following hash functions for determining said hash value: SHA (secure hash algorithm)-224, SHA-256, SHA-384, SHA-512, SHA-512/224, SHA- 512/256. Further details regarding these hash functions can be found at https://doi.orq/10.6028/NIST.FIPS.180-4. According to further preferred embodiments, other types of hash functions may also be used.
  • hash functions for determining said hash value: SHA (secure hash algorithm)-224, SHA-256, SHA-384, SHA-512, SHA-512/224, SHA- 512/256.
  • said step 302 (Fig. 2A) of determining said hash value HV further comprises, cf. Fig. 2B: combining 302a said random number RN with said first data D1 to obtain a combination comb, applying 302b a or said hash function, e.g., SHA-256, to said combination comb to obtain a hash function output HO, using 302c at least a portion of said hash function output HO as said hash value HV.
  • said hash function e.g., SHA-256
  • Figure 4 schematically depicts a simplified block diagram of data according to further preferred embodiments, wherein the block comb represents said combination of said first data D1 and said random number RN as mentioned above, wherein said block arrow HF of Fig. 4 represents an application of said hash function (also cf. step 302b of Fig. 2B), and wherein said block HO of Figure 4 represents said hash function output HO as obtained by step 302b.
  • Reference sign HO' of Fig. 4 indicates said portion of said hash function output HO which is preferably used as said hash value HV (Fig. 2B).
  • said portion HO' of said hash function output HO used as said hash value HV comprises twelve bytes, preferably the twelve most significant bytes of said hash function output HO.
  • said random number RN comprises four bytes.
  • said step 302a (Fig. 2B) of combining said random number RN with said first data D1 to obtain said combination comb may comprise at least one of: a) adding said random number RN to said first data D1 (wherein said first data D1 may e.g. also be considered to characterize a number), b) logically combining said random number RN with said first data D1 , e.g. by using an AND or an XOR function or the like, c) concatenating said random number RN and said first data D1.
  • said concatenating may be performed by appending said random number RN to said first data D1 , whereby the most significant bytes of said combination comb comprise said first data D1 and the least significant bytes of said combination comb comprise said random number.
  • said WPAN communications technology that may be used by said first device 100 (Fig. 1) and/or said second device 200 is based on a) the Bluetooth Low Energy, BLE, specification version 4.2 and/or on b) a specification at least partly compatible with the BLE specification version 4.2, particularly the Bluetooth Core Specification version 5.1 or higher.
  • BLE specifications are available at https://www.bluetooth.com/specifications/archived-specifications/.
  • Figure 5 schematically depicts a simplified block diagram of a first device 100a according to further preferred embodiments.
  • the first device 100 of Fig. 1 may comprise a configuration and/or structure at least similar or identical to the configuration 100a of Fig. 5.
  • Device 100a comprises at least one calculating unit 102 and at least one memory unit 104 associated with (i.e., usable by) said at least one calculating unit 102 for at least temporarily storing a computer program PRG and/or data DAT (e.g., a VID, the random number RN, and the like), wherein said computer program PRG is e.g. configured to at least temporarily control an operation of said device 100, 100a, e.g. the execution of a method according to the embodiments.
  • a computer program PRG e.g. configured to at least temporarily control an operation of said device 100, 100a, e.g. the execution of a method according to the embodiments.
  • the at least one calculating unit 102 may comprise at least one of the following elements: a microprocessor, a microcontroller, a digital signal processor (DSP), a programmable logic element (e.g., FPGA, field programmable gate array), an ASIC (application specific integrated circuit), hardware circuitry, a core. According to further preferred embodiments, any combination of two or more of these elements is also possible.
  • DSP digital signal processor
  • programmable logic element e.g., FPGA, field programmable gate array
  • ASIC application specific integrated circuit
  • the memory unit 104 comprises at least one of the following elements: a volatile memory 104a, particularly a random-access memory (RAM), a non-volatile memory 104b, particularly a Flash-EEPROM.
  • a volatile memory 104a particularly a random-access memory (RAM)
  • a non-volatile memory 104b particularly a Flash-EEPROM.
  • said computer program PRG is at least temporarily stored in said non-volatile memory 104b.
  • Data DAT which may e.g. be used for executing the method according to the embodiments, may at least temporarily be stored in said RAM 104a.
  • an optional computer-readable storage medium SM comprising instructions, e.g. in the form of a further computer program PRG’, may be provided, wherein said further computer program PRG’, when executed by a computer, i.e. by the calculating unit 102, may cause the computer 102 to carry out the method according to the embodiments.
  • said storage medium SM may comprise or represent a digital storage medium such as a semiconductor memory device (e.g., solid state drive, SSD) and/or a magnetic storage medium such as a disk or harddisk drive (HDD) and/or an optical storage medium such as a compact disc (CD) or DVD (digital versatile disc) or the like.
  • the first device 100a may comprise a data interface 106, preferably for wireless bidirectional data exchange with an external device (not shown in Fig. 5), such as e.g. the second device 200 (Fig. 1), e.g. according to at least one of said WPAN communication technologies as already mentioned above.
  • said data interface 106 may comprise a transmitter/receiver ("transceiver"), e.g. a BLE-compatible transceiver 106'.
  • an optional data carrier signal DCS may be received, e.g. from an external device (not shown).
  • the data carrier signal DCS may represent or carry the computer program PRG, PRG' according to the embodiments, or at least a part thereof.
  • transceiver 106' may also be used to transmit one or more messages AM (Fig. 1) from the first device 100a (Fig. 5) to the second device 200 (Fig. 1).
  • the first device 100a may be integrated into a mobile device 10 (Fig. 3).
  • the functionality of said first device 100a may at least partly be implemented by using existing components (hardware and/or software) of said mobile device 10.
  • said mobile device 10 may be a smartphone with a processor, a memory unit, and a transceiver, preferably a BLE-capable transceiver.
  • the processor of said smartphone 10 may perform at least some aspects of the method according to the embodiments, and/or the memory unit of said smartphone 10 may be used to stored at least portions of said data DAT (Fig. 5) and/or said computer program PRG, PRG', and/or the transceiver of said smartphone 10 may be used to transmit and/or receive data to/from said further device 200.
  • said method of operating the first device 100, 100a further comprises: constructing 304a an advertising message AM (also cf. Fig. 1) comprising a data field P26 (cf. Fig, 11B explained further below), said data field being suitable for receiving a universally unique identifier, UUID, according to BLE specification version 4.2 (or a specification at least partly compatible with the BLE specification version 4.2, particularly the Bluetooth Core Specification version 5.1 or higher), and providing 304b (Fig. 6) said hash value HV (Fig. 2A, 2B) and said random number RN in said data field p26 (Fig. 11B).
  • said first device 100 instead of using a plain text UUID value, said first device 100,
  • step 304c said advertising message AM is transmitted by said first device 100, 100a via its transceiver 106' (Fig. 5) to the second device 200 (also cf. Fig. 1).
  • first device 100, 100a wherein said first device 100, 100a is configured to wirelessly transmit data AM to the second device 200, preferably using a wireless personal area network, WPAN, communications technology, wherein said first device 100, 100a is configured to perform the method according to the embodiments.
  • WPAN wireless personal area network
  • FIG. 1 a method of operating a/the second device 200 (Fig. 1), also cf. Fig. 7, wherein said second device 200 is configured to wirelessly receive data AM from said first device 100, 100a, preferably using said wireless personal area network, WPAN, communications technology
  • said method of operating said second device 200 comprises: receiving 400 a hash value HV and a random number RN from said first device 100, 100a, evaluating 402 said received hash value HV depending on said received random number RN and depending on reference data RD, wherein preferably said evaluating 402 comprises, cf. Fig. 8, determining 402a a second hash value HV2 depending on said received random number RN and on said reference data RD and comparing 402b said second hash value HV2 with said received hash value HV.
  • said determining 402a of said second hash value HV2 at the second device 200 may be similar or identical to said determining of said hash value HV at the first device 100, 100a.
  • said second hash value HV2 (as obtained by the second device 200) is identical with said received hash value HV from said first device 100, 100a, it may be concluded that said first device 100, 100a possesses and/or has used said first data D1 (Fig. 2A) for building 302 (Fig. 2A) said hash value HV which is identical to said reference data RD (Fig. 7) of said second device 200.
  • said first device 100, 100a uses a specific VI N as said first data D1 together with a specific random number RN (e.g., also determined by said first device 100, 100a) to determine 302 the hash value HV to be transmitted to the second device 200, and if said second device 200 also uses said same specific VIN (e.g., provided locally at the second device 200 in form of its reference data RD) together with the specific random number RN as received (step 400 of Fig. 7) from the first device 100, 100a, said second hash value HV2 (Fig. 7) is identical with said hash value HV (Fig. 2A) as determined by and received from said first device.
  • a specific VI N e.g., also determined by said first device 100, 100a
  • said reference data RD may be local data of said second device 200 and/or a shared information, especially shared secret, known to both the first device 100, 100a and the second device 200, which enables the second device 200 to efficiently evaluate the hash value HV received from said first device 100, 100a.
  • said reference data RD may be identical to said first data D1.
  • said reference data RD is associated with at least one of: said first device 100, 100a, said second device 200, a target system 10 (Fig. 3) for said first device 100, 100a, a target system 20 for said second device 200, wherein preferably, as mentioned above, said target system 10 for said first device 100, 100a is a mobile device 10 such as e.g.
  • said target system 20 for said second device 200 is a control unit (or a part of a control unit) for a vehicle, preferably a control unit for a car 20 (or the car 20 with such control unit), wherein preferably said reference data RD characterizes or is a vehicle identification number, VIN, especially the VIN of said vehicle 20.
  • a second device 200 configured to perform the method according to the embodiments.
  • the second device 200 or its functionality may e.g. be integrated into a control unit for and/or of the vehicle 20.
  • the second device 200 and/or a control unit for receiving said second device 200 may comprise a structure similar or identical with the configuration of Fig. 5, wherein the computer program PRG, PRG' is configured to control at least an operation of the second device 200.
  • either device 100, 100a, 200 may be configured to at least temporarily perform the method according to at least one of Fig. 2A, 2B, 6 and/or according to at least one of Fig. 7, Fig. 8.
  • a device 100a (Fig. 5) may also be configured to at least temporarily perform the method of operating the first device 100, 100a as explained above and to at least temporarily perform the method of operating the second device 200 as explained above.
  • said first device 100, 100a may be configured to at least temporarily assume a "peripheral" role according to BLE 4.2, wherein said second device 200 may be configured to at least temporarily assume a "central” role according to BLE 4.2, cf. e.g. the BLE specification version 4.2, Vol 1, Part A: Architecture, Section 6.2 “Generic Access Profile” (GAP).
  • BLE 4.2 the BLE specification version 4.2, Vol 1, Part A: Architecture, Section 6.2 "Generic Access Profile” (GAP).
  • FIG. 5 Further preferred embodiments relate to a computer program PRG, PRG' (Fig. 5) comprising instructions which, when the program is executed by a computer 102, cause the computer 102 to carry out the method according to according to the embodiments.
  • FIG. 1 a system 1000 (Fig. 1) comprising at least one first device 100, 100a according to the embodiments and at least one second device 200 according to the embodiments.
  • system 1000 may be used to enable, preferably WPAN-type, communications between a control unit of a car 20 and a smartphone 10, cf. Fig. 3.
  • FIG. 1 a method of operating a system 1000 (Fig. 1 ) comprising at least one first device 100, 100a according to the embodiments and at least one second device 200 according to the embodiments.
  • Figure 9 schematically depicts a simplified flow chart of such a method according to further preferred embodiments.
  • the first device 100 determines a random or pseudorandom number RN.
  • the first device 100 determines a hash value HV, e.g. as explained in detail above with respect to Fig. 2A, 2B.
  • the first device 100 transmits said hash value HV and said random number RN to said second device 200, e.g. in the form of a BLE 4.2 compatible advertisement message AM (Fig. 1).
  • the second device 200 Upon receipt of said advertisement message AM, in step s3, the second device 200 determines a second hash value HV2 depending on the received random number RN and, preferably local, reference data RD. In step s4, the second device 200 compares the received hash value HV and the locally determined second hash value HV2. In a further, optional, step s5, the second device 200 controls an operation of the second device 200 and/or at least one further device (e.g., a control unit of said vehicle 20 (Fig. 3)) depending on said comparison of step s4.
  • a further device e.g., a control unit of said vehicle 20 (Fig. 3)
  • step s4 if said comparison of step s4 yields that said second hash value HV2 is equal to or identical with said received hash value HV from said first device, 100, said second device 200 may continue to exchange data with said first device 100, e.g. for initiating a BLE connection with said first device 100.
  • said comparison of step s4 if said comparison of step s4 yields that said second hash value HV2 is not equal to or identical with said received hash value HV from said first device, 100, said second device 200 may refrain from further data exchange with said first device 100, e.g. "ignoring" said advertisement message AM.
  • FIG. 10 Further preferred embodiments, cf. Figure 10, relate to a use 2000 of the method according to the embodiments and/or of the first device 100, 100a according to the embodiments and/or of the second device 200 according to the embodiments and/or of the computer program PRG, PRG' (Fig. 5) according to the embodiments and/or of the system 1000 (Fig.
  • a vehicle 20 in said vehicle 20 as a target system, e) gaining access to a vehicle 20, particularly when using said second device 200 in said vehicle 20 as a target system, preferably for automatic passive entry, APE, to said vehicle 20 and/or for triggered passive entry, TPE, to said vehicle 20, and/or for remote keyless entry, RKE, to said vehicle 20, f) unlocking a vehicle 20 or a component (e.g., trunk) thereof, particularly when using said second device 200 in said vehicle 20 as a target system, g) sending data, particularly user data associated with said first device 100, 100a and/or with a user of said first device 100, 100a, particularly to said second device 200, h) establishing connection to an unknown device, i) authenticating a connection to a device.
  • APE automatic passive entry
  • TPE triggered passive entry
  • RKE remote keyless entry
  • the principle according to the embodiments may be used for setting up an initial WPAN, for example Bluetooth Low Energy (BLE), connection between two devices 100,
  • BLE Bluetooth Low Energy
  • the first device 100 and the second device 200 i.e. the first device 100 and the second device 200, e.g. based on a name and/or identifier ("id"), e.g. a VIN, preferably to identify, particularly uniquely identify, each other.
  • This identifier e.g. the VIN, may be part of an (e.g., BLE) advertising message AM (Fig. 9), wherein said first device 100 may e.g. be configured to transmit such (BLE) advertising message upon a first connection with said second device 200.
  • said hash value HV can be created by the first device 100 out of the identifier VIN (first data D1) and a random number RN, as explained above.
  • the hash value HV and the random number RN may be sent within the advertising message AM (e.g., instead of a plain text UUID) from the first device 100 to the second device 200.
  • an attacker (not shown) is therefore not able to resolve out of the hash value HV and the random number RN the identifier, e.g. VIN.
  • the identifier is kept secret to the public.
  • only the second device 200 can verify such an advertising message AM as provided by said first device 100, e.g. by creating out of the received random number RN within the advertising message AM and the known identifier (e.g., reference data RD) the second hash value HV2 for comparison with the received hash value HV of the advertising message AM.
  • the known identifier e.g., reference data RD
  • Figure 11 A schematically depicts a data packet format DF according to further preferred embodiments, which may be used for transmitting messages, especially from the first device 100 to the second device 200 and/or vice versa.
  • said data packet format DF may be used to transmit said hash value HV and said random number RN (Fig. 2A) from said first device 100 (Fig. 1) to said second device 200, e.g. in form of an (BLE) advertisement message.
  • said data packet format DF may be used to transmit more than one 2-tuple (HV, RN) of a hash value HV and an associated random number RN from said first device 100 (Fig. 1) to said second device 200, e.g. in form of an (BLE) advertisement message.
  • said data packet format DF may comprise at least one of: a) a preamble P1 of e.g. 1 byte, b) an access address field P2 of e.g. 4 bytes, c) a protocol data unit, PDU, field P3 of preferably variable length (preferably ranging between 2 and 257 bytes), d) a redundancy information field P4, e.g. for a checksum, preferably crc-checksum, of e.g. 3 bytes.
  • BLE advertisement messages AM (Fig. 1), e.g. for broadcasting data, may conform to GAP (Generic Access Profile) according to the BLE specification 4.2 or above.
  • GAP Generic Access Profile
  • at least some, preferably all, BLE advertisement messages AM shall fit into a single PDU P3 (Fig. 11 A).
  • especially point-to-point connections (e.g., for sending commands), may conform to GATT (Generic Attribute Profile) according to the BLE specification 4.2 or above.
  • Figure 11 B schematically depicts a data packet format DF' according to further preferred embodiments, which may also be used for transmitting messages, especially from the first device 100 to the second device 200 and/or vice versa.
  • the data packet format DF' may comprise at least one of: a) a preamble P5 of e.g. 1 byte (e.g. having a value of "OxAA"), b) an access address field P6 of e.g. 4 bytes, c) a protocol data unit, PDU, field P7 of preferably variable length (preferably ranging between 8 and 39 bytes), d) a redundancy information field P8, e.g. for a checksum, preferably CRC (cyclic redundancy check)-checksum, of e.g. 3 bytes.
  • the PDU field P7 may comprise a PDU header P9 of e.g. 2 bytes and a PDU payload field P10 of variable length, e.g. ranging between 6 and 37 bytes.
  • the PDU header P9 may comprise at least one of: a) a PDU type field P11 of e.g. 4 bits, b) a transmit ("Tx") address field P12 of e.g. 1 bit, c) a receive ("Rx") address field P13 of e.g. 1 bit, d) a first reserved and/or unused field P14 of e.g. 2 bits, e) a length field P15 of e.g. 6 bits, e.g. to indicate said (variable) length of said PDU payload field P10, f) a second reserved and/or unused field P16 of e.g. 2 bits, g) an advertiser address field P17, e.g. of 6 bytes, e.g. for a BLE media access control (MAC) address, h) an advertising data field P18 of preferably variable length (preferably ranging between 0 and 31 bytes).
  • Tx transmit
  • Rx receive
  • P13 of e.g. 1
  • the advertising data field P18 may comprise at least one of: a) a flag field P19 of e.g. 3 bytes, b) a field P20 for holding one or more (e.g., a list of) UUIDs, preferably 128-bit UUIDs.
  • the flag field P19 may comprise at least one of: a) a length field P21 of preferably 1 byte, b) a type field P22 of preferably 1 byte, c) a data field P23 of preferably 1 byte.
  • the field P20 may comprise at least one of: a) a length field P24 of preferably 1 byte, b) an advertisement type field P25 of preferably 1 byte, c) at least one UUID field P26 of preferably 16 bytes.
  • the hash value HV and the random number RN according to preferred embodiments (cf. e.g. Fig. 2A, 9) may be provided in said UUID field P26 of Fig. 11 B.
  • the data packet formats DF, DF' explained above with reference to Fig. 11 A, 11 B may e.g. be used by the first device 100, 100a and/or target systems 10 for said first device 100, 100a such as e.g. smartphones for transmitting BLE advertising messages.
  • a unified advertising message structure may be provided which may e.g. be used for transmitting the hash value HV and said random number RN.
  • messages may comprise an advertising data field P18 (Fig. 11 B) according to the following examples related to tables T1 to T10.
  • a fixed value is indicated, e.g. in the tables T1 to T10, said fixed value may be set in this way for a plurality of, preferably for all, advertising messages.
  • variable value fields in the tables T1 to T10 may e.g. be, preferably dynamically (during runtime, e.g. of said first device), defined for each message.
  • a first advertising data block (“Adv Data Block") "AD 0" may comprise the data as defined in rows 2, 3, 4, while an N-th advertising data block may comprise the data as defined in rows 5, 6, 7 of table T 1 .
  • an advertising data block structure as exemplarily depicted by table T2 below may be used, preferably for advertisements, e.g. VIN advertisements, with a complete list of service UUIDs.
  • an advertising event type may be "Connectable Undirected (event)", also cf. e.g. Table 4.1 of BLUETOOTH SPECIFICATION Version 4.2 [Vol 6, Part B]
  • the data according to row 4 of Table T2 above may comprise said hash value HV as explained above, e.g. with respect to Fig. 2A, 9, and, according to further preferred embodiments, the data according to row 5 of Table T2 may comprise said random number RN as explained above, e.g. with respect to Fig. 2A, 9.
  • a new random number RN may be determined and/or used each time a user of the first device 100, 100a opens an activity, e.g. requiring access to an unknown vehicle 20 (Fig. 3). Such determination may e.g. be made in step 300 explained above with respect to Fig. 2A.
  • a new random number RN may be generated repeatedly, particularly periodically, especially during a connection (e.g., between said first device 100, 100a and said second device 200). This may further contribute to preventing a traceability of the user of the device 100, 100a.
  • an advertising data block structure as exemplarily depicted by table T3 below may be used, preferably for advertisements, e.g. VI N advertisements, with an incomplete list of service UUIDs.
  • an advertising event type may be "Connectable Undirected (event)", also cf. e.g. Table 4.1 of BLUETOOTH SPECIFICATION Version 4.2 [Vol 6, Part B].
  • a new random number RN may be determined and/or used each time a user of the first device 100, 100a opens an activity, e.g. requiring access to an unknown vehicle 20 (Fig. 3). Such determination may e.g. be made in step 300 explained above with respect to Fig. 2A.
  • a new random number RN may be generated repeatedly, particularly periodically, especially during a connection (e.g., between said first device 100, 100a and said second device 200). This may further contribute to preventing a traceability of the user of the device 100, 100a.
  • the vehicle 20 when the vehicle 20 (Fig. 3) or its second device 200, respectively, receives an advertisement message AM (Fig. 1 ), particularly VIN advertisement message AM, with incomplete list of service UUID, the vehicle 20 (or its second device 200, respectively) may send a scan request, particularly if at least one of the following conditions C1 , C2, C3 is not met: UUIDs received in the Advertisement
  • a data block structure as exemplarily depicted by table T4 below may be used, especially for scan response.
  • a data block structure as exemplarily depicted by table T5 below may be used, especially for Localisation Advertisement with Complete List of Service UUID.
  • an advertising event type Connectable Undirected.
  • a data block structure as exemplarily depicted by table T6 below may be used, especially for Localisation Advertisement with Incomplete List of Service UUID.
  • an advertising event type Connectable Undirected.
  • GATT Generic Attribute Profile
  • GATT services and associated characteristics in the System 1000 may/shall take the following format.
  • a service denoted as "PkTagSvc" may be provided and/or defined, wherein said service PkTagSvc may be used to exchange data between a tag and the master.
  • a tag may act as the server, and the master may act as the client.
  • a tag may be a (preferably mobile) device, e.g. the first device 100, 100a and/or a key fob. according to further preferred embodiments, said first device 100, 100a may also act as a key fob.
  • At least one or more of the below listed characteristics may be provided by and/or shall be available in the service PkTagSvc.
  • the service “PkTagSvc” may be used to transmit secure data from a tag 100 (Fig. 3) to the vehicle 20 (or its second device 200, respectively) and/or vice versa.
  • the message may be written in the form: Service. Characteristic(Command, Parameters), e.g. PkT agSvc.AuthT ext(RKE, RKE_Function).
  • the functional commands and corresponding parameters as exemplarily listed in table T9 below may be transmitted as a value field of the Characteristic Value Attribute of PkTagSvc.PlainTextQ, also cf. the row "PlainText" of table T8 above.
  • the functional commands and corresponding parameters as exemplarily listed in table T 10 below may be transmitted as the value field of the Characteristic Value Attribute of PkTagSvc.AuthTextQ, also cf. the row "AuthText" of table T8 above.
  • PkTagSvc.CAText() may be used to transmit messages, e.g. messages generated by and or provided by means of a (cryptographic) security library, preferably all such messages generated by and or provided by means of such/said (cryptographic) security library.
  • such messages may be transmitted as the value field of the Characteristic Value Attribute of PkTagSvc.CAText(), also cf. the row "AuthText" of table T8 above.
  • details of the content of each such message may be contained in a documentation of the security library.
  • Fig. 12 to 24 schematically depict simplified flow charts related to said further aspects and/or preferred embodiments which may be, either alone or in combination with each other, combined with at least one of the aspects and preferred embodiments explained above.
  • Figure 12 schematically depicts a flow-chart which may, according to at least some further preferred embodiments, relate to a use case "establishing vehicle ownership", wherein e.g. the first device 100, 100a according to the embodiments may be involved, which may e.g. be integrated into a smartphone, cf. block 10a of Fig. 12.
  • Block 11 of Fig. 12 may represent a user of the smartphone 10a
  • block 20a may represent a second device 200 (also cf. Fig. 3) according to the embodiments or a target system 20a for said second device 200, which target system 20a is preferably arranged in a vehicle 20.
  • the target system 20a is also named as "master", in accordance with its communication role with respect to the first device or smartphone 10a.
  • said smartphone 10a may be configured to provide a user interface 10a' (preferably graphical user interface, GUI) for the user 11 , e.g. to enable the user 11 to enter data such as e.g. the vehicle's unique VIN, and/or an (optional) ownership code. As an example, at least one of these steps may be performed during an Ownership Setup process.
  • said user 11 may chose and/or execute a function F1 (which may e.g. also be referred to as "AddNewVehicleO") to initiate a procedure at the smartphone 10a which enables to add a new vehicle.
  • a function F1 which may e.g. also be referred to as "AddNewVehicleO"
  • said smartphone 10a may execute a function F2 (which may e.g. also be referred to as "RequestVehicleDetails()"), for requesting vehicle details, especially of said vehicle which should be added as indicated by function F1.
  • a function F2 which may e.g. also be referred to as "RequestVehicleDetails()"
  • said user 11 may chose and/or execute a function F3 (which may e.g. also be referred to as "VehicleDetailsO") to provide detail data related to said new vehicle 20 (Fig. 3) to the smartphone 10a.
  • a function F3 which may e.g. also be referred to as "VehicleDetailsO"
  • such detail data related to said new vehicle 20 may e.g. comprise at least one of: the vehicle's unique VIN, and/or an (optional) ownership code.
  • the process of Fig. 12, which may also be referred to as “Ownership process” may, preferably after receiving the detail data of said new vehicle (function F3), utilize a block B1 (which may also be referred to as "Block_UnknownDeviceConnect”), preferably for connecting to an unknown device (e.g., the second device 20a of the new vehicle), details of which are explained further below with respect to Fig. 21.
  • a block B1 which may also be referred to as "Block_UnknownDeviceConnect”
  • an optional block B2 may be provided, which comprises a first section B2_1 and a second section B2_2.
  • At least one of said sections B1 _ 1 is selected from at least one of said sections B1 _ 1 ,
  • B2_2 is executed conditionally.
  • the Ownership process may proceed with execution of the first section B2_1 of block B1 , and, in other cases, i.e. if said PlainText attribute does not exist, the master 20a shall disconnect from the smartphone 10a, cf. dashed arrow a1 of the second section B2_2.
  • an optional block B2_1_1 (which may also be referred to as "Block_AuthConnection") may be utilized/executed, details of which are explained further below with respect to Fig. 22.
  • a further optional block B2_1_2 (which may also be referred to as " CAjDwnerRegistration") may be utilized/executed, details of which are provided in the Bluetooth specification.
  • the CAjDwnerRegistration procedure B2_1_2 may e.g. comprise a protocol that uses a current established Bluetooth connection is not detailed in this application.
  • said CAjDwnerRegistration procedure B2_1_2 is performed after the block B2_1_1.
  • the master 20a may register the new owner ID as its owner, cf. dashed arrow a2, and may optionally clear all previous authentication data from previous owners and/or shared users, cf. dashed arrow a3.
  • the exemplary ownership process according to Fig. 12 may utilize a bonding procedure within optional block B2_1_3 (which may also be referred to as "Block_Bonding"), details of which are explained further below with respect to Fig. 22.
  • the master 20a may send a message M2 to the smartphone 10a, wherein said message M2 e.g. signals a vehicle status to the smartphone 10, e.g. "PkTagSvc_AuthText(VehicleStatus)", which may e.g. signal the end of the Ownership process.
  • said message M2 e.g. signals a vehicle status to the smartphone 10, e.g. "PkTagSvc_AuthText(VehicleStatus)", which may e.g. signal the end of the Ownership process.
  • the system 1000 (Fig. 1), which may also be referred to as "PK System", is configured to support a user 11 (Fig. 12) taking ownership of the vehicle 20 (Fig. 3), e.g. according to Fig. 12, wherein e.g. GUID: 6cd086d4-8880-44a3-9d02-4bdecbdbb303.
  • Figure 13 schematically depicts a flow-chart which may, according to at least some further preferred embodiments, relate to a use case "known (smart)phone moves into range", wherein e.g. the smartphone 10a (and its first device 100, 100a) may be involved, as well as the vehicle 20 and its second device 20a.
  • known (smart)phone moves into range
  • the process of Fig. 13 may comprise a block B3 (which may also be referred to as "Block_KnownDeviceConnect”), details of which are explained further below with respect to Fig. 24.
  • an optional block B4 may be provided, which comprises a first section B4_1 and a second section B4_2.
  • at least one of said sections B4_1 , B4_2 is executed conditionally.
  • the process may proceed with execution of the first section B4_1 of block B4, and, in other cases, i.e. if said PlainText attribute does not exist, the master 20a shall disconnect from the smartphone 10a, cf. dashed arrow a4 of the second section B4_2.
  • the known device or smartphone 10a may use/execute the block B4_1_1 (which may also be referred to as "Block_AuthConnection"), details of which are explained further below with respect to Fig. 22.
  • the master 20a may send a message M3, preferably PkTagSvc_AuthText(VehicleStatus), to the smartphone 10a, i.e. similar to message M2 of Fig. 12. Preferably, this will signal the end of the Ownership process.
  • the system 1000 (Fig. 1), which may also be referred to as "PK System", as mentioned above, is configured to support a known device connection and authentication, e.g. according to Fig. 13, wherein e.g. GUID: 525aac52-9fa2-408b-869e-88bcd909b553.
  • Figure 14 schematically depicts a flow-chart which may, according to at least some further preferred embodiments, relate to a use case "first use by a friend (i.e., a user with a shared key)", wherein e.g. the smartphone 10a (and its first device 100, 100a, and the user 11 ) may be involved, as well as the vehicle 20 and its second device 20a.
  • the user 11 may initiate a first connection and authentication via a function F4, e.g. by opening an RKE (remote keyless entry) page or section of the user interface 10a', wherein said user interface 10a' may e.g. be provided by an application (e.g., computer program, "phone application”) running on the smartphone 10a.
  • Function F4 is preferably executed whilst the smartphone 10a is in a BLE communications range of the vehicle 20.
  • the smartphone 10a may enable the function F4 only after the master 20a sends vehicle status information (not shown in Fig. 14), e.g. similar to message M3 of Fig. 13. Temporarily disabling the function F4 may e.g. comprise visually indicating to the user 11 by means of the smartphone GUI 10a' that a GUI element (e.g., virtual "button") is currently not selectable and/or active, respectively, i.e. by "greying out” said GUI element. According to further preferred embodiments, once the smartphone 10a has received said vehicle status information from the master 20a, the smartphone 10a may activate its GUI element(s) for initiating the function F4.
  • a GUI element e.g., virtual "button
  • the process of Fig. 14 may comprise a block B1 (which may also be referred to as "BlockJJnknownDeviceConnect", also cf. Fig. 12), preferably for connecting to an unknown device, details of which are explained further below with respect to Fig. 21.
  • a block B1 which may also be referred to as "BlockJJnknownDeviceConnect”, also cf. Fig. 12
  • an optional block B5 may be provided, which comprises a first section B5_1 and a second section B5_2.
  • at least one of said sections B5_1, B5_2 is executed conditionally.
  • the process may proceed with execution of the first section B5_1 of block B5, and, in other cases, i.e. if said PlainText attribute does not exist, the master 20a shall disconnect from the smartphone 10a, cf. dashed arrow a5 of the second section B5_2.
  • an optional block B5_1_1 (which may also be referred to as "Block_AuthConnection") may be utilized/executed, details of which are explained further below with respect to Fig. 22.
  • a further optional block B5_1_2 (which may also be referred to as "Block_Bonding") may be utilized/executed, details of which are provided in Fig. 23.
  • said Block_Bonding procedure B5_1_2 is performed after the block B5_1_1.
  • the master 20a shall send a message M4 (e.g., as "PkTagSvc_AuthText(VehicleStatus)" to the smartphone 10a signaling that it (i.e., the smartphone 10a) may now activate the GUI element(s) (e.g., RKE buttons) on the GUI provided by said phone application.
  • the smartphone 10a may active said GUI element(s), cf. "message" M5.
  • the master 20a is configured to wait, cf. block B6 of Fig. 14, for the user 11 to select the GUI element, e.g., press the "Unlock button", on the phone application ("RKE event").
  • the master may enable the functionality of Passive Entry (APE and/or TPE) and/or Passive Start, cf. the dashed arrow a6.
  • the system 1000 (Fig. 1) ("PK System”), is configured to support friend unknown device connection and/or authentication e.g. according to 14, wherein e.g. GUID: 70bafc90-d7eb-41d0- 9b8f-a1fb31ed2806.
  • Figure 15 schematically depicts a flow-chart which may, according to at least some further preferred embodiments, relate to a use case "active connection", wherein e.g. the smartphone 10a (and its first device 100, 100a, and the user 11 ) may be involved, as well as the vehicle 20 and its second device 20a, and an optional anchor 12.
  • active connection e.g. the smartphone 10a (and its first device 100, 100a, and the user 11 ) may be involved, as well as the vehicle 20 and its second device 20a, and an optional anchor 12.
  • the anchor 12 may support the master (e.g., second device 20a), e.g. to compute a current position of the mobile device 10a, e.g. using trilateration.
  • a vehicle 20 may have two or more anchor nodes 12 distributed all over the vehicle's body, which may e.g. communicate with the master 20a using vehicle's CAN bus and/or proprietary connection.
  • the anchor nodes 12 may be listening for Localisation_Advertisement() message of already connected devices to calculate distance using trilateration, such as e.g. message M6 of block B8 explained below.
  • the anchor 12 may be omitted, and a corresponding functionality may at least partly be implemented by the second device 20a.
  • An optional first block B7 of Fig. 15 represents a procedure similar to that explained above with respect to Figure 13, which may e.g. relate to a use case "known (smart)phone moves into range”.
  • the smartphone 10a sends at least one message M6, e.g. a Localisation_Advertisement() message M6 to the master 20a.
  • the smartphone 10a repeatedly, preferably periodically, e.g. corresponding to an advertising interval PMFastLocAdvlnterval, sends said advertisement message M6 to the master 20a.
  • the message(s) M6 of Fig. 15 may correspond with the advertisement message AM (Fig. 1 , 9) according to the embodiments explained above and may as such e.g. comprise the hash value HV and the random number RN as explained above, cf. e.g. Fig. 2A.
  • said smartphone 20a is configured to receive a specific message (not shown in Fig, 15) from the master 20a, and to send at least one of said messages M6 as explained in the preceding paragraph once the specific massage from the master 20a is received.
  • said smartphone 20a is configured to receive a PkTagSvc_AuthText(VehicleStatus) message M3 (cf. Fig. 13) as said specific message from the master 20a, and to send at least one of said messages M6 (Fig. 15) as explained in the preceding paragraph to the master 20a once the specific massage M3 from the master 20a is received.
  • the smartphone 10a may commence (or continue) to send Localisation_Advertisement() messages M6, preferably at the advertising interval PMFastLocAdvlnterval.
  • the anchor 12 may, e.g. upon receipt of a/said advertisement message M6 from said smartphone 10a, perform a BLE address decoding operation, which may also be referred to "DecodeBLEAddress()", cf. dashed arrow a7.
  • the anchor 12 may transmit output data obtained by said BLE address decoding a7 and/or data derived from said output data to said master 20a, cf. the message M7.
  • the master 20a may perform a localization procedure, cf. dashed arrow a8 of block B8 of Fig. 15.
  • an optional block B9 is provided which relates to vehicle status changes. Details of this optional block B9 are explained further below with reference to Fig. 16.
  • an optional block B10 is provided which relates to cases of lost connection.
  • the smartphone 10a may send a message M8 to the master, said message M8 e.g. indicating that an exit, by the smartphone 10a, of the BLE communication range with the master 20a is planned and/or has occurred.
  • the master 20a may update its whitelist, e.g. by executing an "UpdateWhitelist()" function, cf. dashed arrow a9.
  • the master 20a may send a message M9 to the anchor 12 to signal to the anchor 12 that it should remove a certain tag, preferably associated with and/or represented by said smartphone 10a (or its first device 100, 100a, respectively).
  • the anchor 12 may remove said tag as signaled via said message M9, e.g. by updating its whitelist, cf. dashed arrow a10.
  • the anchor 12 may also use an "UpdateWhitelistQ" function a10, which may e.g. be similar or identical to the "UpdateWhitelistO" function a9 of the master 20a.
  • the anchor 12 of Fig. 15 may comprise a structure similar or identical with the configuration 100a of Fig. 5, wherein the computer program PRG, PRG' is configured to control at least an operation of the anchor 12, e.g. according to at least some aspects of the process exemplarily depicted by Fig. 15.
  • the system 1000 (Fig. 1) ("PK System”), is configured to support vehicle status updates, e.g. in form of message M3 of Fig. 13, wherein e.g. GUID: b9194229-66c9-4d9f-96a5- c53ee7892f24.
  • Figure 16 schematically depicts a flow-chart which may, according to at least some further preferred embodiments, relate to a use case "vehicle status changes", wherein e.g. the smartphone 10a (and its first device 100, 100a) and the user 11 may be involved, as well as an entity 21 of the vehicle 20 (i.e., representing the vehicle) and its second device 20a.
  • the entity 21 of the vehicle 20 may represent one or more electronic control units (ECUs) of said vehicle, similar to the master 20a, which may also represent an ECU of said vehicle 20, comprising the second device 200 or the functionality of the second device 200).
  • ECUs electronice control units
  • a status change of the vehicle 20 may occur, for example when a door of the vehicle is opened or closed or the like.
  • the vehicle 20, or rather the respective ECU 21 of the vehicle 20 may send a message M10 (e.g. referred to as "StatusUpdate()"), to the master 20a.
  • the master 20a may send a further message M11 to said smartphone 10a, preferably via the WPAN communications, i.e. BLE data connection between the devices 20a, 10a, wherein said message M11 may e.g.
  • Message M11 may e.g. be transmitted in a secure manner to smartphone 10a, cf. e.g. the row "AuthText" of table T8 above.
  • the smartphone 10a may update its GUI, cf. the arrow a11 , i.e. to notify the user 11 of the vehicle status change characterized by the message M11.
  • the update a11 of the GUI may e.g. be performed if the application of the smartphone 10a is currently running and/or in the foreground, i.e. visible to the user 11.
  • the vehicle status change may be signaled to the user 11 by means of a notification M12.
  • existing notification mechanisms of e.g. an operating system of the smartphone 10a may be used, e.g. indicating said notification in a status bar and/or notification bar of the smartphone's display, and/or performing an acoustic notification.
  • Figure 17 schematically depicts a flow-chart which may, according to at least some further preferred embodiments, relate to a use case "automatic passive entry” (APE), wherein the following entities may be involved: user 11, smartphone 10a, master 20a, an entity 21 ' of the vehicle 20, wherein said entity 21' may e.g. be similar to entity 21 (Fig. 16), e.g. another ECU of the vehicle 20, e.g. a body computer module (BCM), which represents a domain control unit e.g. for body electronic functions of said vehicle 20.
  • the system 1000 (“PK system”) may be configured to support APE as explained in detail further below.
  • APE Automatic Passive Entry
  • PK System 1000 Fig. 1
  • APE may also be referred to as “Approach Unlock” or “Auto Unlock.”
  • a methodology related to APE e.g.
  • any tag e.g., smartphone 10a
  • the vehicle 20 shall automatically unlock the door/s
  • - If no tags with UNLOCK permission remain localized within the defined STAY-UNLOCKED zone/s, the vehicle 20 shall automatically lock the door/s, -
  • RKE and Triggered PE (passive entry) operations may override Automatic PE operations.
  • automatic PE operations are only resumed after a PE zone transition into the same state as set by the RKE or triggered operation.
  • the APE_Timer may be reset, preferably with a value of APE_Delay_Cfg.
  • TagslnUnlockZone may or shall be set to ANY. According to further preferred embodiments, else, TagslnUnlockZone shall be set to NONE.
  • APE Unlock shall/may proceed, preferably simultaneously, for all zones which contain tags with UNLOCK permission.
  • a methodology related to APE lock may comprise one or more of the following aspects: If the current state of APE_Arbitration is AutoJJnlocked (cf. e.g. state S_1_2 of Fig. 18 explained further below), and APE_Lock_Preconditions becomes TRUE, then a corresponding APE Unlock event shall be requested.
  • an APE Request may comprise at least one of the following aspects:
  • a message format related to an APE Request may be comparatively generic, where e.g. a specific vehicle implementation of the request and/or a response, e.g. via LIN (local interconnect network) or CAN (controller area network) may/shall be defined in a specification for that vehicle implementation.
  • LIN local interconnect network
  • CAN controller area network
  • an execution of a successful APE Lock/Unlock event may be or shall be realised according to e,g, Fig. 17.
  • the PK System 1000 may or shall support Automatic Passive Entry behaviour, wherein e.g. (GUID: 05cbcca4-c803-4b36-8f5d-03ee2e2e8e18).
  • the optional block B12 represents an exemplary use case according to which a known device comes into range, also cf. Figure 13.
  • the smartphone 10a sends a message M13 to the master 20a, wherein preferably the message M13 may be referred to as "CrossAccessZoneBoundaryQ".
  • a boundary may be defined as an edge of a zone in which locking and unlocking passively is permitted (edge of UNLOCK ZONE).
  • the process of Fig. 17 may comprise, preferably after execution of said optional function a12, a further optional block B13, wherein said block B13 may comprise a waiting process.
  • said block B13 may comprise waiting until the abovementioned APE preconditions, e.g. CrossAccessZoneBoundary(), are satisfied.
  • At least one optional APE request message M14 may be sent from the master 20a to the BCM 21'.
  • said BCM 21' may process said at least one received optional APE request message M14, cf. dashed arrow a13.
  • said processing a13 may also be referred to as "Process_Access_Request()".
  • said BCM 21' may send at least one APE response message M15 to the master 20a.
  • said APE response message M15 may e.g. be used to signal a vehicle lock status to the master 20a.
  • the master 20a may signal information related to said at least one APE response message M15 to the smartphone 10, cf. the message M16.
  • At least one of said messages M14, M15 may be transmitted using at least one, preferably at least partly vehicle- internal, communication system such as e.g. a vehicle data bus, e.g. of the LIN- or CAN type or the like.
  • said messages M14, M15 are preferably transmitted via a vehicle-internal, preferably wired, data communication, as compared to e.g. the WPAN-type wireless (preferably BLE 4.2 compatible) data transmission M16 between the devices 10a, 20a.
  • a further block B14 may be provided, which may e.g. comprise signaling the vehicle status to the user 11.
  • said block B14 of the exemplary process according to Fig. 17 may e.g. be identical or at least similar to block B11 of Fig. 16.
  • Figure 18 exemplarily depicts a simplified state diagram according to further preferred embodiments.
  • the PK System 1000 may or shall manage a Vehicle Lock Status with respect to APE according to e.g. Fig.
  • GUID abd75c54-2a2b-4613-9736-a35a118e57c4.
  • the locked state S_1 may comprise at least one of the following states: a) S _ 1 _ 1 , corresponding to "Trigger_Locked", b) S_1_2, corresponding to "Auto_Locked".
  • the unlocked state S_2 may comprise at least one of the following states: a) S_2_1 , corresponding to "TriggerJJnlocked", b) S_2_2, corresponding to "AutoJJnlocked”.
  • a predetermined time interval such as e.g. the last 1000 milliseconds (ms) may be considered. This facilitates considering case where e.g. the tag (e.g. in form of the smartphone 10a) moves to a new zone, particularly before the VehicleLockStatus changes.
  • FIG 19 schematically depicts a flow-chart which may, according to at least some further preferred embodiments, relate to a use case "triggered passive entry” (TPE), wherein the following entities may be involved: user 11, smartphone 10a, master 20a, and vehicle 20 or an entity 2T such as BCM 2T of Fig. 17, respectively.
  • TPE triggered passive entry
  • the PK System 1000 may or shall support TPE according to a least one of the following aspects.
  • TPE Triggered Passive Entry
  • PEPS PEPS
  • Cap Sensor Unlock Cap Sensor Unlock
  • Button Press Unlock PEPS
  • a methodology related to TPE may comprise one or more of the following aspects: a) - If the user activates the defined unlock trigger, and any authenticated tag with UNLOCK permission is localized within the UNLOCK zone, the vehicle 20 (Fig. 3) shall unlock the door/s. b) - If the user activates the defined lock trigger, and any authenticated tag with UNLOCK permission is localized within the UNLOCK zone, the vehicle 20 shall lock the door/s.
  • a Triggered Passive Entry command from the user may (preferably shall always) result in a corresponding request from the master 20a to the vehicle interface 2T, regardless of any recent Automatic Passive Entry, Triggered Passive Entry, or Remote Keyless Entry event.
  • the PK System 1000 if the PK System 1000 receives a request for access to the Rear Access Entry Zone ("Trunk”), and there are not any authenticated and connected tags with TRUNK permission localised in the TRUNK zone; then the PK System 1000 shall take no further action.
  • Trustk Rear Access Entry Zone
  • a TPE Request may comprise at least one of the following aspects:
  • a message format related to a TPE Request may be comparatively generic, where e.g. a specific vehicle implementation of the request and/or a response, e.g. via LIN (local interconnect network) or CAN (controller area network) may/shall be defined in a specification for that vehicle implementation.
  • LIN local interconnect network
  • CAN controller area network
  • TPE TPE
  • AccessFunction Trunk.
  • the master 20a may or shall support Triggered Passive Entry behaviour according to e.g. Fig. 19, wherein e.g. GUID: 01ca0945-143a-4dc4- 9d9c-93ec893f6778.
  • the optional block B7' represents an exemplary use case according to which a known device comes into range, similar to block B7 of Figure 15, also cf. Fig. 13.
  • Arrow a14 of Fig. 19 indicates a signal, particularly a trigger signal (which according to further preferred embodiments may also be referred to as "PE_Trigger(AccessZone)”), e.g. from user 11 (or the (smart)phone 10a, respectively) to the vehicle 20 and/or its BCM 2T, respectively.
  • the BCM 2T may send a message M17 to the master 20a, which may perform an optional process a15, e.g. of checking a tag location, preferably depending on access zone information which may have been comprised e.g. within said message M17.
  • an optional process a15 e.g. of checking a tag location, preferably depending on access zone information which may have been comprised e.g. within said message M17.
  • the tag e.g., in form of the smartphone 10a
  • the access zone as e.g. determined in the process a15
  • the further optional block B15 is executed.
  • the master 20a may request access to the vehicle, e.g. by using the message M18 which is sent from the master 20a to the BCM 2T.
  • the BCM 2T may process such access request, cf. dashed arrow a16.
  • the BCM 2T may send an access response message M19 to the master 20a, preferably after said step of processing a16.
  • the master 20a may send a message M20 to the smartphone 10a, particularly a message M20 of the PkTagSvc_AuthText(VehicleStatus)-type.
  • the vehicle status may be signaled from the master 20a to the smartphone 10a in a secure manner.
  • a further block B16 may be provided, which may e.g. comprise signaling the vehicle status from the smartphone 10a to the user 11.
  • said block B16 of the exemplary process according to Fig. 19 may e.g. be identical or at least similar to block B11 of Fig. 16.
  • FIG. 20 schematically depicts a flow-chart which may, according to at least some further preferred embodiments, relate to a use case "remote keyless entry” (RKE), wherein the following entities may be involved: user 11, smartphone 10a, master 20a, and vehicle or an entity 21' such as BCM 21', respectively.
  • RKE remote keyless entry
  • the PK System 1000 may or shall support RKE according to a least one of the following aspects.
  • Remote Keyless Entry is one available method for gaining vehicle access, which may be supported by the PK System 1000 (Fig. 1).
  • a methodology related to RKE may comprise one or more of the following aspects: a) - If the user presses a button on a connected and authenticated remote device (e.g., KEYFOB or Mobile Phone App on the smartphone 10a), the vehicle 20 may execute a command associated with that button press, b) buttons available to the user (e.g., on the GUI of the smartphone 10a) may include (but are not limited to): b1) Unlock, b2) Lock, b3) Trunk Open, b4) Global Window Open, b5) Global Window Close, b6) Panic Alarm.
  • a button on a connected and authenticated remote device e.g., KEYFOB or Mobile Phone App on the smartphone 10a
  • buttons available to the user e.g., on the GUI of the smartphone 10a
  • buttons available to the user may include (but are not limited to): b1) Unlock, b2) Lock, b3) Trunk Open, b4) Global Window Open, b5) Global Window Close, b6) Pan
  • RKE may be supported by the PK System 1000 (Fig. 1); where RKE is defined as a deliberate user action, resulting in a request for vehicle access functionality.
  • RKE shall/may be supported by the (smart)Phone 10a, e.g. acting as a Tag.
  • RKE shall/may be supported by the keyfob as Tag.
  • a valid and authenticated Remote Keyless Entry command from the User 11 shall (preferably always) result in a corresponding request from the Master 20a to the BCM 21', e.g. preferably taking priority over any recent Automatic Passive Entry, Triggered Passive Entry, or Remote Keyless Entry event.
  • RKE functions may be initiated with preferably 100% reliability from a single user activation request with a line of sight radius from 0 to 30 meters (m) measured from a center of the vehicle 20.
  • the master 20a may or shall send an RKE request to the vehicle communication interface 2T, preferably within 500 milliseconds (ms) of user activation of the request.
  • RKE commands may or shall be transmitted from the Tag 10a (smartphone 10a and/or keyfob) to the master 20a in the form of a connected message "PkT agSvc.AuthT ext(RKE)".
  • the PK System 1000 shall support Remote Keyless Entry according to e.g. Fig. 20, wherein e.g. GUID: 5ebb5304-7746-430a-9f32-9202a166edb5.
  • RKE_Function there shall be a 1- byte identifier, RKE_Function, packaged in the RKE command from the Tag 10a to the Master 20a , which identifies the type of vehicle access functionality being requested by the user 11.
  • the RKE_Function shall have the following enumerations: 0x00 - No Action, 0x01 - Unlock, 0x02 - Lock, 0x03 - Trunk Release, 0x04 - Global Open Windows, 0x05 - Global Close Windows, 0x06 - Panic Alarm (e.g., flash lights and sound horn), 0x07 to OxFF - Reserved (No Action).
  • the Tag 10a may or shall generate a random, Tag-Vehicle Unique, preferably 16-byte AES (advanced encryption standard) key e.g. usable for a RKE_MAC calculation, which may e.g. be shared with the master 20a, preferably during every authentication event, e.g. as RKE_AESKey.
  • SHA-256 Secure Hash Algorithm 2
  • TID + VI D + RKE_RC + RKE_Function may be used to generate a preferably 32-byte output from e.g. 27-byte input ( TID + VI D + RKE_RC + RKE_Function).
  • the master 20a shall accept an RKE command from a Tag 10a (preferably only) if all fields in the RKE_String match the expected values.
  • the master 20a may accept an RKE command from a Tag only if the RKE_RC is in the acceptable range of: (RKE_RC_prev : RKE_RC_prev + RKE_RC_window).
  • the RKE_RC may be incremented modulo OxFFFFFFFF (unit32) on each button press (user RKE request, i.e. function activation by user on the GUI 10a'), where according to further preferred embodiments, the command is preferably only sent after the RKE_RC has been incremented.
  • an RKE Request may comprise at least one of the following aspects:
  • a message format related to an RKE Request may be comparatively generic, where e.g. a specific vehicle implementation of the request and/or a response, e.g. via LIN (local interconnect network) or CAN (controller area network) may/shall be defined in a specification for that vehicle implementation.
  • LIN local interconnect network
  • CAN controller area network
  • the user may select a function, i.e. by pressing a (virtual) button on the GUI 10a' of the smartphone 10a, cf. arrow a17, which may, according to further preferred embodiments, be considered as an external trigger.
  • the smartphone 10a may send a message M21 via wireless WPAN connection, e.g. BLE 4.2, to the master 20a, e.g. using a "PkT agSvc_AuthT ext(RKE)" function.
  • an optional block B17 may be executed, particularly if said process a18 yields that said RKE request of message M21 is valid.
  • the master 20a may send an access request for RKE, e.g. in form of the message M22, e.g. over LIN and/or CAN and/or another, preferably at least partly vehicle-internal, communication bus, to the BCM 21'.
  • said RKE access request M22 may comprise at least one of: information related to RKE, information related to an access function, information related to an ID of the tag 10a.
  • the BCM 21' may process said RKE access request M22, cf. the dashed arrow a19, and may, preferably after said processing a19, send an RKE access response message M23 to the master 20a, preferably again over LIN and/or CAN or the like.
  • said RKE access response message M23 may comprise information on a vehicle lock status.
  • the master 20a may send a message M24 (i.e., via BLE 4.2) to the smartphone 10a, particularly a message M24 of the PkTagSvc_AuthText(VehicleStatus)-type.
  • a message M24 i.e., via BLE 4.2
  • the smartphone 10a may send a message M24 (i.e., via BLE 4.2) to the smartphone 10a, particularly a message M24 of the PkTagSvc_AuthText(VehicleStatus)-type.
  • the vehicle status may be signaled from the master 20a to the smartphone 10a in a secure manner.
  • a further block B18 may be provided, which may e.g. comprise signaling the vehicle status from the smartphone 10a to the user 11.
  • said block B18 of the exemplary process according to Fig. 20 may e.g. be identical or at least similar to block B11 of Fig. 16.
  • Figure 21 schematically depicts a flow chart according to further preferred embodiments, wherein said block B1 (cf. e.g. the "Block_UnknownDeviceConnect” block B1 of Fig. 12) is detailed.
  • the smartphone 10a in order to connect to a new vehicle 20 for the first time, shall send a VINAdvertisement(), cf. the message M25 of Fig. 21 , and also cf. the advertisement message AM of Fig. 1.
  • the LSB of the calculated Proximity UUID may be incremented by 1, making the BaseUUID of the Proximity UUID equal to XXXXXXX-0000-1000-8000-00805F9B34FC.
  • the smartphone 10a may advertise the VINAdvertisementQ M25 (i.e., send repeatedly (e.g., every 100 ms) the advertisement message M25 related to a VI N) until either the master 20a initiates a connection, cf. message M26 of Fig. 21 , or after a timeout of VINAdvPeriod (ms) expires, cf. arrow a20, in which case the smartphone 10a may provide a failure notification to the user 11 via the smartphone's user interface (e.g., GUI 10a'), cf. the arrow a21 in the second section B19_2 of the block B19.
  • the smartphone's user interface e.g., GUI 10a'
  • block B20 may be executed, which represents a simplified BLE service discovery process.
  • this service discovery process B20 several BLE service discovery messages M27a, M27b may be exchanged, wherein more specifically, message M27a represents a service discovery, and message M27b represents a service information.
  • the PK System 1000 shall support the Connection to an unknown device according to e.g. Fig. 21, wherein e.g. GUID: ccf9fa9a-ad50-468d-ab17-bd00e60c58c7.
  • Figure 22 schematically depicts a flow chart according to further preferred embodiments, wherein e.g. said block B2_1_1 (cf. e.g. the " Block_AuthConnection" block B1 of Fig. 12) is detailed.
  • the master 20a may send a message M28, which may e.g. be referred to as "PkTagSvc_PlainText(AUTH_START)" to the smartphone 10a.
  • an optional block B21 may follow, which represents a protocol for a connection setup, e.g. as defined in a security library, that e.g. uses a current established Bluetooth connection between the devices 10a, 20a and which is not further detailed.
  • block B21 may be used to perform and/or complete, cf. arrow a24 an authentication of the smartphone 10a with respect to the master 20a.
  • connection setup process (as an example also referred to as "CA_ConnectionSetup process"), e.g. using block B21 , is completed
  • the smartphone 10a may send a message M29, which may e.g. also be referred to as "PkTagSvc_PlainText(TAG_DONE)" to the master 20a.
  • the master 20a may mark the Authentication as OK, cf. the dashed arrow a25 of section B22_1 of block B22.
  • the CA_ConnectionSetup process B21 has an authentication failure (e.g., for the first time, detected by the master 20a, cf. section B22_2 of block B22)
  • the Block_AuthConnection i.e., the complete process according to Fig. 22
  • the master 20a shall disconnect from the phone, cf. the dashed arrow a26.
  • the CA_ConnectionSetup process has an authentication failure (first time, detected by the smartphone 10a, cf.
  • the smartphone 10a may send a message M30 to the master 20a, e.g. a message M30 of the type "PkTagSvc_PlainText(AUTH_FAIL)", indicating the authentication fail to the master 20a, and the Block_AuthConnection (i.e., Fig. 22) may restart from the top, cf. block B22_3a.
  • the smartphone 10a may disconnect from the master 20a.
  • the PK System 1000 shall support the Authentication of the Connection to the phone 10a according to e.g. Fig. 22, wherein e.g. GUID: 147144d5-d68f-423c-afe0-e5a987d0e78a.
  • Figure 23 schematically depicts a flow chart according to further preferred embodiments, wherein e.g. said block B_2_1_3 of Fig. 12 is detailed.
  • the PK System 1000 shall support Bonding of the smartphone 10a connection according to e.g. Fig. 23, wherein e.g. GUID: 77a8871e-acdd-4aa9-bbd8-75b926e54044.
  • the exemplary bonding process of Fig. 23 comprises at least one of the following elements and/or actions: a) master 20a sends a BLE_Bonding() message M31 to smartphone 10a, b) smartphone 10a signals to user 11 Bonding Request M32, e.g. via a phone app, via a GUI 10a', c) user 11 approves of bonding, i.e. "sending" a bonding approval input M33 to smartphone 10a, i.e. via GUI 10a' and/or the phone app, d) smartphone sends a BLE_Bonding() message M34 to master 20a, e) smartphone may send a BondingComplete() message M35 to user 11 , i.e. via GUI 10a' and/or the phone app, to indicate completion of the bonding process.
  • Figure 24 schematically depicts a flow chart according to further preferred embodiments, wherein e.g. said block B3 ("Connection to a known device") of Fig. 13 is detailed.
  • the smartphone 10a may send one or more Localisation() advertisements M36, preferably repeatedly with period PMSIowLocAdvlnternal.
  • a Proximity UUID field for LocalisationAdvertisement() may be equal to the CharacteristicJJUID of PlainText.
  • the smartphone 10a may send VINAdvertisement() messages M37 (also cf. the advertisement message AM of Fig. 1 , 9), preferably repeatedly with a period PMSFastLocAdvlnternal.
  • the master 20a may scan for advertisements M36, M37 as outlined below.
  • the master 20a if the master 20a hears a LocalisationO advertisement M36 from a smartphone 10a with a Private Device Address, it shall attempt to resolve that address, cf. arrow a28, using the locally stored IRK's, according to the Bluetooth specification version 4.2, [Vol 3, Part C] ⁇ 1.3.2.3, "Private Device Address Resolution", and request a connection, cf. message M36a.
  • the master 20a may hear a VINAdvertisement(VIN) M37, i.e. containing the (preferably unique) VIN of that vehicle 20 (e.g., in form of the hash value HV), it may request a connection, cf. message M37a.
  • preparation of an initial BLE connection may be performed at the master 20a, cf. arrow a29.
  • any other advertisements heard by the master 20a, and not meeting the above criteria may be filtered out and ignored.
  • the master 20a may perform a service discovery, cf. block B24, on the smartphone 10a, and e.g. check, cf. the dashed arrow a23, for the "PlainText" attribute, also cf. the row "PlainText" of table T8 above.
  • the elements B24 and a23 of Fig. 24 correspond with the elements B20 and a23 of Fig. 21.
  • connection shall be established with a shortest possible connection interval supported by the smartphone 10a, in order to facilitate maximum throughput of data (and hence, speed), especially in the authentication phase.
  • the PK System 1000 shall support the Connection to a known device according to e.g. Fig. 24, wherein e.g. GUID: 10b0d375-adf0-4b90-95b1-a05aaab3e729.
  • the principle according to the embodiments at least sometimes enables one or more of the following aspects and/or advantages: a) well-defined method for a digital key enabled smart device 10a to communicate with vehicles 20 and other BLE enabled devices 200, 20a,

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mechanical Engineering (AREA)
  • Power Engineering (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

L'invention concerne un procédé pour faire fonctionner un premier dispositif, ledit premier dispositif étant configuré pour transmettre sans fil des données à un second dispositif, de préférence en faisant appel à la technologie de communication à réseau personnel sans fil (WPAN), ledit procédé comprenant : la détermination d'un nombre aléatoire, la détermination d'une valeur de hachage en fonction dudit nombre aléatoire et de premières données, la transmission de ladite valeur de hachage et dudit nombre aléatoire audit second dispositif.
PCT/EP2019/073607 2019-09-04 2019-09-04 Dispositif et procédé pour faire fonctionner un dispositif WO2021043396A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/EP2019/073607 WO2021043396A1 (fr) 2019-09-04 2019-09-04 Dispositif et procédé pour faire fonctionner un dispositif

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/EP2019/073607 WO2021043396A1 (fr) 2019-09-04 2019-09-04 Dispositif et procédé pour faire fonctionner un dispositif

Publications (1)

Publication Number Publication Date
WO2021043396A1 true WO2021043396A1 (fr) 2021-03-11

Family

ID=67874451

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2019/073607 WO2021043396A1 (fr) 2019-09-04 2019-09-04 Dispositif et procédé pour faire fonctionner un dispositif

Country Status (1)

Country Link
WO (1) WO2021043396A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US12047385B2 (en) 2022-05-09 2024-07-23 T-Mobile Usa, Inc. Interoperable unlocking technology for wireless devices

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140169564A1 (en) * 2012-12-14 2014-06-19 GM Global Technology Operations LLC Method and system for secure and authorized communication between a vehicle and wireless communication devices or key fobs
US20180198752A1 (en) * 2015-07-02 2018-07-12 Telefonaktiebolaget Lm Ericsson (Publ) Bluetooth low energy address resolving

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140169564A1 (en) * 2012-12-14 2014-06-19 GM Global Technology Operations LLC Method and system for secure and authorized communication between a vehicle and wireless communication devices or key fobs
US20180198752A1 (en) * 2015-07-02 2018-07-12 Telefonaktiebolaget Lm Ericsson (Publ) Bluetooth low energy address resolving

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US12047385B2 (en) 2022-05-09 2024-07-23 T-Mobile Usa, Inc. Interoperable unlocking technology for wireless devices

Similar Documents

Publication Publication Date Title
US20220408261A1 (en) Wireless access credential system
US20240106630A1 (en) Id-based control unit-key fob pairing
US11259178B2 (en) Bluetooth mesh network provisioning authentication
US9330514B2 (en) Systems and methods for locking device management
JP6769686B2 (ja) 一方向のキーフォブ及び車両ペアリング認証、保持、及び無効化
US10654447B2 (en) Vehicle sharing accessory module and system
US10841304B2 (en) Device-to-device communication method including device-to-device authentication using hash chain
JP5114420B2 (ja) ネットワーク環境との通信を確立する方法、記憶媒体、及び、システム
US8385824B2 (en) Procedure for headset and device authentication
US20070287418A1 (en) Establishing Data Communications
KR101582502B1 (ko) 인증을 위한 시스템 및 방법
GB2452251A (en) Authentication in Wireless Personal Area Networks
JP7410771B2 (ja) 認証システム及び認証方法
US20100023768A1 (en) Method and system for security key agreement
WO2024007993A1 (fr) Procédé de mise à jour du logiciel, dispositif et moyen de stockage
WO2021043396A1 (fr) Dispositif et procédé pour faire fonctionner un dispositif
WO2021043398A1 (fr) Amélioration de la confidentialité dans des réseaux personnels sans fil à l'aide de valeurs d'identifiant universellement unique personnalisées
WO2021159506A1 (fr) Procédé et appareil de reconnaissance automatique d'identité, et puce
EP1677189A2 (fr) Architecture extensible pour la configuration d'un dispositif par un médium de confiance
FI126936B (en) Method and technical apparatus for short - distance communication
CN114802101A (zh) 车辆解闭锁控制方法、装置、移动终端和存储介质
JP2023527408A (ja) 検証方法および装置
US20240317179A1 (en) Terminal device and method processing of data for terminal device
TW202027479A (zh) 車載聯網電子系統的控制方法
JP2004032072A (ja) セキュリティシステムにおけるセキュリティコード更新方式

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 19765233

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 19765233

Country of ref document: EP

Kind code of ref document: A1