WO2018093683A1 - Systèmes et procédés de détection de clonage de balise sans fil - Google Patents

Systèmes et procédés de détection de clonage de balise sans fil Download PDF

Info

Publication number
WO2018093683A1
WO2018093683A1 PCT/US2017/061163 US2017061163W WO2018093683A1 WO 2018093683 A1 WO2018093683 A1 WO 2018093683A1 US 2017061163 W US2017061163 W US 2017061163W WO 2018093683 A1 WO2018093683 A1 WO 2018093683A1
Authority
WO
WIPO (PCT)
Prior art keywords
eik
candidate
beacon
eid
eiks
Prior art date
Application number
PCT/US2017/061163
Other languages
English (en)
Inventor
Ari Juels
Original Assignee
Pcms Holdings, Inc.
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 Pcms Holdings, Inc. filed Critical Pcms Holdings, Inc.
Publication of WO2018093683A1 publication Critical patent/WO2018093683A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0407—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the identity of one or more communicating identities is hidden
    • H04L63/0414—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the identity of one or more communicating identities is hidden during transmission, i.e. party's identity is protected against eavesdropping, e.g. by using temporary identifiers, but is known to the other party or parties involved in the communication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H04L63/123—Applying verification of the received information received data contents, e.g. message integrity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/12—Detection or prevention of fraud
    • H04W12/121—Wireless intrusion detection systems [WIDS]; Wireless intrusion prevention systems [WIPS]
    • H04W12/122—Counter-measures against attacks; Protection against rogue devices
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/80—Services using short range communication, e.g. near-field communication [NFC], radio-frequency identification [RFID] or low energy communication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2463/00—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00
    • H04L2463/121—Timestamp
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W84/00—Network topologies
    • H04W84/02—Hierarchically pre-organised networks, e.g. paging networks, cellular networks, WLAN [Wireless Local Area Network] or WLL [Wireless Local Loop]
    • H04W84/10—Small scale networks; Flat hierarchical networks
    • H04W84/12—WLAN [Wireless Local Area Networks]

