WO2018125945A1 - System and method for lightweight broadcast authentication - Google Patents

Abstract

Systems and methods for lightweight broadcast authentication. In a method, a receiver receives a transmission including a candidate temporal key and candidate verification values for a future epoch. The receiver parses the transmission, and compares test values calculated using the candidate temporal key to previously authenticated values held by the receiver. If verified, the candidate verification values are saved at the receiver for comparison with future transmissions. If there is a verification failure, the receiver may output or generate an alert that the receiver is out of contact with a beacon authentication network.

Description

SYSTEM AND METHOD FOR LIGHTWEIGHT BROADCAST AUTHENTICATION

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] The present application is a non-provisional filing of, and claims benefit under 35 U.S.C. §119(e) from, U.S. Provisional Patent Application Serial No. 62/440,672, entitled "System and Method for

Lightweight Broadcast Authentication," filed December 30, 2016, the entirety of which is incorporated herein by reference.

BACKGROUND

[0002] In many settings, it would be valuable for a beacon's emissions to be authenticable offline. For example, to protect against shrinkage in a supply-chain with high-value goods such as automotive parts or electronics, items or collections of items could be instrumented with low-cost devices that verify continuous proximity to an RF beacon. However, such low-cost devices cannot feasibly maintain internet connectivity, and therefore would benefit from the ability to authenticate beacon emissions offline.

[0003] Examples of current approaches include public-key cryptography, key sharing, and the TESLA family of authentication protocols.

[0004] Public-key cryptography is too resource-intensive for beacons (and thus not used in, e.g., Google's Eddystone standard. There has been some academic exploration of this approach, for example in Thorsten Schuiz, Frank Golatowski, Dirk Timmermann, "Secure privacy preserving information beacons for public transportation systems," PerCom Workshops 2016: 1-6. Such an approach, however, has not proven practical and has not been adopted in popular beacon products.

[0005] An alternative is for the beacon and devices to share keys, but this requires onerous key setup procedures and exposes keys to potential compromise. For example, use of fixed-key broadcast authentication to protect against loss of crates in a warehouse would require that each crate be programmed with a key upon entry into the warehouse. Compromise of the key in a single crate would result in complete compromise of the warehouse anti-theft system.

[0006] To address this problem, a family of existing approaches based on the TESLA protocol instead relies on symmetric-key cryptography and loose (relative) time synchronization between the beacon and devices, as described in A. Perrig, R. Canetti, J. D. Tygar, D. Song. (2002), 'The TESLA Broadcast Authentication Protocol," RSA CryptoBytes, vol. 5, no. 2, pp. 2-13. The TESLA protocol and derivative schemes call for a broadcasting device to traverse a hash chain, releasing a new preimage in each epoch. Maintaining such a hash chain, however, imposes a considerable computational and storage burden on a transmitting device, as well as implementation complexity, rendering the approach unsuitable for extremely low-end devices such as Bluetooth BLE (Bluetooth low energy) beacons.

[0007] Additionally, TESLA-like schemes call for computation of a long hash chain upon initialization, which for a low-cost beacon employs key setup by an external device— an inflexible regime that entails a risk of key disclosure upon setup— or considerable time and power drain on the beacon.

SUMMARY

[0008] Cryptographic authentication of data transmitted over a broadcast channel has many applications. Among these, and without limitation, is secure proximity detection to prevent theft of high- value items or parts or unauthorized movement of people or devices. In many settings, such authentication must occur offline and without pre-shared cryptographic keys. Existing authentication protocols for such settings, however, are generally too resource-intensive for low-cost wireless devices. The systems and methods disclosed herein relate to broadcast authentication with minimal cryptographic computation for both key setup and broadcast and are thus well suited to low-cost, low-energy devices such as BLE beacons and receivers.

[0009] In an exemplary embodiment, a method is provided for monitoring proximity of a receiver to a beacon device. During an initial epoch, e.g. during a setup period, the receiver receives at least a first message from the beacon device. Based on proximity of the receiver to the beacon device, it is stipulated that the first message is authentic. For each of a plurality of respective predetermined epochs subsequent to the initial epoch, the receiver operates to determine whether it has received during the respective epoch, a subsequent authentic message from the beacon device. The receiver determines that a subsequent message is authentic only if (i) the subsequent message is authenticated by a selected key, and (ii) a cryptographic commitment to use the selected key was provided in a previously-received authentic message from the beacon device. In some embodiments, the receiver receives the selected key from the beacon device after the respective epoch has ended (e.g. in the next epoch) and validates the received key under the cryptographic commitment.

[0010] In some embodiments, the receiver issues an alert in response to a determination that no authentic message was received from the beacon device during the respective epoch. In some embodiments, the receiver at least partially disables equipment to which the receiver is affixed in response to a determination that no authentic message was received from the beacon device during the respective epoch.

[0011] In some embodiments, the cryptographic commitment to use the selected key includes a hash value of the selected key under a predetermined hash function. Alternatively, other cryptographic transformations (such as encryption) may be used as a cryptographic commitment. In embodiments that use a hash value as a cryptographic commitment, a method such as the following may be performed. After the respective epoch, the receiver receives a candidate key from the beacon. The receiver applies the predetermined hash function to the candidate key to generate a calculated hash value and determines whether the calculated hash value is the same as the hash value provided as a cryptographic commitment in the previously-received authentic message.

[0012] In some embodiments, the subsequent message includes a message authentication code. To determine whether the subsequent message is authenticated by a selected key, the receiver may perform a method such as the following. After receiving a candidate key, the receiver generates a calculated message authentication code from the subsequent message using the candidate key and determines whether the calculated message authentication code is the message authentication code that was provided in the subsequent message.

[0013] Through proximity-based, trust-on-first-use authentication used in exemplary embodiments, a beacon message received during an initial epoch may be stipulated to be valid without the use of any authenticated channel between the receiver and the beacon device or any exchange of cryptographic credentials between the beacon and the receiver.

[0014] The subsequent authentic message may itself include a cryptographic commitment to use a second selected key in an epoch after the respective epoch.

[0015] In another exemplary embodiment, a method is provided for authenticating a current message received during a current epoch of a plurality of predetermined epochs. A receiver device receives a prior message before the current epoch, where the prior message includes a cryptographic commitment to use a selected key (e.g. a hash value of the selected key). The receiver receives the current message during the current epoch, where the current message includes a current message body and a current message authentication code. The receiver later receives a subsequent message after the current epoch, wherein the subsequent message includes a subsequent key. The receiver determines that the current message is authentic only in response to a determination that (i) the prior message is authentic, (ii) the current message authentication code is valid under the subsequent key, and (iii) the cryptographic commitment was a commitment to use the subsequent key. [0016] Exemplary embodiments further include methods performed by a beacon device and systems configured to perform the methods described herein.

BRIEF DESCRIPTION OF THE DRAWINGS

[0017] A more detailed understanding may be had from the following description, presented by way of example in conjunction with the accompanying drawings, wherein:

[0018] FIG. 1 illustrates one embodiment of data update at a receiver.

[0019] FIG. 2 illustrates a time-ordered data flow diagram for one embodiment of the present systems and methods.

[0020] FIG. 3A illustrates a time-ordered data flow diagram for one embodiment of the present systems and methods, including an authentication failure.

[0021] FIG. 3B illustrates a time-ordered data flow for one embodiment of the present systems and methods, including windowing.

[0022] FIG. 4 is a functional block diagram of an exemplary beacon device used in some embodiments.

[0023] FIG. 5 is a functional block diagram of an exemplary receiver device used in some embodiments.

[0024] FIG. 6 is a flow diagram of an exemplary method for monitoring continued proximity between a beacon and a receiver device.

[0025] FIG. 7 is a flow diagram of an exemplary method performed by a receiver device to authenticate messages received from a beacon.

[0026] FIG. 8 illustrates an exemplary wireless transmit/receive unit (WTRU) that may be employed as a receiver in some embodiments.

[0027] FIG. 9 illustrates an exemplary network entity that may be employed in some embodiments. DETAILED DESCRIPTION

[0028] A detailed description of illustrative embodiments will now be provided with reference to the various Figures. Although this description provides detailed examples of possible implementations, it should be noted that the provided details are intended to be by way of example and in no way limit the scope of the application.

[0029] Note that various hardware elements of one or more of the described embodiments are referred to as "modules" that carry out (i.e., perform, execute, and the like) various functions that are described herein in connection with the respective modules. As used herein, 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. 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.

Overview of Exemplary Embodiments.

[0030] The present systems and methods include processes relating to message authentication and key authentication.

[0031] Message authentication: In exemplary embodiments, a message M is authenticated by means of a message authentication code (MAC) in a time period (e.g., epoch) t under a key k[t+1]. The key k[t+1] is released in the subsequent epoch t+1. Provided that a receiver can authenticate k[t+1], it can then verify the authenticity of the message M. Message authentication codes may be generated (and/or authenticated) using techniques such as those described in, for example, FIPS PUB 198-1 (The Keyed-Hash Message Authentication Code (HMAC)), ISO/IEC 9797-1 (Mechanisms using a block cipher), or ISO/IEC 9797- 2 (Mechanisms using a dedicated hash-function), among other alternatives.

[0032] Key authentication: To permit verification of the key k[t+1 ], a hash of k[t+1 ] is included in the authenticated message of a previous emission. Various different hash functions may be used. For example, 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. Because of this, the systems and methods maintain the invariant that the receiver holds an authenticated hash of k[t+1] in a time period t, supporting message authentication in that period. In some embodiments, cryptographic transformations other than hash functions are employed.

[0033] In some embodiments, tolerance to message losses is achieved through multiple broadcasts during a given epoch (as in Eddystone-EID) and/or by having receivers maintain a window of authenticated hashes spanning multiple epochs.

[0034] Exemplary systems and methods can be implemented without the use of digital signatures or hash-chain maintenance. Features of the disclosed systems and methods include, but are not limited to:

[0035] Minimal setup cost: Exemplary systems and methods disclosed herein do not require computation of a hash chain upon setup. Key setup can therefore be performed quickly on-device. In contrast, because computation of a hash chain can be computationally expensive, schemes that employ a hash chain cannot easily be implemented within a low-resource device; instead, such schemes may need to rely on computation of hash chains by external devices. This can result in drawbacks for TESLA-like schemes: (a) an extra manufacturing step for construction of the device; (b) device keys are exposed to the manufacturing facility; and (c) key rotation in the field is cumbersome or infeasible.

[0036] Minimal on-the-fly computation: Exemplary methods and systems as disclosed herein may use only a small number of low-cost cryptographic operations. The number of operations may be constant.

[0037] Additionally, exemplary embodiments do not require that keys be structured within a hash chain. As a consequence, the disclosed systems and methods are implementable within the constraints of existing beacon standards, such as Eddystone (for example using a combination of ordinary Eddystone and Eddystone-EID protocols, as further discussed below).

[0038] In various embodiments of the disclosed systems and methods, a receiver receives a transmission including a candidate temporal key and candidate verification values for a future epoch. The receiver parses the transmission and compares test values calculated using the candidate temporal key to previously authenticated values held by the receiver. If verified, the candidate verification values are saved at the receiver for comparison with future transmissions. If there is a verification failure, the receiver may output or generate an alert that the receiver is out of contact with a beacon authentication network. In some embodiments, a verification failure may cause a device associated with the receiver to become partially or fully inoperative or to be otherwise disabled. In some embodiments, an alert may be issued (or a device may be disabled) in response to a failure to receive a verified transmission for a period of time, which may be a predetermined time threshold.

Exemplary Computer-Readable Instructions.

[0039] Exemplary systems and methods are discussed herein in terms of functions executed by a beacon, which emits messages (and keys), and a receiver, which authenticates beacon emissions. In some implementations, there may be multiple receivers per beacon.

[0040] Herein, a value x[t] is a time-varying key (e.g., temporal based identifier) associated with epoch t. For example, in an Eddystone-EID beacon, x[t] is the ephemeral identifier for the current time period.

[0041] Herein, <M> denotes an optional argument, an auxiliary message M. This value M is not needed for authentication of a beacon and may be omitted in some embodiments. The optional argument may represent side data a beacon may wish to transmit in an authenticated way to a receiver, which may be a useful optional feature for some implementations of the disclosed systems and methods.

[0042] Herein, T denotes the current time according to a device's (e.g., beacon's or receiver's) local clock. In operation, the device clocks are at least loosely synchronized in relative time, such that their relative skew does not vary significantly. Techniques know from, for example, Eddystone-EID systems may be used to implement time synchronization.

[0043] An application program interface (API) of the disclosed systems and methods may include one or more of the following three functions, among other possible functions:

[0044] Em/f(<M>) is executed by a beacon: takes as input optional message M and emits M, along with authentication of M and evolving key material. For authentication only, it suffices for a beacon to call EmitQ without arguments.

[0045] /n/f/a//ze(e'[t-1], e'[t]) is executed by a receiver upon setup. It takes as input a pair of successive beacon outputs. A trust-on-first-use (TOFU) regime is employed in some embodiments, in which it may be stipulated that no adversarial spoofing of a beacon has occurred upon setup, (even if such spoofing may potentially be attempted at a later time).

[0046] >4ivf/7enf/cafe(e'[t]) is executed by a receiver. It takes as input a beacon emission and verifies its authenticity. An authentication failure (indicating a forged beacon emission) calls a function failQ.

[0047] For simplicity, the present description focuses on embodiments in which there is only a single beacon in a particular region. In practice, multiple beacons may be active in overlapping regions. In this case, the various beacons additionally emit unique identifiers for disambiguation, and the systems and methods disclosed herein may be extended accordingly. In exemplary embodiments, a receiver successfully receives at least one emission per epoch. Discussed below are ways to increase the error tolerance of the systems and methods for cases where a receiver does not receive a transmission in a particular epoch.

[0048] In one embodiment of the present systems and methods, h'[t] denotes a candidate hash of key x'[t], i.e., if correct, h'[t] = H(x'[t]).

[0049] Similarly, m'[t] denotes a candidate MAC on h'[t], i.e., if correct, m'[t] = MACx[n](h'[t],<M>).