Definitions

  • This disclosure relates to systems and methods for wireless beacons. More specifically, this disclosure relates to systems and methods for detection and/or prevention of cloning of wireless beacons.
  • Bluetooth Low-Energy (BLE) beacons are small radio devices that emit static identifiers. They are expected to be one of the foundational devices in the Internet of Things (loT), particularly as BLE has already found its way into a number of major industries, including automotive, medical, etc.
  • beacons are one-way transmitters that may be used in various fashions, such as to mark places or objects, or the like.
  • a beacon may only be visible to a user device within a short range, such as a few meters.
  • Eddystone is an open beacon format which can be detected by both Android and iOS devices.
  • Different types of payload can be included in the frame format, including: Eddystone-UID, a unique, static ID with a 10-byte Namespace component and a 6-byte Instance component; Eddystone-URL, a compressed URL that, once parsed and decompressed, is directly usable by the client; Eddystone-TLM, beacon status data that is useful for beacon fleet maintenance, and powers Google Proximity Beacon API's diagnostics endpoint - Eddystone-TLM should be interleaved with an identifying frame such as Eddystone- UID or Eddystone-EID (for which the encrypted eTLM version preserves security); and Eddystone-EID, a time-varying beacon frame that can be resolved to a stable identifier by a linked resolver, such as Proximity Beacon API.
  • EID Ephemeral ID
  • Google has introduced an Eddystone identifier format variant called an Ephemeral ID (EID).
  • EID transmission is already supported by various vendors and used in a variety of applications (e.g., offering location-based discounts, tracking physical objects, etc.).
  • An EID is a time- varying value computed using a cryptographic key, and thus resists the straightforward copying to which UIDs are vulnerable.
  • Eddystone-EID beacons may broadcast an identifier, which may change every few minutes (or some other time period). This identifier can be resolved to useful information, such as by a service that shares an Ephemeral Identity Key (EIK) with the given individual beacon.
  • EIK Ephemeral Identity Key
  • Uses of Eddystone-EID require both a beacon and a resolving service (e.g., the Google Proximity Beacon API).
  • the Google Proximity Beacon API will only return attachment data associated with the beacon if the request contains the API key of an authorized project.
  • Eddystone-EID shared keys between individual beacons and a beacon registry may be exchanged at the time beacons are provisioned using an elliptic curve Diffie-Hellman key agreement protocol.
  • registration of an Eddystone-EID beacon may occur through two channels: by exchanging public keys with the beacon, in a fully secure end-to-end fashion; and by accepting the shared EIK directly, which is less secure but permits a single beacon to be registered multiple times with different services.
  • the resolution service also synchronizes a clock to later resolve the EID broadcasts.
  • the current EID may be sent to a resolver, along with the API key of the calling app.
  • the resolver establishes whether the supplied API key is authorized to fetch attachments that have been associated with the beacon. If resolution is allowed, the attachments may be served back. Otherwise, the resolver may return an empty value, as it would if the beacon had not been registered.
  • Beacons transmitting EIDs remain vulnerable to cloning by an adversary that gains physical access to them.
  • an adversary can create clone beacons that are perfectly indistinguishable from the originals.
  • Numerous such attacks are documented against cryptographically enabled devices, particularly low-cost ones such as RFID tags and smartcards (see, e.g., R. Anderson and M. Kuhn, 'Tamper resistance— a cautionary note", in USENIX Security, pages 1-11, 1996; and Y. Oren and A. Shamir, "Remote password extraction from RFID tags", IEEE Transactions on Computers, 56(9): 1292- 1296, 2007).
  • Many BLE beacons are programmable, and thus highly vulnerable both to key extraction and modification.
  • Described herein are systems and methods related to detection and/or prevention of cloning of wireless beacons.
  • a method comprises, for each of a plurality of beacon devices, maintaining an associated candidate set of at least one candidate ephemeral ID key (EIK). The method also includes periodically updating each of the candidate sets by replacing at least one EIK in a candidate set (and, in some embodiments, all EIKs in a candidate set) with at least two new EIKs derived therefrom.
  • EIK ephemeral ID key
  • the method also includes, in response to a resolution request containing an ephemeral ID (EID): identifying, from the candidate EIKs, a selected EIK that is consistent with the EID; responding to the resolution request by identifying the beacon device associated with the selected EIK; and updating the set of candidate EIKs associated with the identified beacon device to include only the selected EIK.
  • EID ephemeral ID
  • a method comprises receiving, at a cloning detection server (CDS) from a resolver server, a first resolution message indicative of a successful resolution of a first ephemeral ID (EID), wherein the first resolution message comprises at least a first ephemeral ID key (EIK) associated with a first registered beacon resolved from the first EID.
  • the method also includes updating, at the CDS, a set of candidate EIKs associated with the first registered beacon, such that the first EIK is indicated as detected.
  • a method comprises receiving, at a cloning detection server (CDS) from a resolver server, a first resolution message indicative of a successful resolution of a first ephemeral ID (EID), wherein the first resolution message comprises at least a first ephemeral ID key (EIK) associated with a first registered beacon determined from the first EID.
  • the method also includes updating, at the CDS, a set of candidate EIKs associated with the first registered beacon, such that the first EIK is indicated as having been detected.
  • the method also includes communicating, from the CDS to the resolver server, a replacement set of candidate EIKs, based at least in part on the first EIK, to be registered with the resolver server.
  • a method comprises receiving, at a cloning detection server (CDS) from a resolver server, a first resolution message comprising at least a first candidate ephemeral ID key (EIK) associated with a first registered beacon resolved from a first ephemeral ID (EID) query received at the resolver server.
  • the method also includes receiving, at the CDS from the resolver server, a second resolution message comprising at least a second candidate EIK associated with the first registered beacon determined from a second EID query received at the resolver server.
  • the method also includes comparing the key state evolutions of the first candidate EIK and the second candidate EIK.
  • the method also includes communicating, responsive to a determination that the key state evolutions of the first candidate EIK and the second candidate EIK are divergent, a cloning detection notification to an owner associated with the first registered beacon.
  • a method comprises maintaining, for each of a plurality of beacon devices, an associated candidate set of at least one candidate ephemeral ID key (EIK). The method also includes periodically updating each of the candidate sets by replacing at least one EIK in a candidate set (and in some embodiments, all EIKs in the candidate set) with at least two new EIKs derived therefrom.
  • EIK ephemeral ID key
  • the method also includes in response to a resolution request containing an ephemeral ID (EID): identifying, from the candidate EIKs, a selected EIK that is consistent with the EID; responding to the resolution request by returning content stored in association with the beacon device associated with the selected EIK; and storing in association with the identified beacon device an indicator of a detection event of the selected EIK.
  • EID ephemeral ID
  • systems comprising a processor and a non-transitory storage medium storing instructions operative, when executed on the processor, to perform functions including those set forth in relation to the methods described above.
  • FIG. 1 illustrates one embodiment of data flow in exemplary disclosed cloning detection methods and systems.
  • FIG. 2 illustrates one embodiment of the evolution of the candidate set C when there is no emission sighting for a beacon B over a period of three epochs.
  • FIG. 3 depicts an example of one embodiment of a method of cloning detection.
  • FIG. 4 is a functional block diagram of an exemplary beacon device used in some embodiments.
  • FIG. 5 is a functional block diagram of an exemplary receiver device and an exemplary resolver system.
  • FIG. 6 is a table illustrating content of an exemplary resolver database.
  • FIG. 7 illustrates an exemplary wireless transmit/receive unit (WTRU) that may be employed as a CDS, receiver, or resolver in some embodiments.
  • WTRU wireless transmit/receive unit
  • FIG. 8 illustrates an exemplary network entity that may be employed in some embodiments.
  • modules that carry out (i.e., perform, execute, and the like) various functions that are described herein in connection with the respective modules.
  • a module includes hardware (e.g., one or more processors, one or more microprocessors, one or more microcontrollers, one or more microchips, one or more application-specific integrated circuits (ASICs), one or more field programmable gate arrays (FPGAs), one or more memory devices) deemed suitable by those of skill in the relevant art for a given implementation.
  • ASICs application-specific integrated circuits
  • FPGAs field programmable gate arrays
  • Each described module may also include instructions executable for carrying out the one or more functions described as being carried out by the respective module, and it is noted that those instructions could take the form of or include hardware (i.e., hardwired) instructions, firmware instructions, software instructions, and/or the like, and may be stored in any suitable non-transitory computer-readable medium or media, such as commonly referred to as RAM, ROM, etc.
  • a Drifting Keys scheme assumes that a device can transmit data to a receiver, which basic Eddystone-EID beacons do not do.
  • the scheme in Itkis presumes the ability to transmit certificate chains, which generally exceeds the bandwidth available to a beacon.
  • the systems and methods disclosed herein may avoid the impractical resource requirements of Itkis and Zanetti et al. in the beacon setting. Such systems and methods may achieve significantly higher robustness and security than Drifting Keys and in some cases operate using only a single beacon emission.
  • Components of the system may include a beacon B, a receiver, a resolver, and a cloning detection service.
  • a beacon B (100) emits a time-varying value known as an EID (103).
  • a beacon stores an £-b ⁇ t cryptographic key known as an ephemeral ID key, or EIK.
  • An EID is computed at a given time t as an AES encryption of the time t under the El K.
  • the beacon may have an internal clock, and a value representing a current time as measured by the clock (to a
  • predetermined level of precision may be AES-encrypted using the EIK as the encryption key.
  • a Receiver 105 (e.g., a digital device, smartphone, etc.) that obtains the EID (103) may send it (107)to an online service known as a Resolver 110.
  • the resolver stores all EIKs for individual beacons (as well as data needed to synchronize time with individual beacons) and thus can map a received EID to its corresponding EIK.
  • the resolver 110 Upon successful resolution, the resolver 110 returns to the Receiver 105 a value (e.g., beacon B data 112), such as a stable identifier, stored for the EIK by the beacon owner.
  • a value e.g., beacon B data 112
  • Such stored values may include, but are not limited to, URLs, previously stored content, etc.
  • a cloning-detection service (CDS) 120 may register and manage beacons in the disclosed systems and methods. It may use the administrative features provided by the Resolver 110 (e.g., the Google Beacon Dashboard) to detect suspected beacon cloning.
  • the CDS 120 may comprise a server, an application running on a digital device, and/or the like.
  • the CDS may be a component of a resolver 110, or an application running at the resolver 110.
  • the CDS may be a standalone component from the resolver.
  • the CDS may receive resolution tracking information 117 from the resolver 110, and may provide candidate EIKs 122 to the resolver 110 for resolving received EIDs 103.
  • T denote time measured in epochs.
  • a beacon refreshes its state.
  • An epoch may, for example, be a day (or alternatively an hour, multiple hours, less than an hour, multiple days, and/or the like).
  • ⁇ ] denote the El K of a beacon B during epoch T.
  • the beacon B generates a random value r[T] 1 n .
  • a hash function H ⁇ 0,1 ⁇ * ⁇ ⁇ 0,l ⁇
  • a hash function H may be used.
  • the hash function H may be a cryptographic hash function such as MD5, SHA-0 or SHA-1 , SHA-2, SHA-3, BLAKE, or BLAKE2, among others.
  • the random function r has a range of ⁇ 0,1 ⁇ and thus randomly outputs a single bit.
  • one or more other cryptographic transformations may be used in place of a hash function to generate EIKs, such as use of a pseudorandom function with a shared key or the like as known to one of ordinary skill in the relevant art.
  • Emission sighting An emission during epoch T is said to be sighted when a beacon emits a onetime value based on its current key EIK[T] and a receiving device receives this one-time value and queries the Resolver using this emission.
  • the EID may be generated by the beacon based on an AES encryption of a representation of the current time in seconds, based on the current key.
  • the CDS may observe this query and can verify whether it corresponds to EIK[T].
  • the Resolver may pre-generate mapping tables (or the like) for each registered El K for upcoming times. Upon receipt of a query with a particular EID, the Resolver may compare the received EID to said mapping tables to determine the associated EIK.
  • the CDS may maintain a set CfT] of candidate keys for every beacon B it manages.
  • Each original EIK in the set C[T] may be replaced with at least two EIKs derived from the respective original EIK.
  • Derived EIKs may be generated from an original EIK by, for example, combining the original EIK with a value in the
  • the set ⁇ EIKo ⁇ may be updated to:
  • this set may in turn be updated to:
  • the beacon may be automatically deregistered so that the set C T] of candidate keys is no longer maintained and does not continue to grow exponentially.
  • the threshold used for automatic deregistration is based on, for example, a period of time or number of epochs since the last sighting instead of a number of candidate keys.
  • not all EIKs in a candidate set are necessarily replaced at the beginning of an epoch with at least two derived EIKs.
  • rules e.g., deterministic rules
  • 0) is replaced only with H(H(EIK
  • the rule is applied only at, for example, even-numbered (or odd-numbered) epochs.
  • Various other such rules may be applied, for instance only EIKs with odd parity may be replaced in odd epochs, and/or only EIKs with even parity may be replaced in even epochs, and/or the like.
  • the replacement may be a replacement with different rule-determined numbers of candidate EIKs (such that an EIK may be replaced with one, two, three, etc. derived EIKs), or EIKs that satisfy particular conditions may remain unchanged across two or more epochs.
  • the foregoing are simply examples of the types of rules that can be implemented and are not intended to be an exhaustive list. Such rules and conditions are implemented at both the beacon and resolver such that the set of candidate keys corresponds to possible outcomes of key evolution of a legitimate registered beacon device.
  • the CDS may register all candidate keys C[T'] with the Resolver at the beginning of an epoch T'. In some embodiments, the CDS may then unregister the set of keys C T'-1], as these are no longer in use by B.
  • FIG. 2 illustrates one embodiment of the evolution of the candidate set C when there is no emission sighting for a beacon B over a period of three epochs.
  • a device may be cloned where an adversary steals an EIK from an authentic beacon B via a side-channel attack and creates a second device B' at time T with key EIKTT].
  • the state of the two devices will quickly diverge with high probability, such that EIK'fT+k] ⁇ EIK[T+k].
  • the CDS will set C to the EIK of that beacon, rendering the other beacon invalid. If B has been sighted, then the clone B' will be rendered invalid and the clone will in effect be deactivated. Otherwise, B will be deactivated. In both cases, only one beacon remains valid, and thus the cloning attempt fails.
  • FIG. 3 illustrates one embodiment of the disclosed methods.
  • a system e.g., a CDS and/or resolver
  • the system may periodically update each of the candidate sets (e.g., at the start of each epoch) by replacing each EIK in a candidate set with at least two new EIKs derived from the original EIK (310).
  • the system may identify, from the candidate EIKs, a selected EIK that is consistent with the EID (315).
  • the system may respond to the resolution request by identifying the beacon device associated with the selected EIK (320).
  • the response to the resolution request may include returning content that was previously stored in association with the identified beacon device.
  • the system may update the set of candidate EIKs associated with the identified beacon device to include only the selected EIK (325).
  • each EIK derived from an original (or immediately preceding candidate) EIK is generated by applying a hash function or other cryptographic transformation to a combination of (i) the original (or immediately preceding candidate) EIK and (ii) a value in the predetermined range of a random function.
  • the random function may have a predetermined range of ⁇ 0,1 ⁇ and thus outputs a single, randomly-selected bit value.
  • one of the derived EIKs may be generated by combining the value 0 with the original EIK and hashing the result, and another one of the derived EIKs may be generated by combining the value 1 with the original EIK and hashing the result.
  • an updated set of candidate EIKs includes new candidate EIKs for each possible combination of a prior candidate EIK and the values in the predetermined range of the random function.
  • each candidate set is updated at the beginning of each new epoch.
  • identifying a selected EIK that is consistent comprises identifying an EIK that, when used to encrypt a current time value, gives the EID.
  • mapping tables for various time intervals may be pre-generated based on the candidate EIKs, such that EID emission sightings may be mapped to candidate EIKs.
  • the method may further comprise, in response to a failure to identify any EIK that is consistent with the EID, reporting a failed resolution attempt (e.g., to the receiver).
  • the only candidate keys that are stored for a particular beacon are those keys that are valid in the current epoch.
  • Such embodiments can help to prevent cloning because (1) a cloned device may not have a valid current key and thus may fail to deceive a beacon reader, or (2) if a cloned device does manage to use a valid current key, attempts to resolve the authentic device are likely to fail, and the owner of the authentic device can report the issue, likely resulting in de-registration of the keys being used by the clone.
  • Detection of cloning in such embodiments may be described as implicit, as the existence of a clone may be inferred by detection of more general service problems (e.g., failure to resolve the EID of a beacon that is known to be valid).
  • a CDS may operate to maintain a larger set of key states.
  • the CDS may store, for each beacon, keys that were previously valid candidate keys (but that are no longer valid) and/or keys derived from previously-valid candidate keys. In this way, if the CDS detects use of a key that is no longer valid (or that is derived from a key that is no longer valid), the CDS is able not only to recognize that cloning has taken place but also to identify the beacon that is the subject of the cloning attempt.
  • the identified beacon may be automatically disabled at the resolver, and the beacon owner may be required to re- provision the beacon (e.g., thereby disabling the clone).
  • the disclosed systems and methods may be employed in various use cases.
  • a pallet in a supply chain for high-value goods such as medical devices, or parts for mobile devices or automobiles.
  • Inexpensive RF devices such as RFID tags
  • RFID tags are playing an increasingly instrumental role in anti-counterfeiting (see Staake et al., "Extending the EPC network: the potential of RFID in anti-counterfeiting", ACM Symposium on Applied Computing, 2005) through pallet- and item-level tagging.
  • the receiver of a tagged unit of goods can use the unique identifier in the RFID tag to look up the pallet and ensure that its source is authentic.
  • a recognized risk of such tagging approaches is that the tagging devices themselves, along with their unique identifiers, can be cloned.
  • a counterfeiter might clone an authentic beacon B to tag a pallet of counterfeit goods with a clone beacon B'.
  • the receiver of the pallet queries the Resolver using the clone beacon B', the pallet and its goods will appear to be authentic.
  • beacons that are used to mark transit stops, help people navigate buildings, or track medical devices are cloned, various safety hazards may result.
  • a BLE beacon may communicate telemetry data using the EIK of the beacon.
  • an authentic beacon A were cloned by a third party to cloned beacon A', the third party could use A' to transmit false telemetry data.
  • the transmission of such false telemetry data may be prevented and/or detected.
  • an EID emission by A is communicated to a resolver and/or a CDS.
  • the emission is resolved and the encrypted telemetry data (e.g., Eddystone-eTLM frame content encrypted using the current EIK state of the beacon) processed as established at the resolver in association with the candidate EIKs.
  • the CDS may then be notified (or otherwise be aware) of the successful resolution to the particular candidate EIK, call it EIKA.
  • This particular candidate EIK may be noted by the CDS, and the set of candidate EIKs registered at the resolver updated to include only the particular candidate EIK, EIKA (at least for the current epoch).
  • EIKA at least for the current epoch.
  • an EID emission from A' is communicated, based on an EIKA', which has diverged from EIKA over the intervening epochs since cloning. Because the alternative candidate EIKs were deregistered after the sighting of A, the emission from A' is not resolved. Thus, only A remains valid and the cloning attempt fails.
  • an EID emission by A' is communicated to the resolver first.
  • the set of registered candidate EIKs at the resolver is updated to include only EIKA' (and perhaps the false telemetry data decrypted and utilized by the owner of A), and a subsequent sighting of A will result in failure.
  • the owner of A can become aware of the service failure of A after the sighting of A, the cloning of A may be detected (e.g., determined from the service failure of A), and A reprovisioned, thereby eliminating the cloning of A.
  • the then-current El K of A may be utilized by the CDS to identify the epoch in which A was cloned.
  • the candidate keys may not be deregistered from the resolver, but sightings may be noted by the CDS, and mismatches in the key state evolutions of the EIKs may be used to detect cloning.
  • forensic detection performed by the CDS may determine that A was, at the latest, cloned in epoch T+1 (i.e., the epoch before divergence). In some instances, such information could be utilized by the owner of A to attempt to determine the third party who cloned A, or the like.
  • FIG. 4 A block diagram of a beacon according to an exemplary embodiment is provided in FIG. 4.
  • the beacon of FIG. 4 includes re-writable key storage 405 for storing a current EIK.
  • the beacon also includes an internal clock 410.
  • a state evolution module 415 of the beacon operates to generate a new key state for use through the remainder of the epoch.
  • the beacon is provided with a software or hardware random number generator 420 which randomly selects an output value from among a predetermined range of values.
  • the predetermined range of values may be ⁇ 0,1 ⁇ .
  • the module is further provided with a software or hardware hash function module 425, which applies a hash function to a combination (such as a concatenation) of the current stored key and the random value, and the outcome is stored as the new EIK.
  • the beacon operates to transmit frames using the Eddystone format.
  • the beacon is provided with a software or hardware encryption module 430, which may be an AES encryption module.
  • the encryption module 430 operates to encrypt a current time value read from the clock (to a
  • the beacon is further equipped with an RF transmitter 435 for transmitting frames that include the EID.
  • FIG. 5 Block diagrams of an exemplary receiver device and resolver are provided in FIG. 5.
  • the receiver device 500 may be, for example, a smartphone, tablet computer, or other wireless transmit-receive unit (WTRU) as described in greater detail with respect to FIG. 7.
  • WTRU wireless transmit-receive unit
  • a beacon frame containing an EID is received at an RF receiver 505 of the receiver device.
  • the EID is passed to a network interface 510 of the receive device, which conveys the El D to a resolver server.
  • the resolver server 520 may be implemented as a network entity as described in greater detail with respect to FIG. 8.
  • the resolver 520 is provided with a network interface 525 for receiving the EID.
  • the resolver is also equipped with a resolver database 530 that stores, for each registered beacon, a corresponding set of candidate ephemeral ID keys (EIKs) 532.
  • the resolver database 530 may also store beacon-specific content 534 associated with each respective beacon.
  • the resolver operates to identify the beacon associated with the EID.
  • the resolver is equipped with an encryption module 535 that operates using the same predetermined encryption function (e.g., AES) implemented by the beacon.
  • the encryption module receives a clock value from a clock module 540 of the resolver and encrypts the clock value using various candidate keys stored in the resolver database to generate candidate EIDs.
  • a selection module 545 of the resolver compares these candidate EIDs to the received EID. If the candidate EID matches the received EID, then the selection module retrieves the corresponding beacon-specific content from the resolver database and provides that content to the network interface for transmission to the receiver device.
  • the receiver device may be equipped with, for example, a display for displaying the beacon-specific content to a user.
  • the receiver device may alternatively (or in addition) operate to store and/or further process the beacon-specific content. For example, where the beacon-specific content includes a URL, the receiver device may retrieve content at that URL using the network interface.
  • the resolver is provided with a key set update module 550.
  • the functions of a key set update module are performed by a separate clone detection system server.
  • the key set update module updates the set of candidate keys associated with each registered beacon.
  • the key set update module updates the set of candidate keys by replacing each key original key in the set with at least two new keys derived from the original key.
  • the new keys may be derived as follows: for each value in the predetermined range of the random function used by the beacons, that value is hashed together with the original key to generate a respective one of the derived keys.
  • Hashing the original key with the value may be performed by concatenating the original key and the value and subsequently applying a cryptographic hash function to the concatenated result.
  • each registered beacon is associated with a stable identifier, a set of one or more candidate keys (EIKs), and beacon-specific content (which may be configured by the beacon owner).
  • EIKs candidate keys
  • beacon-specific content which may be configured by the beacon owner.
  • the resolver operates to identify which candidate EIK, when used to encrypt the current time value, gives a value equal to the received EID.
  • the corresponding beacon-specific content may be sent to the receiver device.
  • the beacon-specific content may have various forms, such as a URL, information identifying a geographic location, or a tracking number of a particular shipment, among other possibilities.
  • a stable identifier of the beacon may be sent in response to a resolution request that includes an EID.
  • the database stores candidate EIK values.
  • the database stores (alternatively or additionally) a set of candidate EID values for each of the registered beacons. These candidate EID values may be updated with each "tick" of the clock.
  • the selection module may operate using conventional database search techniques (e.g., using a SQL query) to identify a received EID within the resolver database.
  • the database instead of storing the candidate EIK values, stores one or more values from which the candidate EIK values were derived. As an example, with reference to FIG. 2, a database may store EIK[t], from which all eight EIKs in C[t+3] may be derived on an as-needed basis.
  • the methods set forth herein may be generally carried out by utilizing the -eTLM frames of the Eddystone format.
  • a given beacon may have a stable EIK and a varying EIK (e.g., the hash of the previous EIK and a random function result), and use the stable EIK for generating an emission EID, where a comparable value based on the varying EIK may be carried as an encrypted portion of an -eTLM frame.
  • the resolver may itself or in communication with a CDS retrieve a set of candidate EIKs (for example, associated with this particular beacon device, as known from resolution of the EID), and separate from resolution of the EID the evolution of the varying EIK may be verified.
  • a set of candidate EIKs for example, associated with this particular beacon device, as known from resolution of the EID
  • there is a method comprising: for each of a plurality of beacon devices, maintaining an associated candidate set of at least one candidate ephemeral ID key (EIK).
  • the method also includes periodically updating each of the candidate sets by replacing at least one EIK in a candidate set with at least two EIKs derived therefrom.
  • the method also includes, in response to a resolution request containing an ephemeral ID (EID): identifying, from the candidate EIKs, a selected EIK that is consistent with the EID; responding to the resolution request by providing beacon-specific content for the beacon device associated with the selected EIK; and updating the set of candidate EIKs associated with the identified beacon device to include only the selected EIK.
  • EID ephemeral ID
  • the method may include wherein each EIK derived from an original EIK is generated by applying a hash function or other cryptographic transformation to a combination of (i) the original EIK and (ii) a value in the predetermined range of a random function.
  • identifying a selected EIK that is consistent comprises identifying an EIK that, when used to encrypt a current time value, gives the EID.
  • the method may further comprise, in response to a failure to identify any EIK that is consistent with the EID, reporting a failed resolution attempt.
  • the method may include wherein each candidate set is updated at the beginning of each of a series of epochs.
  • a method comprising: receiving, at a cloning detection server (CDS) from a resolver server, a first resolution message indicative of a successful resolution of a first ephemeral ID (EID), wherein the first resolution message comprises at least a first ephemeral ID key (EIK) associated with a first registered beacon, the first EIK resolved from the first EID.
  • the method also includes updating, at the CDS, a set of candidate EIKs associated with the first registered beacon, such that the first EIK is indicated as detected.
  • the method may further comprise, at the start of a next epoch as determined by the CDS, communicating a replacement set of candidate EIKs from the CDS to the resolver server, wherein each replacement candidate EIK in the replacement set of candidate EIKs is generated by applying a hash function or other cryptographic transformation to a combination of (i) a prior candidate EIK for the first registered beacon and (ii) a value in the predetermined range of a random function.
  • the method may further comprise: receiving, at the CDS, from an authenticated owner of the first registered beacon, a failed resolution message indicative of a failed resolution attempt of the first registered beacon; and
  • the method may further comprise: updating, at the CDS, the set of candidate El Ks associated with the first registered beacon such that the set is a null set; and communicating, from the CDS to the resolver server, a deregistration of the set of candidate EIKs.
  • the method may further comprise: receiving at the CDS from the authenticated owner a verified EIK of the first registered beacon; comparing a key state evolution of the verified EIK and the first EIK; and determining, based at least in part on the compared key state evolutions, an epoch in which the first registered beacon was cloned.
  • the method may include wherein each candidate EIK for the first registered beacon is generated by applying a hash function or other cryptographic transformation to a combination of (i) an original EIK for the first registered beacon and (ii) a value in the predetermined range of a random function.
  • a method comprising: receiving, at a cloning detection server (CDS) from a resolver server, a first resolution message indicative of a successful resolution of a first ephemeral ID (EID), wherein the first resolution message comprises at least a first ephemeral ID key (EIK) associated with a first registered beacon determined from the first EID; updating, at the CDS, a set of candidate EIKs associated with the first registered beacon, such that the first EIK is indicated as having been detected; and communicating, from the CDS to the resolver server, a replacement set of candidate EIKs, based at least in part on the first EIK, to be registered with the resolver server.
  • CDS cloning detection server
  • EIK ephemeral ID key
  • the method may include wherein each candidate EIK in the set of candidate EIKs for the first registered beacon is generated by applying a hash function or other cryptographic transformation to a combination of (i) an original EIK for the first registered beacon and (ii) a value in the predetermined range of a random function.
  • the method may further comprise, at the start of a next epoch as determined by the CDS, communicating a replacement set of candidate EIKs from the CDS to the resolver server, wherein each replacement candidate EIK in the replacement set of candidate EIKs is generated by applying a hash function or other cryptographic transformation to a combination of (i) a prior candidate EIK for the first registered beacon and (ii) a value in the predetermined range of a random function.
  • the method may further comprise: receiving, at the CDS, a failed resolution message indicative of a failed resolution attempt of the first registered beacon from an authenticated owner of the first registered beacon; and communicating, responsive to a determination that the first registered beacon was previously indicated as detected, a cloning detection message to the authenticated owner.
  • the method may further comprise: updating, at the CDS, the set of candidate EIKs associated with the first registered beacon such that the set is a null set; and communicating, from the CDS to the resolver server, a deregistration of the set of candidate EIKs.
  • the method may further comprise: receiving at the CDS from the authenticated owner a verified EIK of the first registered beacon; comparing a key state evolution of the verified EIK and the first EIK; and determining, based at least in part on the compared key state evolutions, an epoch in which the first registered beacon was cloned.
  • a method comprising: receiving, at a cloning detection server (CDS) from a resolver server, a first resolution message comprising at least a first candidate ephemeral ID key (EIK) associated with a first registered beacon resolved from a first ephemeral ID (EID) query received at the resolver server; receiving, at the CDS from the resolver server, a second resolution message comprising at least a second candidate EIK associated with the first registered beacon determined from a second EID query received at the resolver server; comparing the key state evolutions of the first candidate EIK and the second candidate EIK; and communicating, responsive to a determination that the key state evolutions of the first candidate EIK and the second candidate EIK are divergent, a cloning detection notification to an owner associated with the first registered beacon.
  • CDS cloning detection server
  • the method may include wherein a set of candidate EIKs associated with the first registered beacon was previously registered with the resolver server.
  • the method may include wherein each EIK in the set of candidate EIKs comprises a hash or other cryptographic transformation of a previous epoch state EIK and a value in the predetermined range of a random function.
  • the method may further comprise, at the start of each sequential epoch, updating the set of candidate El Ks registered at the resolver sever, such that for at least one candidate EIK a plurality of subsequent epoch candidate EIKs are added to the set.
  • the method may include wherein each candidate EIK for the first registered beacon is generated by applying a hash function or other cryptographic transformation to a combination of (i) an original EIK for the first registered beacon and (ii) a value in the predetermined range of a random function.
  • there is a method comprising: maintaining, for each of a plurality of beacon devices, an associated candidate set of at least one candidate ephemeral ID key (EIK); periodically updating each of the candidate sets by replacing at least one EIK in a candidate set with at least two EIKs derived therefrom; and in response to a resolution request containing an ephemeral ID (EID): identifying, from the candidate EIKs, a selected EIK that is consistent with the EID; responding to the resolution request by returning content stored in association with the beacon device associated with the selected EIK; and storing in association with the identified beacon device an indicator of a detection event of the selected EIK.
  • EIK ephemeral ID key
  • the method may include wherein each EIK derived from an original EIK is generated by applying a hash function or other cryptographic transformation to a combination of (i) the original EIK and (ii) a value in the predetermined range of a random function.
  • identifying a selected EIK that is consistent comprises identifying an EIK that, when used to encrypt a current time value, gives the EID.
  • the method may further comprise, in response to a failure to identify any EIK that is consistent with the EID, reporting a failed resolution attempt.
  • the method may include wherein each candidate set is updated at the beginning of each of a series of epochs.
  • the method may further comprise in response to a second resolution request containing a second ephemeral ID (EID): identifying, from the candidate EIKs, a second selected EIK that is consistent with the second EID; determining for the beacon device associated with the second selected EIK that the second selected EIK is not derived from the previously selected EIK; and communicating a cloning detection message to an authenticated owner associated with the beacon device associated with the selected and second selected EIKs.
  • EID ephemeral ID
  • a system comprising a processor and a non-transitory storage medium storing instructions operative, when executed on the processor, to perform functions including: for each of a plurality of beacon devices, maintaining an associated candidate set of at least one candidate ephemeral ID key (EIK); periodically updating each of the candidate sets by replacing at least one EIK in a candidate set with at least two EIKs derived therefrom; and in response to a resolution request containing an ephemeral ID (EID): identifying, from the candidate EIKs, a selected EIK that is consistent with the EID; responding to the resolution request by identifying the beacon device associated with the selected EIK; and updating the set of candidate EIKs associated with the identified beacon device to include only the selected EIK.
  • EIK ephemeral ID key
  • a system comprising a processor and a non-transitory storage medium storing instructions operative, when executed on the processor, to perform functions including: receiving, at a cloning detection server (CDS) from a resolver server, a first resolution message indicative of a successful resolution of a first ephemeral ID (EID), wherein the first resolution message comprises at least a first ephemeral ID key (EIK) associated with a first registered beacon resolved from the first EID; and updating, at the CDS, a set of candidate EIKs associated with the first registered beacon, such that the first EIK is indicated as detected.
  • CDS cloning detection server
  • EID ephemeral ID
  • EIK ephemeral ID key
  • a system comprising a processor and a non-transitory storage medium storing instructions operative, when executed on the processor, to perform functions including: receiving, at a cloning detection server (CDS) from a resolver server, a first resolution message indicative of a successful resolution of a first ephemeral ID (EID), wherein the first resolution message comprises at least a first ephemeral ID key (EIK) associated with a first registered beacon determined from the first EID; updating, at the CDS, a set of candidate EIKs associated with the first registered beacon, such that the first EIK is indicated as having been detected; and communicating, from the CDS to the resolver server, a replacement set of candidate EIKs, based at least in part on the first EIK, to be registered with the resolver server.
  • CDS cloning detection server
  • EIK ephemeral ID key
  • a system comprising a processor and a non-transitory storage medium storing instructions operative, when executed on the processor, to perform functions including: receiving, at a cloning detection server (CDS) from a resolver server, a first resolution message comprising at least a first candidate ephemeral ID key (EIK) associated with a first registered beacon resolved from a first ephemeral ID (EID) query received at the resolver server; receiving, at the CDS from the resolver server, a second resolution message comprising at least a second candidate EIK associated with the first registered beacon determined from a second EID query received at the resolver server; comparing the key state evolutions of the first candidate EIK and the second candidate EIK; and communicating, responsive to a determination that the key state evolutions of the first candidate EIK and the second candidate EIK are divergent, a cloning detection notification to an owner associated with the first registered beacon.
  • CDS cloning detection server
  • EIK ephe
  • a system comprising a processor and a non-transitory storage medium storing instructions operative, when executed on the processor, to perform functions including: maintaining, for each of a plurality of beacon devices, an associated candidate set of at least one candidate ephemeral ID key (EIK); periodically updating each of the candidate sets by replacing at least one EIK in a candidate set with at least two EIKs derived therefrom; and in response to a resolution request containing an ephemeral ID (EID): identifying, from the candidate EIKs, a selected EIK that is consistent with the EID; responding to the resolution request by returning content stored in association with the beacon device associated with the selected EIK; and storing in association with the identified beacon device an indicator of a detection event of the selected EIK.
  • EIK ephemeral ID key
  • a method of detecting cloning of an ephemeral ID beacon comprising: receiving a first beacon resolver request comprising information regarding a first ephemeral beacon ID and a first random portion; receiving a second beacon resolver request comprising information regarding a second ephemeral beacon ID and a second random portion; responsive to a determination that i) the first ephemeral beacon ID and the second ephemeral beacon ID match, and ii) the first random portion and the second random portion do not match: alerting a registered owner of a beacon associated with the first and second beacon resolver requests of cloning of the beacon.
  • the method may include wherein the first ephemeral ID and first random portion are hashed together (or some other cryptographic transformation is applied or performed).
  • a method performed by a beacon device comprising: periodically updating an ephemeral ID key (EIK) stored at the beacon device by selecting a random value from a predetermined range of values and combining the selected value with a current EIK to generate a new EIK; generating an ephemeral ID (EID) based on the new EIK; and transmitting the EID.
  • EIK ephemeral ID key
  • the method may include wherein generating the EID based on the EIK comprises: determining a current time value; and encrypting the current time value using the EIK as an encryption key.
  • the method may include wherein the EID is transmitted in an Eddystone format.
  • the method may include wherein the updating of the EID is performed at the start of each of a plurality of epochs.
  • FIG. 7 is a system diagram of an exemplary WTRU 702, which may be employed as a CDS, receiver, resolver, or the like, in embodiments described herein. As shown in FIG.
  • the WTRU 702 may include a processor 718, a communication interface 719 including a transceiver 720, a transmit/receive element 722, a speaker/microphone 724, a keypad 726, a display/touchpad 728, a non-removable memory 730, a removable memory 732, a power source 734, a global positioning system (GPS) chipset 736, and sensors 738. It will be appreciated that the WTRU 702 may include any sub-combination of the foregoing elements while remaining consistent with an embodiment.
  • GPS global positioning system
  • the processor 718 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Array (FPGAs) circuits, any other type of integrated circuit (IC), a state machine, and the like.
  • the processor 718 may perform signal coding, data processing, power control, input/output processing, and/or any other functionality that enables the WTRU 702 to operate in a wireless environment.
  • the processor 718 may be coupled to the transceiver 720, which may be coupled to the transmit/receive element 722. While FIG. 7 depicts the processor 718 and the transceiver 720 as separate components, it will be appreciated that the processor 718 and the transceiver 720 may be integrated together in an electronic package or chip.
  • the transmit/receive element 722 may be configured to transmit signals to, or receive signals from, a base station over the air interface 716.
  • the transmit/receive element 722 may be an antenna configured to transmit and/or receive RF signals.
  • the transmit/receive element 722 may be an emitter/detector configured to transmit and/or receive IR, UV, or visible light signals, as examples.
  • the transmit/receive element 722 may be configured to transmit and receive both RF and light signals. It will be appreciated that the transmit/receive element 722 may be configured to transmit and/or receive any combination of wireless signals.
  • the WTRU 702 may include any number of transmit/receive elements 722. More specifically, the WTRU 702 may employ MIMO technology. Thus, in one embodiment, the WTRU 702 may include two or more transmit/receive elements 722 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 716.
  • the WTRU 702 may include two or more transmit/receive elements 722 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 716.
  • the transceiver 720 may be configured to modulate the signals that are to be transmitted by the transmit/receive element 722 and to demodulate the signals that are received by the transmit/receive element 722.
  • the WTRU 702 may have multi-mode capabilities.
  • the transceiver 720 may include multiple transceivers for enabling the WTRU 702 to communicate via multiple RATs, such as UTRA and IEEE 802.11 , as examples.
  • the processor 718 of the WTRU 702 may be coupled to, and may receive user input data from, the speaker/microphone 724, the keypad 726, and/or the display/touchpad 728 (e.g., a liquid crystal display (LCD) display unit or organic light-emitting diode (OLED) display unit).
  • the processor 718 may also output user data to the speaker/microphone 724, the keypad 726, and/or the display/touchpad 728.
  • the processor 718 may access information from, and store data in, any type of suitable memory, such as the non-removable memory 730 and/or the removable memory 732.
  • the non-removable memory 730 may include random-access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device.
  • the removable memory 732 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, and the like.
  • SIM subscriber identity module
  • SD secure digital
  • the processor 718 may access information from, and store data in, memory that is not physically located on the WTRU 702, such as on a server or a home computer (not shown).
  • the processor 718 may receive power from the power source 734, and may be configured to distribute and/or control the power to the other components in the WTRU 702.
  • the power source 734 may be any suitable device for powering the WTRU 702.
  • the power source 734 may include one or more dry cell batteries (e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel metal hydride (NiMH), lithium-ion (Li-ion), and the like), solar cells, fuel cells, and the like.
  • the processor 718 may also be coupled to the GPS chipset 736, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 702.
  • location information e.g., longitude and latitude
  • the WTRU 702 may receive location information over the air interface 716 from a base station and/or determine its location based on the timing of the signals being received from two or more nearby base stations. It will be appreciated that the WTRU 702 may acquire location information by way of any suitable location-determination method while remaining consistent with an embodiment.
  • the processor 718 may further be coupled to other peripherals 738, which may include one or more software and/or hardware modules that provide additional features, functionality and/or wired or wireless connectivity.
  • the peripherals 738 may include sensors such as an accelerometer, an e-compass, a satellite transceiver, a digital camera (for photographs or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands free headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, and the like.
  • sensors such as an accelerometer, an e-compass, a satellite transceiver, a digital camera (for photographs or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands free headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module
  • FIG. 8 depicts an exemplary network entity 790 that may be used in embodiments of the present disclosure.
  • network entity 790 includes a communication interface 792, a processor 794, and non-transitory data storage 796, all of which are communicatively linked by a bus, network, or other communication path 798.
  • Communication interface 792 may include one or more wired communication interfaces and/or one or more wireless-communication interfaces. With respect to wired communication, communication interface 792 may include one or more interfaces such as Ethernet interfaces, as an example. With respect to wireless communication, communication interface 792 may include components such as one or more antennae, one or more transceivers/chipsets designed and configured for one or more types of wireless (e.g., LTE) communication, and/or any other components deemed suitable by those of skill in the relevant art. And further with respect to wireless communication, communication interface 792 may be equipped at a scale and with a configuration appropriate for acting on the network side— as opposed to the client side— of wireless communications (e.g., LTE communications, Wi-Fi communications, and the like).
  • wireless communications e.g., LTE communications, Wi-Fi communications, and the like.
  • communication interface 792 may include the appropriate equipment and circuitry (perhaps including multiple transceivers) for serving multiple mobile stations, UEs, or other access terminals in a coverage area.
  • Processor 794 may include one or more processors of any type deemed suitable by those of skill in the relevant art, some examples including a general-purpose microprocessor and a dedicated DSP.
  • Data storage 796 may take the form of any non-transitory computer-readable medium or combination of such media, some examples including flash memory, read-only memory (ROM), and random-access memory (RAM) to name but a few, as any one or more types of non-transitory data storage deemed suitable by those of skill in the relevant art could be used. As depicted in FIG. 9, data storage 796 contains program instructions 797 executable by processor 794 for carrying out various combinations of the various network-entity functions described herein.
  • ROM read only memory
  • RAM random access memory
  • register cache memory
  • semiconductor memory devices magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks, and digital versatile disks (DVDs).
  • a processor in association with software may be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, or any host computer.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

Le clonage de balises sans fil peut être détecté et/ou empêché, où un état secret ou "clé" d'une balise change selon un facteur aléatoire dans le temps, de sorte que les états des balises authentiques et clonées divergent au fil du temps. Dans un mode de réalisation de la présente invention, pour chaque dispositif de balise d'une pluralité de dispositifs de balise, un ensemble candidat associé d'au moins une clé d'ID éphémère (EIK) candidate est maintenu (305). Les ensembles candidats peuvent être périodiquement mis à jour (310) en remplaçant au moins une EIK dans chaque ensemble candidat avec au moins deux EIK dérivées de ces dernières. En réponse à une demande de résolution (315) contenant un ID éphémère (EID) : une EIK sélectionnée peut être identifiée (315) à partir des ELK candidates qui est conforme à l'EID ; un contenu associé au dispositif de balise associé à l'EIK sélectionnée peut être renvoyé (320) ; et l'ensemble d'EIK candidates associées au dispositif de balise identifié peut être mis à jour (325) pour inclure uniquement l'EIK sélectionnée.
PCT/US2017/061163 2016-11-18 2017-11-10 Systèmes et procédés de détection de clonage de balise sans fil WO2018093683A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US201662424181P 2016-11-18 2016-11-18
US62/424,181 2016-11-18

Publications (1)

Publication Number Publication Date
WO2018093683A1 true WO2018093683A1 (fr) 2018-05-24

Family

ID=60480442

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2017/061163 WO2018093683A1 (fr) 2016-11-18 2017-11-10 Systèmes et procédés de détection de clonage de balise sans fil

Country Status (1)

Country Link
WO (1) WO2018093683A1 (fr)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20200401993A1 (en) * 2018-11-29 2020-12-24 Red Hat, Inc. Implementation of rolling key to identify systems inventories
US11930356B2 (en) 2020-04-15 2024-03-12 Google Llc Three-party cryptographic handshake protocol

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2009158643A1 (fr) * 2008-06-27 2009-12-30 Qualcomm Incorporated Procédés et appareils pour la divulgation sécurisée d’informations d’identification et / ou de découverte
US9043602B1 (en) * 2014-06-10 2015-05-26 Google Inc. Generating and using ephemeral identifiers and message integrity codes

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2009158643A1 (fr) * 2008-06-27 2009-12-30 Qualcomm Incorporated Procédés et appareils pour la divulgation sécurisée d’informations d’identification et / ou de découverte
US9043602B1 (en) * 2014-06-10 2015-05-26 Google Inc. Generating and using ephemeral identifiers and message integrity codes

Non-Patent Citations (11)

* Cited by examiner, † Cited by third party
Title
BOWERS ET AL.: "Drifting Keys: Impersonation detection for constrained devices", INFOCOM, 2013 PROCEEDINGS IEEE, 2013, pages 1025 - 1033, XP032440851, DOI: doi:10.1109/INFCOM.2013.6566892
CONTI ET AL.: "Distributed detection of clone attacks in wireless sensor networks", IEEE TRANS. DEPENDABLE SEC. COMPUT., vol. 8, no. 5, 2011, pages 685 - 698, XP011329885, DOI: doi:10.1109/TDSC.2010.25
CONTI ET AL.: "Wireless sensor replica detection in mobile environments", ICDCN, 2012, pages 249 - 264, XP047370996, DOI: doi:10.1007/978-3-642-25959-3_19
ELKHIYAOUI ET AL.: "Checker: on-site checking in RFID-based supply chains", WISEC, 2012, pages 173 - 184
G. ITKIS: "Forward security: Adaptive cryptography-time evolution", HANDBOOK OF INFORMATION SECURITY, 2006
HARRIS ALBERT F ET AL: "Security and Privacy in Public IoT Spaces", 2016 25TH INTERNATIONAL CONFERENCE ON COMPUTER COMMUNICATION AND NETWORKS (ICCCN), IEEE, 1 August 2016 (2016-08-01), pages 1 - 8, XP032961055, DOI: 10.1109/ICCCN.2016.7568573 *
LEHTONEN ET AL.: "How to detect cloned tags in a reliable way from incomplete RFID traces", IEEE INTERNATIONAL CONFERENCE ON RFID, 2009, pages 257 - 264
R. ANDERSON; M. KUHN: "Tamper resistance — a cautionary note", USENIX SECURITY, 1996, pages 1 - 11
STAAKE ET AL.: "Extending the EPC network: the potential of RFID in anti-counterfeiting", ACM SYMPOSIUM ON APPLIED COMPUTING, 2005
Y. OREN; A. SHAMIR: "Remote password extraction from RFID tags", IEEE TRANSACTIONS ON COMPUTERS, vol. 56, no. 9, 2007, pages 1292 - 1296, XP011190118, DOI: doi:10.1109/TC.2007.1050
ZANETTI ET AL.: "Tailing RFID Tags for Clone Detection", NDSS, 2013

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20200401993A1 (en) * 2018-11-29 2020-12-24 Red Hat, Inc. Implementation of rolling key to identify systems inventories
US11930356B2 (en) 2020-04-15 2024-03-12 Google Llc Three-party cryptographic handshake protocol

Similar Documents

Publication Publication Date Title
JP6894059B2 (ja) ビーコンメッセージの伝送
US10616765B2 (en) Security for wireless broadcasts
US10212689B2 (en) Generating and publishing validated location information
CN107079525B (zh) 跟踪移动设备
EP3384629B1 (fr) Système et procédé pour une mesure d'utilisation de dispositif inviolable
US8595504B2 (en) Light weight authentication and secret retrieval
US10219106B1 (en) Secure BLE broadcast system for location based service
WO2012119434A1 (fr) Procédé d'authentification dynamique entre un lecteur et une étiquette, et dispositif pour ce procédé
EP2405376B1 (fr) Utilisation d'un interpréteur de microcodes intégrée dans un processeur
EP3338398B1 (fr) Serveur et procédé de transmission d'un message géo-chiffré
US11902856B2 (en) Electronic device
EP3598333A1 (fr) Gestion de mise à jour de dispositif électronique
CN105208551A (zh) 传输、获取信标数据的方法及装置
WO2014064339A1 (fr) Procédés et appareil pour garantir une sécurité de données dans des réseaux ad hoc mobiles
WO2017040124A1 (fr) Système et procédé pour la détection de dispositifs clonés
CN106407794B (zh) 一种防止信标设备被伪造或复制的方法
WO2018093683A1 (fr) Systèmes et procédés de détection de clonage de balise sans fil
CN104243153A (zh) 一种用于发现设备的用户的方法和用户设备
KR20200056192A (ko) 데이터 통신 시스템과 데이터 통신 방법, 서버, 차량
US20210182441A1 (en) Cable Security
CN109039651A (zh) 一种位置信息的传输方法、传输装置及卫星定位系统
WO2017059282A1 (fr) Système et procédé pour la découverte avec protection de la vie privée de dispositifs sans fil et de leur position
US20230189357A1 (en) Packet transmission method for electronic device positioning service and apparatus thereof
KR20220018876A (ko) 전자 장치의 위치 확인 서비스를 위한 패킷 전송 방법 및 그 장치
JP2021064315A (ja) 個体識別装置、個体識別システム、および、個体識別方法

Legal Events

Date Code Title Description
DPE1 Request for preliminary examination filed after expiration of 19th month from priority date (pct application filed from 20040101)
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 17805061

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

Country of ref document: EP

Kind code of ref document: A1