[0050] In one embodiment, a beacon may operate the emitQ function. For example, as

£m/^'f(<M>)

t ^ T

Compute x[t], x[t+1], x[t+2]

Output e[t] = {x[t], MACx[_t+i](H(x[t+2],<M>), H(x[t+2]),<M>; t}

[0051] At a receiver, a verification operation may be defined such that Verif[t]= TRUE if h'[t] has been successfully authenticated (and conversely Verif[t]= FALSE if h'[t] is not successfully authenticated).

[0052] In one embodiment, a receiver may operate the initializeQ function. This may occur at some time prior to a current epoch. The initialization may operate, for example, as /n/f/a//ze(e'[t-1], e'[t])

Parse e'[t-1] as {x'[t-1], m'[t+1], h'[t+1],<M>; t}

Parse e'[t] as {x'[t], m'[t+2], h'[t+2],<M>; t}

Store h'[t+1], h'[t+2], m'[t+2]

Verif[t] <r TRUE

Verif[t+1] - TRUE

T ^ t

[0053] At some time after the initialization, the receiver may receive an emission from a beacon and operate the authenticated function. For example, as

Authenticate^)

t ^ T

Parse e'[t] as {x'[t], m'[t+2], h'[t+2], <M>; t'}

if t≠ f

failQ;

Store m'[t+2], h'[t+2]

if Verif[t] = FALSE or H(x'[t])≠ h'[t] or m'[t+1]≠ MACx_1t](h'[t+1], <M>)

failQ;

Verif[t+1] - TRUE

Verif[t+2] <r FALSE

[0054] FIG. 1 illustrates a block diagram for one embodiment of a data update at a receiver.

[0055] In an exemplary embodiment, the receiver may maintain three registers, A, B, and C. In response to input e'[t], the receiver verifies the two equalities H(x'[t])-LA and C-LMACx^B).

[0056] In response to input e'[t] = {x'[t], m'[t+2], h'[t+2], <M>; t'}, the receiver verifies that:

• the hash of the received key x'[t] matches the previously stored authenticated hash of x[t] (e.g., data stored in A, or H(x[t])); and

• the previously stored MAC (e.g., data stored in C, or MAC_X[t](H(x[t+1]))) matches a computed MAC under the received key x'[t] of the previously stored hash of x[t+1] (e.g., a computed

MACx[t](H(x[t+1])), where H(x[t+1]) was previously stored in B).

[0057] If both authentication checks are successful, the receiver may update the stored values. The stored authenticated hash of x[t] is replaced by the previously stored hash of x[t+1] (e.g., register B at the beginning of epoch t is authenticated and replaces register A at the end of epoch t). The received candidate MAC (e.g., m'[t+2]) replaces the data in register C at the end of epoch t. The received candidate hash (e.g., h'[t+2]) replaces the data in register B at the end of epoch t.

[0058] After updating, register A maintains a successfully authenticated hash, and registers B and C maintain values to be authenticated upon receipt of the next beacon emission.

[0059] FIG. 2 illustrates a time-ordered data flow diagram for one embodiment of the present systems and methods. For simplicity, FIG. 2 illustrates a case in which the emissions from the beacon are correct and authentic. Alternative scenarios will be discussed further below.

[0060] As shown in FIG. 2, there is a previously established beacon and a previously established (e.g., initialized) receiver. At some time to, the receiver receives an emission from the beacon. For example, the emission at time to may comprise e[t₀] = {K₀, H(K₂), MAC_Jfi (H(K₂)), < M >; t₀}. From an update at the end of the previous epoch, the receiver may have in storage an authenticated hash value for the current epoch (e.g., H(Ko)), an authenticated hash value for the next epoch (e.g., H(Ki)), and a MAC under the key for the current epoch for the hash of the key for the next epoch (e.g., MAC_Jfo (H(K₁))). After parsing the received emission, the receiver attempts to perform authentication. The receiver hashes the value of received key Ko, and determines if the calculated value matches the previously stored

authenticated hash value (e.g., previously stored H(Ko)). The receiver next calculates a MAC using the received key Ko over the previously stored (and authenticated) value for H(Ki), and determines if the calculated value matches the previously stored MAC (e.g., MAC^ (H (¾))). Based on these two determinations, if both are true (as in FIG. 2) the received emission is authenticated, along with any message M contained in the emission. After authentication (or otherwise at the end of the current epoch to), the values stored by the receiver may be updated. For example,

• the authenticated current epoch hash value H(Ko) may be updated to the authenticated hash value for the next epoch H(Ki), which was previously stored by the receiver;

• the received hash value H(K2) (e.g., received hash value for the subsequent epoch) may replace the previously stored authenticated hash value for the next epoch (e.g., H(Ki)); and

• the received MAC (e.g., MAC_Jfi (H(K₂))) may replace the previously stored MAC (e.g.,

MAC^ CHCKi))).

[0061] In subsequent epochs (e.g., ti, k, etc.), further emissions from the beacon may be received by the receiver and authenticated, resulting in further updating of the stored values at the receiver, as further shown in FIG. 2. [0062] In an alternative scenario, such as set forth in FIG. 3A, a receiver may detect an emission at time to from an authentic beacon A. The emission may be parsed and authenticated, and the stored values at the register updated accordingly. At a later time ti, the receiver may detect an emission from a non- authentic beacon A'. This emission may include an incorrect key ΚΊ, and may in some instances further include additional incorrect candidate values (e.g., H'(K'3) and MAC^ (H'(K'₃))). When the Receiver attempts to authenticate the emission with the received key ΚΊ, it will result in a failure of verification. Based on the failed verification, the Receiver may trigger the fail() operation, which may, for example, log a message, disable an associated device, or generate an alarm (e.g., digital or audible, etc.).

[0063] Eddystone implementation: In some embodiments, the systems and methods set forth herein are implemented within the Eddystone protocol. Eddystone-EID emits a rotating identifier x[t] in epoch t. Emission e[t] = {x[t], MAC_X[t₊i](H(x[t+2]), H(x[t+2])} can be partitioned such that x[t] is emitted via an Eddystone-EID beacon frame and MAC_X[t+i](H(x[t+2]) and H(x[t+2]) are emitted within a sequence of Eddystone-TLM (or -eTLM) frames.

[0064] It should be noted that in some embodiments, two types of receiving devices are supported simultaneously: (1) Offline receiving devices as specified herein and (2) Online devices that resolve EID values but ignore TLM frames— and are thus standard, unmodified Eddystone-EID devices.

[0065] Enhanced error tolerance: In some embodiments, keys, hashes, and MACs are included for a sequence of more than one future epoch in a given emission e[t]. Such windowing may ensure successful authentication even if a receiver does not successfully receive a beacon emission in one or more epochs.

[0066] For example, with reference to FIG. 3B, if a given emission at to is windowed such that it, in addition to {K₀, H(K₂), MAC^H K;,)), < M >; t₀} as in the scenario of FIG. 2, the emission also includes values hash and MAC values for at least one additional epoch after to. In such a case, the emission may comprise {K₀, H(K₂), MAC^ (H(K₂)), < M >, H(K₃), MAC_¾ (H(K₃))_; t₀}. After the message is authenticated, as in relation to FIG. 2, the additional hash and MAC values may be stored in association with a future epoch fe. (In further embodiments, a plurality of future epochs may be incorporated into the emission at a given epoch, in analogous fashion.)

[0067] Subsequently, if an emission was not received in epoch ti, but then an emission was received in epoch t2, such that the emission in included the temporal key K2, the receiver may retrieve the authenticated values for H(K2), H(K₃), and MAC_Jf2 (H(K₃)) and attempt authentication as previously described. Upon successful authentication, any values included in the emission may be stored as authenticated. Analogously, such procedure may be extended for a gap of a plurality of epochs, based on the number of future epochs having values previously authenticated (such as at a time to). [0068] Similarly, in Eddystone-EID implementations, the additional windowed epochs in a given emission may be included in additional -TLM (or -eTLM) frames.

[0069] A block diagram of a beacon 400 according to an exemplary embodiment is provided in FIG. 4. The beacon of FIG. 4 may include storage 402 for a private identifier, which may be used to calculate temporal identifiers (or keys) for the beacon, based time measurements by a clock 404 of the beacon. In various embodiments, there may be one or more key generation modules (e.g., a current key generation module 406 and a future key generation module 408). In some embodiments, a single key generation module may generate current and future keys for the beacon. For example, a current key x[t] may be passed to an emission generation module 410. Also, a generated future key x[t+2] may be provided as input to a hash function module 412 to calculate a hash value H(x[t+2]), and a generated future key x[t+1] and the hash value H(x[t+2]) may be passed to a MAC module 414 to calculate a MAC value. These various values, such as x[t], H(x[t+2]), MAC_x[t+1](H(x[t + 2])), current epoch t, and in some embodiments an optional message <M>, may be combined at the emission generation module 410 into one or more outputs. The one or more outputs may then be passed to an RF transmitter 416 for transmitting one or more frames generated by the emission generation module.

[0070] At the start of each new epoch as measured by the clock (e.g. every day at midnight GMT, among numerous other possibilities), or at some other predetermined interval, the beacon may calculate new values for current and/or future keys, and update its emissions accordingly. The module is further provided with a software or hardware hash function module, which applies a hash function to a combination (such as a concatenation) of the current stored key and the current time, and the outcome is stored as the new EIK. In some embodiments, the beacon operates to transmit frames using the Eddystone format. To generate an ephemeral ID for transmission in a beacon frame, the beacon is provided with a software or hardware encryption module, which may be an AES encryption module (or such module may be incorporated into the one or more key generation modules). The encryption module operates to encrypt a current time value read from the clock (to a predetermined precision) using the stored private identifier as the encryption key. The outcome of the encryption (or a predetermined subset of bits from the encryption) is used as the current key, or EID in Eddystone embodiments. The beacon is further equipped with an RF transmitter for transmitting emission frames.

[0071] A block diagram of an exemplary receiver device is provided in FIG. 5. The receiver device may be, for example, a smartphone, tablet computer, or other wireless transmit-receive unit (WTRU) as described in greater detail with respect to FIG. 6.

[0072] A beacon emission is received at an RF receiver 505 of the receiver device. The emission may be passed to an emission parsing module 510, which is configured to parse the emission into its relevant portions (e.g., candidate key x'[t], candidate MAC value m'[t+2], candidate hash h'[t+2], optional message <M>, epoch indicator t', etc.).

[0073] In some embodiments, an epoch indicator t' may be passed to a comparison module 535 from the emission parsing module 510. The comparison module 535 may obtain a current epoch t for the Receiver from a clock 530, and compare this to the epoch indicator t'. In some embodiments, if there is a non-match, the comparison module 535 may trigger a failure module / alarm 540.

[0074] The emission parsing module 510 may pass the candidate key x'[t] to a hash function module 515. The hash function module 515 may perform a preset hash operation on the candidate key x'[t] to calculate a candidate hash H(x'[t]). This calculated value may then be passed to the comparison module 535.

[0075] The emission parsing module 510 may also pass the candidate key x'[t] to a MAC module 520. The MAC module 520 may retrieve the previously authenticated hash H(x[t+1]) from a storage 525. Using these values (and in some embodiments, a message parsed from the emission as well), the MAC module 520 may calculate a test MAC, and pass the calculated test MAC to the comparison module 535. In some embodiments, the MAC module may receive indication of the current and/or future epoch indicators from the clock 530, as to permit retrieval of the correct values from storage 525.

[0076] The comparison module 535 may receive the test hashed value from the hash function module 515 and the test MAC from the MAC module 520. These received values may be compared, respectively, to the previously authenticated hash H(x[t]) and the MAC value m[t+1], each retrieved from storage 525. If each respective comparison results in verification of the calculated values to the previously authenticated and stored values, the comparison module 535 may store parsed values from the emission in the storage as replacement authenticated values (see discussion in relation to FIGs. 1 and 2 above for further discussion of replacing values). If either of the comparisons results in a failed verification, the comparison module 535 may trigger the failure module / alarm 540.

[0077] In some embodiments, a message module 545 may act on the message content <M>, as appropriate for particular applications of the present systems and methods (e.g., transmitted side data, etc.).

[0078] In some embodiments, such as where Eddystone formats are used, the receiver may communicate with a resolver to decipher an EID. In some embodiments, the resolver may be implemented at the same device as the receiver.

[0079] In one exemplary implementation, a hospital may wish to protect high-value medical equipment by generating an alarm if a piece of equipment is removed from the hospital. Such protection can be achieved using the systems and methods disclosed herein by having beacons placed around the hospital such that equipment remains in continuous contact with at least one beacon. Each piece of equipment may be equipped with a receiver (e.g. incorporated therein or mounted thereto) that verifies such contact and logs a message or generates an alarm (audible or digital) should a break in contact occur. (Note that logged messages can be useful in detecting temporary removal of equipment, e.g., illicit borrowing.)

[0080] Exemplary embodiments disclosed herein can help prevent replay attacks. For example, one might consider a scheme in which a piece of equipment broadcasts a unique identifier, and a receiving device verifies continuous receipt of the identifier. Alternatively, one might consider a scheme in which a beacon emits a unique identifier and a piece of equipment checks for continuous contact with the beacon. In either case, a thief can simply capture and replay the identifier in a cheap substitute device. Such an attack is straightforward to mount.

[0081] Note additionally that it would be undesirable for a piece of equipment to require an internet connection (as for online Eddystone-EID authentication). It would also be undesirable for all equipment in a hospital to share a key with a beacon: if the key is stolen through compromise of a single Receiver, the integrity of the whole system would be compromised, e.g., a thief could impersonate Beacons.

[0082] A similar approach can be adopted to deter and detect theft of high-value goods (e.g., expensive mobile devices, automotive parts, etc.) from a warehouse or shop.

Exemplary Authentication Methods.

[0083] An exemplary authentication method including a receiver device setup operation are illustrated in FIG. 6. The embodiment of FIG. 6 allows a device equipped with a receiver to be paired with a beacon without requiring that device to validate cryptographic credentials of the beacon. For example, no cryptographic keys of the beacon need be provided to the receiver, and setup can be performed without establishing any authenticated channel between the beacon and the receiver. In step 602, the receiver device receives a beacon message. If the receiver device is in a setup mode (which may be determined in step 604), the receiver device determines whether it is in proximity to the beacon. In some embodiments, the mere fact that the receiver device has successfully received a beacon message is sufficient to make a determination of proximity. In other embodiments, additional criteria may be used in determining whether a beacon is in proximity. One such criterion may be a minimum received signal strength. Another such criterion may be a user input of confirmation that the beacon desired for pairing is in proximity to the receiver device. For example, the receiver device may display an identifier received in the beacon message, and the user may confirm whether the displayed identifier is an identifier of a proximate beacon (e.g. an identifier printed or otherwise displayed on the beacon itself). Various other techniques may alternatively be used for confirming that the beacon is in proximity to the receiver device. [0084] If the beacon is proximate to the receiver device, then in step 608, the receiver device pairs with the beacon by stipulating that the message received from the beacon is an authentic message. A message that has been stipulated to be authentic is treated as authentic for the purpose of testing the authenticity of subsequent messages.

[0085] Various different techniques may be employed to put a receiver device in a setup mode. For example, proper use of a physical key or password may serve as a prerequisite for putting the receiver device into setup mode. During setup mode, the receiver device may also synchronize with the paired beacon device such that there is substantial agreement between the beacon and receiver devices on the start and end times of each of a plurality of predetermined epochs. For example, each epoch may start on the hour and have a duration of one hour, although other epoch durations and start times by be used.

[0086] When the receiver device is not in setup mode, then the receiver device operates to determine, for each of the plurality of predetermined epochs, whether an authentic message has been received from the paired beacon. To do this, for a current message received in step 602, the receiver device operates in step 610 to determine whether the current message is authentic. In some embodiments, beacon messages include a beacon identifier, and messages that do not include the identifier of the paired beacon are ignored.

[0087] In some embodiments, the current message is determined to be authentic only if (i) the current message is authenticated by a particular key and (ii) a cryptographic commitment to use that key was received in a previously-received authentic message from the beacon device. It should be noted that authentication of the current message may not be performed immediately on receipt of the current message. In particular, the authentication of the current message may make use of information received in future messages from the beacon. For example, the cryptographic commitment to use a particular key may take the form of a hash value of that key, sent in a previously-received authentic message. The current message may include a message authentication code generated using the key. However, the receiver does not yet have the key itself— just a hash value serving as a cryptographic commitment to use the key— and thus cannot yet authenticate the current message. A beacon message in a subsequent epoch, however, may release the key itself. Once the key itself is released, the receiver device can confirm that this is the key the beacon committed to use and that this key was indeed used to generate the message

authentication code of the current message.

[0088] Even though a received beacon message may not be immediately authenticatable (pending release of an authentication key) a time limit may be imposed for authentication of a beacon message. In particular, beacon messages may have a predetermined authentication window. For example, an authentication window for a beacon message received during a particular epoch may extend to the end of the subsequent epoch. If a received beacon message has not been authenticated by the end of the authentication window, it may be determined (in step 612) that the message is not authentic.

[0089] If the received message is determined to be authentic, that determination is recorded in step 616. In some embodiments, beacon messages that are not authentic messages are discarded (step 614). In other embodiments, particularly if a beacon message includes an identifier of the paired beacon but cannot be authenticated, the failure to authenticate may be logged (or an alert may be issued) to indicate a potential security threat.

[0090] In an exemplary embodiment, as illustrated in FIG. 7, an alert is issued if the receiver device does not receive a authentic beacon message from a paired beacon during at least one predetermined epoch. Such a failure to receive an authentic beacon message during an epoch may indicate loss of proximity of the receiver device to the beacon, which in turn may be an indicator of theft or other unauthorized removal of the receiver device.

[0091] In step 702, which may extend over several epochs, a receiver device receives and authenticates prior messages from a beacon device. At least one of the previously-received authenticated messages includes a cryptographic commitment to use a particular key during a particular epoch (referred to here as epoch T). In some embodiments, a cryptographic commitment in one epoch implicitly indicates a commitment to use a particular key in the subsequent epoch. In other embodiments, a message may explicitly identify the epoch during which the key will be used.

[0092] In step 704, during epoch T, the receiver device receives one or more beacon messages that include respective message authentication codes. After epoch T has ended, during an authentication window for epoch T (which may be epoch T+1), the receiver device receives one or more additional beacon messages. Using information received during step 704, the receiver device attempts in step 708 to authenticate the messages received during epoch T. In particular, if one or more of the messages received during step 704 identifies a key, the receiver device operates to determine whether that is the key that the beacon committed to using during epoch T. If so, the receiver device determines whether any message received during epoch T is authenticated by that key (e.g., whether that key was used to generate a message authentication code included with the message).

[0093] After the authentication window ends for epoch T, if no message received in epoch T has been authenticated, the receiver device in step 710 may take various actions such as issuing an alert (e.g. a visible, auditory, radio-frequency, or other alert), logging the failed authentication, or fully or partially disabling equipment to which the receiver is affixed.

[0094] For ease of description, the foregoing embodiments have primarily been described as using a hash function as a cryptographic commitment scheme. For example, to commit to using key K during epoch T, a beacon may release the hash value H[K] during a prior epoch. However, other cryptographic commitment schemes may alternatively be used. For example, in an alternative cryptographic commitment scheme, a beacon may commit to using a particular authentication key by releasing a cryptographic transformation of the key such as an encrypted version of the authentication key; after the relevant epoch, the decrypted authentication key may be released along with the appropriate decryption key.

[0095] Embodiments of systems and methods described herein may be particularly useful in cases where beacon devices are in a substantially fixed position (e.g. mounted to walls or otherwise serving as part of a fixed security system) while receiver devices are part of or affixed to mobile equipment. However, the embodiments described herein may also be implemented by providing mobile equipment with beacon functionality and using receiver devices in substantially fixed positions.

[0096] While the embodiments described herein are primarily described using examples in which a receiver is paired to a single beacon device, it should be understood that in some embodiments, a receiver may be paired to a plurality of beacon devices. In different embodiments, different actions may be taken in response to failure to receive a message from one or more of the beacons. For example, in some embodiments, an alert may be issued if the receiver fails to receive an authentic message from any one of the paired beacons during a particular epoch. In other embodiments, an alert may be issued only if the receiver fails to receive an authentic message from all of the paired beacons during a particular epoch.

Alternative Embodiments.

[0097] In one exemplary method, a receiver receives a series of beacon messages, each beacon message including a candidate key, a candidate message authentication code (MAC), and a candidate hash value. The series of beacon messages includes at least a first beacon message and a subsequent second beacon message. The receiver determines whether the second message is from an authentic beacon by a method comprising (1) generating a calculated MAC for the candidate hash value in the first message using the candidate key of the second message; and (2) comparing the calculated MAC with the candidate MAC of the first message. In some such embodiments, the series of beacon messages further includes a third beacon message. In that case, the method further includes determining whether the third message is from an authentic beacon by a method comprising (1) generating a calculated hash value by applying a predetermined hash function to the candidate key of the third message and (2) comparing the calculated hash value with the candidate hash value of the first message.

[0098] In one exemplary method, a receiver receives (i) a first beacon message comprising a candidate hash value, (ii) a subsequent second beacon message comprising a message payload and a candidate message authentication code (MAC), and (iii) a subsequent third beacon message comprising a candidate key. The receiver determines whether the third beacon message is from an authentic beacon by a method comprising (1) determining whether the candidate key is a valid key for the generation of the candidate MAC on the message payload of the second message; and (2) determining whether the candidate hash value of the first message is a valid hash of the candidate key. The message payload of the second beacon may comprise a second candidate hash value and/or an auxiliary message payload.

[0099] In one exemplary method, a device equipped with a receiver receives (i) a first beacon message comprising a candidate hash value and (ii) a subsequent second beacon message comprising a message payload and a candidate message authentication code (MAC). Continued operation of the device is permitted only upon timely receipt of an authentic subsequent third beacon message comprising a candidate key. A determination is made of whether the third message is from an authentic beacon by a method comprising (1) determining whether the candidate key is a valid key for the generation of the candidate MAC on the message payload of the second message; and (2) determining whether the candidate hash value of the first message is a valid hash of the candidate key.

[0100] In one exemplary method, a receiver receives a series of beacon messages, each beacon message including a candidate key, a candidate message authentication code (MAC), and a candidate hash value. The series of beacon messages includes at least a first beacon message, a subsequent second beacon message, and a subsequent third beacon message. The receiver determines whether the third beacon message is from an authentic beacon by a method such as the following. The receiver generates a calculated MAC for the candidate hash value in the second beacon message using the candidate key of the third message and compares the calculated MAC with the candidate MAC of the second message. The receiver also generates a calculated hash value by applying a predetermined hash function to the candidate key of the third message and compares the calculated hash value with the candidate hash value of the first message. In some such embodiments, a determination is made that the third beacon message is from an authentic beacon only if (1) the calculated MAC is equal to the candidate MAC of the second message; and (2) the calculated hash value is equal to the candidate hash value of the first message.

[0101] In an exemplary embodiment of a beacon device, the beacon device includes a storage medium, a clock module, and at least a first key generation module. The first key generation module is configured to generate temporal identifiers for the beacon, based at least in part on a private key value and clock values. The beacon device further includes a hash function module that is configured to generate hash values based on temporal identifiers. The beacon device further includes a message authentication code module. The message authentication code module is configured to generate MAC values under a key for a particular epoch based on a hash of a key for an epoch subsequent to the particular epoch. The beacon further includes an emission generation module, configured to generate at least one emission segment, and an RF transmitter. The private key value may be stored in the storage medium. The emission generation module may be configured to generate Eddystone-compatible emissions.

Exemplary Network Architecture.

[0102] Exemplary embodiments disclosed herein are implemented using one or more wired and/or wireless network nodes, such as a wireless transmit/receive unit (WTRU) or other network entity.

[0103] FIG. 8 is a system diagram of an exemplary WTRU 102, which may be employed as a Receiver in embodiments described herein. As shown in FIG. 8, the WTRU 102 may include a processor 118, a communication interface 119 including a transceiver 120, a transmit/receive element 122, a

speaker/microphone 124, a keypad 126, a display/touchpad 128, a non-removable memory 130, a removable memory 132, a power source 134, a global positioning system (GPS) chipset 136, and sensors 138. It will be appreciated that the WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with an embodiment.

[0104] The processor 118 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 118 may perform signal coding, data processing, power control, input/output processing, and/or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit/receive element 122. While FIG. 8 depicts the processor 118 and the transceiver 120 as separate components, it will be appreciated that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

[0105] The transmit/receive element 122 may be configured to transmit signals to, or receive signals from, a base station over the air interface 116. For example, in one embodiment, the transmit/receive element 122 may be an antenna configured to transmit and/or receive RF signals. In another embodiment, the transmit/receive element 122 may be an emitter/detector configured to transmit and/or receive IR, UV, or visible light signals, as examples. In yet another embodiment, the transmit/receive element 122 may be configured to transmit and receive both RF and light signals. It will be appreciated that the transmit/receive element 122 may be configured to transmit and/or receive any combination of wireless signals.

[0106] In addition, although the transmit/receive element 122 is depicted in FIG. 8 as a single element, the WTRU 102 may include any number of transmit/receive elements 122. More specifically, the WTRU 102 may employ MIMO technology. Thus, in one embodiment, the WTRU 102 may include two or more transmit/receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 116.

[0107] The transceiver 120 may be configured to modulate the signals that are to be transmitted by the transmit/receive element 122 and to demodulate the signals that are received by the transmit/receive element 122. As noted above, the WTRU 102 may have multi-mode capabilities. Thus, the transceiver 120 may include multiple transceivers for enabling the WTRU 102 to communicate via multiple RATs, such as UTRA and IEEE 802.11 , as examples.

[0108] The processor 118 of the WTRU 102 may be coupled to, and may receive user input data from, the speaker/microphone 124, the keypad 126, and/or the display/touchpad 128 (e.g., a liquid crystal display (LCD) display unit or organic light-emitting diode (OLED) display unit). The processor 118 may also output user data to the speaker/microphone 124, the keypad 126, and/or the display/touchpad 128. In addition, the processor 118 may access information from, and store data in, any type of suitable memory, such as the non-removable memory 130 and/or the removable memory 132. The non-removable memory 130 may include random-access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, and the like. In other embodiments, the processor 118 may access information from, and store data in, memory that is not physically located on the WTRU 102, such as on a server or a home computer (not shown).

[0109] The processor 118 may receive power from the power source 134, and may be configured to distribute and/or control the power to the other components in the WTRU 102. The power source 134 may be any suitable device for powering the WTRU 102. As examples, the power source 134 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.

[0110] The processor 118 may also be coupled to the GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to, or in lieu of, the information from the GPS chipset 136, the WTRU 102 may receive location information over the air interface 116 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 102 may acquire location information by way of any suitable location-determination method while remaining consistent with an embodiment.

[0111] The processor 118 may further be coupled to other peripherals 138, which may include one or more software and/or hardware modules that provide additional features, functionality and/or wired or wireless connectivity. For example, the peripherals 138 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.

[0112] FIG. 9 depicts an exemplary network entity 190 that may be used in embodiments of the present disclosure. As depicted in FIG. 9, network entity 190 includes a communication interface 192, a processor 194, and non-transitory data storage 196, all of which are communicatively linked by a bus, network, or other communication path 198.

[0113] Communication interface 192 may include one or more wired communication interfaces and/or one or more wireless-communication interfaces. With respect to wired communication, communication interface 192 may include one or more interfaces such as Ethernet interfaces, as an example. With respect to wireless communication, communication interface 192 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 192 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). Thus, communication interface 192 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.

[0114] Processor 194 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.

[0115] Data storage 196 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 196 contains program instructions 197 executable by processor 194 for carrying out various combinations of the various network-entity functions described herein.

[0116] Although features and elements are described above in particular combinations, one of ordinary skill in the art will appreciate that each feature or element can be used alone or in any combination with the other features and elements. In addition, the methods described herein may be implemented in a computer program, software, or firmware incorporated in a computer-readable medium for execution by a computer or processor. Examples of computer-readable storage media include, but are not limited to, a read only memory (ROM), a random access memory (RAM), a 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.

Claims

CLAIMS What is Claimed:

1. A method of monitoring proximity of a receiver to a beacon device, the method comprising:

during an initial epoch, receiving by the receiver at least a first message from the beacon device; based on proximity of the receiver to the beacon device, stipulating that the first message is authentic;

for each of a plurality of respective predetermined epochs subsequent to the initial epoch:

determining whether the receiver has received, during the respective epoch, a subsequent authentic message from the beacon device, wherein a subsequent message is determined to be authentic only if (i) the subsequent message is authenticated by a selected key, and (ii) a cryptographic commitment to use the selected key was provided in a previously-received authentic message from the beacon device; and

issuing an alert in response to a determination that no authentic message was received from the beacon device during the respective epoch.

2. The method of claim 1 , further comprising:

receiving the selected key from the beacon device after the respective epoch; and

validating the selected key under the cryptographic commitment.

3. The method of claim 1 , wherein the cryptographic commitment to use the selected key comprises a hash value of the selected key under a predetermined hash function.

4. The method of claim 3, wherein a determination of whether a cryptographic commitment to use the selected key was provided in the previously-received authentic message is performed by a method comprising:

after the respective epoch, receiving a candidate key;

applying the predetermined hash function to the candidate key to generate a calculated hash value; and

determining whether the calculated hash value was provided in the previously-received authentic message.

5. The method of claim 1 , wherein a determination of whether the subsequent message is authenticated by the selected key is performed by a method comprising:

after the respective epoch, receiving a candidate key; validating that the cryptographic commitment to use the selected key was a cryptographic commitment to use the candidate key;

generating a calculated message authentication code from the subsequent message using the candidate key; and

determining whether the calculated message authentication code was provided in the subsequent message.

6. The method of claim 1 , wherein the cryptographic commitment to use the selected key comprises a predetermined cryptographic transformation of the selected key.

7. The method of claim 1 , wherein the stipulation that the first message is authentic is made without use of an authenticated channel between the receiver and the beacon device.

8. The method of claim 1 , wherein the subsequent authentic message includes a cryptographic

commitment to use a second selected key in an epoch after the respective epoch.

9. The method of claim 1 , further comprising, in response to the determination that no authentic message was received from the beacon device during the respective epoch, at least partially disabling equipment to which the receiver is affixed.

10. A method of authenticating a current message received during a current epoch of a plurality of

predetermined epochs, the method comprising:

receiving a prior message before the current epoch, wherein the prior message includes a cryptographic commitment to use a selected key;

receiving the current message during the current epoch, wherein the current message includes a current message body and a current message authentication code;

receiving a subsequent message after the current epoch, wherein the subsequent message includes a subsequent key; and

determining that the current message is authentic only in response to a determination that (i) the prior message is authentic, (ii) the current message authentication code is valid under the subsequent key, and (iii) the cryptographic commitment was a commitment to use the subsequent key.

11. The method of claim 10, wherein a determination of whether the message authentication code is valid under the subsequent key is performed by a method comprising:

generating a calculated message authentication code from the subsequent message using the subsequent key; and determining whether the calculated message authentication code is equal to the current message authentication code.

12. The method of claim 10, wherein the cryptographic commitment to use the selected key comprises a hash value of the selected key under a predetermined hash function.

13. The method of claim 10, wherein the method is performed for at least one current message in each of a plurality of predetermined epochs.

14. The method of claim 10, wherein the prior message is determined to be authentic based on proximity of a sender of the prior message to a receiver of the prior message.

15. The method of claim 10, wherein the current message body includes a cryptographic commitment to use a second selected key in an epoch after the current epoch.