Patent Description:
Document <CIT> discloses systems and methods for protecting identity in an authenticated data transmission.

This summary is provided to introduce simplified concepts of a three-party cryptographic handshake protocol. The simplified concepts are further described below in the Detailed Description. This summary is not intended to identify essential features of the claimed subject matter, nor is it intended for use in determining the scope of the claimed subject matter.

In aspects, methods, devices, systems, and means for a three-party cryptographic handshake protocol in a wireless network are described in which a sighter receives, from a beacon, a packet including an end-to-end encrypted ephemeral identifier (E2EE-EID). The sighter generates a message for an owner, selects a private key, and computes an exchanged key using the private key and the E2EE-EID. The sighter extracts a common symmetric key from the exchanged key, encrypts the message using the common symmetric key, and transmits the encrypted message to the owner.

In aspects, methods, devices, systems, and means for a three-party cryptographic handshake protocol in a wireless network are described in which a sighter receives, from a beacon, a packet including an exponentiation of a random value and a proxy value and generates an end-to-end encrypted ephemeral identifier (E2EE-EID) from the exponentiation of the random value and the proxy value. The sighter generates a message for an owner, selects a private key, and computes an exchanged key using the private key and the E2EE-EID. The sighter extracts a common symmetric key from the exchanged key, encrypts the message using the common symmetric key, and transmits the encrypted message to the owner.

In aspects, methods, devices, systems, and means for a three-party cryptographic handshake protocol in a wireless network are described in which a beacon determines a common key that is shared between the beacon and an owner. The beacon generates an end-to-end encrypted ephemeral identifier (E2EE-EID) using the common key and a time value. The beacon generates a beacon packet including the E2EE-EID and transmits the beacon packet, the transmitted beacon packet being usable by a sighter receiving the beacon packet to transmit a secure message to the owner.

In aspects, methods, devices, systems, and means for a three-party cryptographic handshake protocol in a wireless network are described in which a beacon generates an exponentiation of a random value that is shared between the beacon and an owner and stores the random value and the exponentiation of the random value. The beacon generates a multiplicative inverse of the random value and stores the multiplicative inverse of the random value. The beacon generates a proxy value using the stored value of the multiplicative inverse and a time value and generates a beacon packet including the exponentiation of the random value and the proxy value. The beacon transmits the beacon packet, the transmitted beacon packet being effective to cause a sighter receiving the beacon packet to generate an end-to-end encrypted ephemeral identifier (E2EE-EID) that is usable to transmit a secure message to the owner.

While features and concepts of the described systems and methods for a three-party cryptographic handshake protocol can be implemented in any number of different environments, systems, devices, and/or various configurations, embodiments of a three-party cryptographic handshake protocol are described in the context of the following example devices, systems, and configurations.

Embodiments of a three-party cryptographic handshake protocol are described with reference to the following drawings. The same numbers are used throughout the drawings to reference like features and components:.

Low-power wireless beacons, such as Bluetooth Low Energy (Bluetooth LE, BLE) beacons, transmit information in beacon packets (e.g., advertisement packets). A beacon may transmit broadcast information that is directly identifiable (e.g., unencrypted data) or broadcast an identifier that changes every few minutes, an ephemeral identifier (ephemeral ID, EID). The ephemeral identifier can be resolved to useful information by an owner that shares a key (the Ephemeral Identity Key, or EIK) with the individual beacon. Although the following discussion frequently refers to BLE, BLE is an example wireless technology that is discussed for simplicity, but the ephemeral identifiers discussed herein may also be applied to another wireless technology (e.g., Ultra Wideband (UWB), Wireless Local Area Network (WLAN), NFC, a personal area network (PAN), IEEE <NUM>. <NUM>, ZigBee, Thread, or the like) in a similar manner.

A beacon system using ephemeral identifiers, such as the Eddystone™ open beacon format, is designed to give developers control over which clients can make use of their beacon signals. By using a pre-agreed pseudorandom function family (PRF) to share state between a beacon and an owner, the beacon can enable a sighter with an algorithmic method to secure a channel to the owner without knowing who the owner is or without having access to the owner. By enabling the sighter to be sure that the channel to the correct owner, that shared a key with the beacon, is secure, the owner is able to decrypt and check the authenticity of a message received from the sighter. A resolver that resolves and finds the owner of the beacon cannot access the content of the message sent by the sighter to the owner.

<FIG> illustrates an example environment <NUM> in which various embodiments of a three-party cryptographic handshake protocol can be implemented. The environment <NUM> includes a beacon <NUM>, a sighter <NUM>, a resolver <NUM>, and an owner <NUM>. The beacon <NUM> is a device, such as a BLE beacon, a headset, or the like that periodically broadcasts (e.g., transmits) beacon packets, as shown at <NUM>. The sighter (or observer) <NUM> is a device, such as a smartphone, that can receive the beacon packets and forward the received packets to a resolver service, as shown at <NUM>. For example, the sighter <NUM> forwards the received packets to a resolver service <NUM> via the Internet <NUM>. In this example, the Internet <NUM> represents any combination of wired and/or wireless, local and/or wide area networks that interconnect the sighter <NUM>, the resolver <NUM>, and/or the owner <NUM>. The resolver <NUM>, such as a cloud-based resolver service (resolution service) compares received EIDs against hash values of shared keys and associated owners to determine the correct owner and forward the received packet to the correct owner <NUM>, as shown at <NUM>. Alternatively or additionally, the owner <NUM> can query the resolver <NUM> for packets or messages received from sighters <NUM> for any beacons <NUM> associated with the owner <NUM>. The owner <NUM> is a device or service, such as a smartphone, computer, or cloud-based service, associated with the beacon <NUM>. The owner <NUM> may own one or more beacons <NUM> and store the shared keys for each of those beacons <NUM>.

The three-party cryptographic handshake protocol can be used with any suitable devices configured for communication as illustrated in <FIG>. The owner <NUM> can be any owner computing system. The beacon <NUM> can be any device associated with the owner computing system. A communication from the device to the owner computing system is anonymized (by hiding the identities of both the device and owner computing system) and involving a routing system (e.g., the resolver <NUM>) to resolve the anonymity into an identification of the owner computing system and device and connecting the device to the owner computing system. The sighter <NUM> can be any sighter system that is an intermediary device that receives a beacon packet from the device and sends sighting information about the sighting of the device to its owner computing system in spite of the anonymity. The sighting information is kept secure from the resolver (and any other network nodes) except the owner computing system.

The beacon <NUM> is a device that periodically transmits (broadcasts) a beacon packet (e.g., a BLE advertisement packet) that includes an ephemeral identifier (EID) that is generated from a shared key (EIK), which is shared between the beacon <NUM> and the owner <NUM>, and the time at which the EID is generated by the beacon <NUM>. The beacon <NUM> calculates a new EID at a rotation rate known to the beacon <NUM> and its owner <NUM>. The beacon <NUM> may have limited computational and power resources and broadcasts the beacon packets over a limited range. The sighter <NUM> can receive beacon packets from the beacon <NUM> and has access to a longer-range network (e.g., a Wide Area Network, WAN). The sighter <NUM> can connect to cloud-based services, such as the resolver <NUM>, over the longer-range network. This enables the sighter <NUM> to forward received beacon packets to a cloud-based resolver <NUM>. The resolver <NUM> can be a device (server) or a collection of devices that form a cloud-based service. The resolver <NUM> stores a set of owners <NUM> and associated EIDs for those owners. The resolver <NUM> compares a received EID from a beacon packet to its stored set of EIDs to determine the associated owner <NUM> for the received beacon packet. Once an owner <NUM> is identified for a received beacon packet, the resolver <NUM> can forward the beacon packet to the correct owner <NUM> of that packet.

At initialization of a beacon <NUM>, the beacon <NUM> and the owner <NUM> use an elliptic curve Diffie-Hellman key agreement protocol to exchange a key (EIK) that is shared between the beacon <NUM> and the owner <NUM>, shown at <NUM>. The shared EIK enables the resolver <NUM> to resolve, based on time, the identity of the beacon <NUM> from the EID and to direct a message from the beacon <NUM> and/or the sighter <NUM> to the owner <NUM>. The communication between the sighter <NUM> and the resolver <NUM> as well as the communication between the resolver <NUM> and the owner <NUM> are secured using Transport Layer Security (TLS). However, any communication between the beacon <NUM> and/or the sighter <NUM> and the owner <NUM> is visible to the resolver <NUM>. Adding a secure (encrypted) end-to-end communication channel from the sighter <NUM> to the owner <NUM> provides secrecy for messages from the beacon <NUM> and/or sighter <NUM> to the owner <NUM> using the resolver <NUM> as a routing element that cannot access the encrypted payload of a message between the sighter <NUM> and the owner <NUM>.

When the beacon <NUM> is paired with the owner <NUM>, the beacon <NUM> and the owner <NUM> initiate a common state and agree upon a common key (the EIK) as described above. From that common state, the beacon <NUM> and the owner <NUM> can decide on a common rotating key based on a PRF. The sighter <NUM> encrypts a message to send to the owner <NUM> using a key based on a PRF (e.g., a PRF-S key). This pairing and initiation are performed in a secure physical environment based on proximity and a lack of other near-by devices to ensure the keys are known only to the beacon <NUM> and the owner <NUM>.

At the time of a broadcast by the beacon <NUM>, the beacon <NUM> will assist the sighter <NUM> to establish a secure channel between the sighter <NUM> and the owner <NUM>, based on the coordinated PRF-S at that time. Optionally or additionally, there may be an authentication rotating-key based on a PRF shared between owner <NUM> and beacon <NUM> to privately sign (e.g., with a Message Authentication Code, MAC) the reported time with an authentication tag (e.g., an authentication tag created using a PRF tag key (PRF-T key)) that is sent from the beacon <NUM>. This authentication tag ensures that the resolver <NUM> cannot send forged messages to the owner <NUM> with no sighter <NUM> being involved. As noted above, the beacon <NUM> has its channel to the resolver <NUM> to establish its identity and its owner <NUM> and a secure channel to send a secure payload.

The beacon <NUM> assists the sighter <NUM> to establish a secure channel with the owner <NUM>. The beacon <NUM> uses an end-to-end encrypted ephemeral identifier (E2EE-EID). The E2EE-EID is represented to the resolver <NUM> for identifier resolution and identification of the owner at a time, t. Otherwise, the time, t, is available or guessed at by the owner <NUM>.

The beacon <NUM> evaluates: <MAT> with the joint key (EIK) and x(t) is in the field of exponent (field elements) that are used for exponentiation. In Elliptic Curve Cryptography (ECC), elliptic curve multiplication is used for this operation.

The beacon <NUM> computes the E2EE-EID: <MAT> and sends g(t) (the E2EE-EID) in its beacon packet. This computation uses exponentiation or in the case of ECC curve elements after curve multiplication. G is a generator agreed upon in the system to perform the elliptic curve Diffie-Hellman key exchange.

Optionally to add an authentication tag to the message sent to the owner <NUM>, the beacon <NUM> also evaluates: <MAT> that is used to authenticate the value of the reported time from the beacon <NUM>. Note that the beacon <NUM> is in a transmit-only broadcast mode so no interactive mode is possible, and the beacon <NUM> does not have a certified signature scheme. The v(t) calculation is akin to a pre-authentication to make sure that, with a relatively light-weight calculation, the owner <NUM> can verify that a message, m, is from the correct beacon <NUM>, with the resolved ID reported by the sighter <NUM>. The authentication tag is included in a different portion of a packet sent from the resolver <NUM> to the owner <NUM> than the payload of the message. The three-party cryptographic handshake protocol works without the v(t) calculation; if the resolver <NUM> can be trusted, then the resolver <NUM> can compute t.

The beacon <NUM> transmits (broadcasts) a beacon packet including: g(t), and optionally v(t), to the sighter <NUM>. Optionally, the beacon <NUM> may include data in the beacon packet, such as a status of the beacon <NUM>, a remaining battery capacity of the beacon <NUM>, a sensor reading from a sensor included in the beacon <NUM>, or the like. After receiving the beacon packet, the sighter <NUM> generates a message, m, to send to the owner <NUM> including private information that will not be readable by the resolver <NUM>. The message, m, can include the data received in the beacon packet as well as additional information included by the sighter <NUM>, such as a location where the sighter <NUM> received the beacon packet, additional sensor data from the sighter <NUM>, or the like. The sighter <NUM> chooses a private key, y(t), and computes: <MAT> that is the exchanged key, where g(t) (the E2EE-EID) is the public key that is broadcast by the beacon <NUM>. The sighter <NUM> extracts from the exchanged key a common symmetric key, k(t), for encrypting and authenticating the message the sighter <NUM> sends by using this key, k(t), to encipher the message, m, using: <MAT> that encrypts the message. The sighter <NUM> sends, to the resolver <NUM>, the sighter message that includes: t, g(t), gy(t), C(t, m), and optionally v(t).

The resolver <NUM> resolves the E2EE-EID in the message from the sighter <NUM> to find the owner <NUM>, as described above. Once the owner <NUM> is found, the resolver <NUM> forwards the sighter message (the message m) to the owner <NUM>, with the time, t, that the resolver <NUM> found to match the received E2EE-EID in the message.

Optionally, the owner <NUM> computes PRF-T(t) and matches it with v(t) to authenticate the reported time in the beacon packet. If the values of PRF-T(t) and v(t) match, the owner <NUM> computes x'(t) PRF-S(t) and g'(t) -G^{x'(t)), and the owner <NUM> compares g'(t) to the g(t) received from the sighter <NUM>. Note that if the resolver <NUM> can be trusted not to forge messages, such as the resolver <NUM> and the owner <NUM> being owned by the same organization, this validation may not be required.

If the validation of g'(t) to g(t) yields a correct validation, the owner <NUM> computes gy(t)^{x'(t)} that should be equal to the exchanged key. The owner <NUM> extracts k'(t)=k(t) from gy(t)^{x'(t)} and decrypts C(t, m) to get the message m. Note that the encryption may be optionally authenticated, such as a message plus MAC, or using a mode like Google Cloud Messaging (GCM) or Counter with CBC-MAC (CCM) that provides integrity.

As a result of using the three-party cryptographic handshake protocol, the owner <NUM> can receive secret messages from the beacon <NUM> and/or the sighter <NUM> via the resolver <NUM> and based on the broadcasting of the beacon <NUM> being received by the sighter <NUM>. The message is authenticated and decryptable only by the owner <NUM>, while the resolver <NUM> or any other node along the network between the sighter <NUM> and the owner <NUM> cannot access the content of the message. For operation of messaging using the three-party cryptographic handshake protocol, it is only assumed that the resolver <NUM> will correctly route the message, m, to the owner <NUM>. The properties for the three-party cryptographic handshake protocol are all derived from the initial sharing of keys between the beacon <NUM> and the owner <NUM>.

The beacon <NUM> may have limited computational and power resources. The calculation of g(t) = G^{x(t)} for each broadcast requires exponentiation, or in some implementations elliptic curve point multiplication, either of which can be costly when using the limited resources of the beacon <NUM>. To reduce the resources consumed at the beacon <NUM> at broadcast time, a proxy encryption can be used that allows a value with one exponent g^x to turn to another value g^y by giving a proxy y/x. The proxy in the three-party cryptographic handshake protocol is the sighter <NUM>. The proxy (the sighter <NUM>) can transform but cannot find x itself. The proxy encryption includes an initialization phase and changes in the three-party cryptographic handshake protocol at the time of the broadcast by the beacon <NUM>. Optionally, the initialization phase may be included as part of the pairing process between the beacon <NUM> and the owner <NUM>.

At initialization, a random exponentiation g^s is computed and g^s and a random value, s, are stored in the beacon <NUM>. A multiplicative inverse, <NUM>/s is computed. <NUM>/s is a multiplicative inverse in the field that is computed by computing the Extended-Greatest Common Divisor (GCD) of s and d, where d is the order of the multiplicative group in the field and where s and d are relatively prime. This algorithm for the Extended-GCD gives: A and B such that As+Bd=<NUM>, and since d is the order zero in the field, this gives As=<NUM> so A=<NUM>/s. A (the multiplicative inverse of s) is also stored in the beacon <NUM>. Executing this initialization is a relatively expensive mechanism but is run only once and, optionally, the owner <NUM> can perform these calculations for the beacon <NUM> at pairing time.

At broadcast time, the beacon <NUM> evaluates x(t) as shown in equation <NUM> above. The beacon <NUM> computes a proxy value, prox(t) where: <MAT> using scalar multiplication in the multiplicative group. The beacon transmits g^s and prox(t) in a beacon packet. When the sighter <NUM> receives the beacon packet, the sighter <NUM> exponentiates {g^s}^{prox(t)} which equals g^{x(t)}. The sighter <NUM> is the proxy for producing the exponentiation (or elliptic curve point multiplication) on behalf of the beacon <NUM> to generate the E2EE-EID. The sighter <NUM> cannot learn s, while the beacon <NUM> only performs online (e.g., post-provisioning) scalar multiplication. Then the sighter <NUM> continues the protocol as described above.

<FIG> illustrates data and control transactions between devices in accordance with aspects of the three-party cryptographic handshake protocol. Although not illustrated for the sake of illustration clarity, various acknowledgements for messages illustrated in <FIG> may be implemented to ensure reliable operations of the three-party cryptographic handshake protocol.

At <NUM>, and as described above, the beacon <NUM> is paired with the owner <NUM>. The pairing includes sharing keys for the three-party cryptographic handshake protocol.

At <NUM>, the beacon generates the E2EE-EID based on the current time. Optionally at <NUM>, the beacon <NUM> generates an authentication tag for the beacon packet.

At <NUM>, the beacon <NUM> generates a beacon packet. The beacon <NUM> includes the E2EE-EID and, optionally if generated, the authentication tag, in the beacon packet. Optionally, the beacon <NUM> may include payload data, such as sensor data, in the beacon packet. Note that based on a predetermined rotation rate for the E2EE-EIDs, the beacon <NUM> repeats the operations of <NUM>, <NUM>, and <NUM> for each successive cycle of the rotation (not illustrated in <FIG>). At <NUM>, beacon <NUM> transmits the beacon packet. The beacon <NUM> may transmit the beacon packet one or more times during each cycle of the rotation.

At <NUM>, after receiving a beacon packet from the beacon <NUM>, the sighter <NUM> generates a message to send to the owner <NUM>. Optionally, the sighter <NUM> may include additional data in the message, such as the sighter's location when the beacon packet was received. As part of generating the message, the sighter <NUM> extracts a common symmetric key, k(t), for encrypting and authenticating the message and encrypts the message. At <NUM>, the sighter sends the message to the resolver <NUM>.

At <NUM>, the resolver <NUM> resolves, based on time, the identity of the beacon <NUM> from the E2EE-EID and compares the identity to a set of owners <NUM> and associated E2EE-EIDs for those owners. If the resolver identifies the owner <NUM> for the received message, the resolver forwards, at <NUM>, the message to the owner <NUM>. At <NUM>, the owner decrypts the received message.

The ability for a sighter <NUM> to add information, such as a location of the reception of a beacon packet, can enable one or more sighters <NUM> to track a beacon <NUM>. For example, the beacon <NUM> can be a device carried by a person or attached to a vehicle. If the sighter <NUM> is also the owner <NUM>, the rate at which sighting data is available to the owner may not be of concern. If a large group of sighters <NUM> are used to crowdsource the location of the beacon <NUM> over time, policy controls on the rate and/or latency with which tracking data is made available to the owner can be implemented. For example, a policy that sets a minimum time period between receiving a beacon packet by a sighter <NUM> and transmitting a message from the sighter <NUM> to the owner <NUM> reduces the ability for real-time tracking of the beacon <NUM>. In another example, a minimum time period between receiving a message at the resolver <NUM> and forwarding the message to the owner <NUM> also reduces the ability for real-time tracking of the beacon <NUM>. Additionally or optionally, the messages from beacon sightings may be buffered in batches at the sighter <NUM> and/or resolver <NUM> with the transmission of the batches of messages being delayed reducing the possibility for real-time tracking.

Example methods <NUM>-<NUM> are described with reference to respective <FIG> in accordance with one or more embodiments of a three-party cryptographic handshake protocol. The order in which the method blocks are described are not intended to be construed as a limitation, and any number of the described method blocks can be skipped or combined in any order to implement a method or an alternate method. Generally, any of the components, modules, methods, and operations described herein can be implemented using software, firmware, hardware (e.g., fixed logic circuitry), manual processing, or any combination thereof. Some operations of the example methods may be described in the general context of executable instructions stored on computer-readable storage memory that is local and/or remote to a computer processing system, and implementations can include software applications, programs, functions, and the like. Alternatively or in addition, any of the functionality described herein can be performed, at least in part, by one or more hardware logic components, such as, and without limitation, Field-programmable Gate Arrays (FPGAs), Application-specific Integrated Circuits (ASICs), Application-specific Standard Products (ASSPs), System-on-a-chip systems (SoCs), Complex Programmable Logic Devices (CPLDs), and the like.

<FIG> illustrates example method(s) <NUM> of a three-party cryptographic handshake protocol as generally related to securely communicating a message from a sighter to an owner. At block <NUM>, a sighter (e.g., the sighter <NUM>) receives, from a beacon (e.g., the beacon <NUM>), a packet including an end-to-end encrypted ephemeral identifier (E2EE-EID).

At block <NUM>, the sighter generates a message (e.g., the message m) for the owner (e.g., the owner <NUM>). At block <NUM>, the sighter selects a private key (e.g., the private key, y(t)).

At block <NUM>, the sighter computes an exchanged key (e.g. the exchanged key, gy(tf) using the private key and the E2EE-EID. At block <NUM>, the sighter extracts, from the exchanged key, a common symmetric key (e.g., the common symmetric key, k(t)). At block <NUM>, the sighter encrypts the message using the common symmetric key, and at bock <NUM>, the sighter transmits the encrypted message to the owner.

<FIG> illustrates example method(s) <NUM> of a three-party cryptographic handshake protocol as generally related to securely communicating a message from a sighter to an owner. At block <NUM>, a sighter (e.g., the sighter <NUM>) receives, from a beacon (e.g., the beacon <NUM>), a packet including an exponentiation of a random value (e.g., the exponentiation g^s) and a proxy value (e.g., the proxy value, prox(t)). At block <NUM>, the sighter generates an end-to-end encrypted ephemeral identifier (E2EE-EID) from the exponentiation of the random value and the proxy value.

<FIG> illustrates example method(s) <NUM> of a three-party cryptographic handshake protocol as generally related to securely communicating a message from a sighter to an owner. At block <NUM>, a beacon (e.g., the beacon <NUM>) determines a common key that is shared between the beacon and the owner. At block <NUM>, the beacon generates an end-to-end encrypted ephemeral identifier (E2EE-EID) using the common key and a time value.

At block <NUM>, the beacon generates a beacon packet including the E2EE-EID. At block <NUM>, the beacon transmits the beacon packet, the beacon packet being usable by a sighter (e.g., the sighter <NUM>) to transmit a secure message to the owner.

<FIG> illustrates example method(s) <NUM> of a three-party cryptographic handshake protocol as generally related to securely communicating a message from a sighter to an owner. At block <NUM>, a beacon (e.g., the beacon <NUM>) generates an exponentiation of a random value (e.g., the exponentiation, g^s, and the random value, s) that is shared between the beacon and the owner (e.g. the owner <NUM>). At block <NUM>, the beacon stores the random value and the exponentiation of the random value.

At block <NUM>, the beacon generates a multiplicative inverse of the random value (e.g., the multiplicative inverse, A). At block <NUM>, the beacon stores the multiplicative inverse of the random value. At block <NUM>, the beacon generates a proxy value (e.g., the proxy value, prox(t)) using the stored value of the multiplicative inverse and a time value.

At block <NUM>, the beacon generates a beacon packet including the exponentiation of the random value and the proxy value. At block <NUM>, the beacon transmits the beacon packet, the transmitting being effective to cause a sighter (e.g., the sighter <NUM>) to generate an end-to-end encrypted ephemeral identifier (E2EE-EID) that is usable to transmit a secure message to the owner.

<FIG> illustrates an example network device <NUM> that can be implemented as any of the network devices in a network in accordance with one or more embodiments of a three-party cryptographic handshake protocol as described herein, such as the sighter <NUM>, the resolver <NUM>, or the owner <NUM>. The network device <NUM> can be integrated with electronic circuitry, microprocessors, memory, input output (I/O) logic control, communication interfaces and components, as well as other hardware, firmware, and/or software to implement the device in a network.

In this example, the network device <NUM> includes a low-power microprocessor <NUM> and/or a high-power microprocessor <NUM> (e.g., microcontrollers or digital signal processors) that process executable instructions. The device also includes an input-output (I/O) logic control <NUM> (e.g., to include electronic circuitry). The microprocessors can include components of an integrated circuit, programmable logic device, a logic device formed using one or more semiconductors, and other implementations in silicon and/or hardware, such as a processor and memory system implemented as a system-on-chip (SoC). Alternatively or in addition, the device can be implemented with any one or combination of software, hardware, firmware, or fixed logic circuitry that may be implemented with processing and control circuits. The low-power microprocessor <NUM> and the high-power microprocessor <NUM> can also support one or more different device functionalities of the device. For example, the high-power microprocessor <NUM> may execute computationally intensive operations, whereas the low-power microprocessor <NUM> may manage less-complex processes such as detecting a hazard or temperature from one or more sensors <NUM>. The low-power processor <NUM> may also wake or initialize the high-power processor <NUM> for computationally intensive processes.

The one or more sensors <NUM> may be included and implemented to detect various properties such as acceleration, temperature, humidity, water, supplied power, proximity, external motion, device motion, sound signals, ultrasound signals, light signals, fire, smoke, carbon monoxide, global-positioning-satellite (GPS) signals, radio-frequency (RF), other electromagnetic signals or fields, or the like. As such, the sensors <NUM> may include any one or a combination of temperature sensors, humidity sensors, hazard-related sensors, other environmental sensors, accelerometers, microphones, optical sensors up to and including cameras (e.g., charged coupled-device or video cameras), active or passive radiation sensors, GPS receivers, and radio frequency identification detectors. In implementations, the network device <NUM> may include one or more primary sensors, as well as one or more secondary sensors, such as primary sensors that sense data central to the core operation of the device (e.g., sensing a temperature in a thermostat or sensing smoke in a smoke detector), while the secondary sensors may sense other types of data (e.g., motion, light or sound), which can be used for energy-efficiency objectives or smart-operation obj ectives.

The network device <NUM> includes a memory device controller <NUM> and a memory device <NUM>, such as any type of a nonvolatile memory and/or other suitable electronic data storage device. The network device <NUM> can also include various firmware and/or software, such as an operating system <NUM> that is maintained as computer executable instructions by the memory and executed by a microprocessor. The device software may also include a messaging application <NUM> that implements embodiments of a three-party cryptographic handshake protocol. The network device <NUM> also includes a device interface <NUM> to interface with another device or peripheral component and includes an integrated data bus <NUM> that couples the various components of the wireless network device for data communication between the components. The data bus in the wireless network device may also be implemented as any one or a combination of different bus structures and/or bus architectures.

The device interface <NUM> may receive input from a user and/or provide information to the user (e.g., as a user interface), and a received input can be used to determine a setting. The device interface <NUM> may also include mechanical or virtual components that respond to a user input. For example, the user can mechanically move a sliding or rotatable component, or the motion along a touchpad may be detected, and such motions may correspond to a setting adjustment of the device. Physical and virtual movable user-interface components can allow the user to set a setting along a portion of an apparent continuum. The device interface <NUM> may also receive inputs from any number of peripherals, such as buttons, a keypad, a switch, a microphone, and an imager (e.g., a camera device).

The network device <NUM> can include network interfaces <NUM>, such as a wireless network interface for communication with other wireless network devices in a wireless network, and an external network interface for network communication, such as via the Internet. The network device <NUM> also includes wireless radio systems <NUM> for wireless communication with other wireless network devices via the wireless network interface and for multiple, different wireless communications systems. The wireless radio systems <NUM> may include Wi-Fi, Bluetooth™, BLE, Mobile Broadband, and/or point-to-point IEEE <NUM>. Each of the different radio systems can include a radio device, antenna, and chipset that is implemented for a particular wireless communications technology. The network device <NUM> also includes a power source <NUM>, such as a battery and/or to connect the device to line voltage. An AC power source may also be used to charge the battery of the device.

<FIG> illustrates an example beacon device <NUM> that can be implemented as the beacon device <NUM> in a network in accordance with one or more embodiments of a three-party cryptographic handshake protocol as described herein. The beacon device <NUM> can be integrated with electronic circuitry, microprocessors, memory, input output (I/O) logic control, communication interfaces and components, as well as other hardware, firmware, and/or software to implement the device in a network.

In this example, the beacon device <NUM> includes one or more processors <NUM> (e.g., microcontrollers or digital signal processors) that process executable instructions. The device also includes an input-output (I/O) logic control <NUM> (e.g., to include electronic circuitry). The processor(s) can include components of an integrated circuit, programmable logic device, a logic device formed using one or more semiconductors, and other implementations in silicon and/or hardware, such as a processor and memory system implemented as a system-on-chip (SoC). Alternatively or in addition, the device can be implemented with any one or combination of software, hardware, firmware, or fixed logic circuitry that may be implemented with processing and control circuits.

Optionally or additionally, one or more sensors <NUM> may be included and implemented to detect various properties such as acceleration, temperature, humidity, water, supplied power, proximity, external motion, device motion, sound signals, ultrasound signals, light signals, fire, smoke, carbon monoxide, global-positioning-satellite (GPS) signals, radio-frequency (RF), other electromagnetic signals or fields, or the like. As such, the sensors <NUM> may include any one or a combination of temperature sensors, humidity sensors, hazard-related sensors, other environmental sensors, accelerometers, microphones, optical sensors up to and including cameras (e.g., charged coupled-device or video cameras), active or passive radiation sensors, GPS receivers, and radio frequency identification detectors. In implementations, the beacon device <NUM> may include one or more primary sensors, as well as one or more secondary sensors, such as primary sensors that sense data central to the core operation of the device (e.g., sensing a temperature in a thermostat or sensing smoke in a smoke detector), while the secondary sensors may sense other types of data (e.g., motion, light or sound), which can be used for energy-efficiency objectives or smart-operation objectives.

The beacon device <NUM> includes a memory <NUM>, such as any type of a nonvolatile memory and/or other suitable electronic data storage device. The beacon device <NUM> can also include various firmware and/or software, such as an operating system <NUM> that is maintained as computer executable instructions by the memory and executed by a processor. The device software may also include a beaconing application <NUM> that implements embodiments of a three-party cryptographic handshake protocol. Optionally or additionally, the beacon device <NUM> also includes a device interface <NUM> to interface with another device or peripheral component. The beacon device <NUM> includes an integrated data bus <NUM> that couples the various components of the beacon device for data communication between the components. The data bus in the beacon device may also be implemented as any one or a combination of different bus structures and/or bus architectures.

The beacon device <NUM> can include a wireless radio system <NUM> for wireless communication. The wireless radio system <NUM> may include Wi-Fi, Bluetooth™, BLE, Mobile Broadband, and/or point-to-point IEEE <NUM>. The wireless radio system <NUM> can include a radio device, antenna, and chipset that is implemented for a particular wireless communications technology. The beacon device <NUM> also includes a power source <NUM>, such as a battery and/or to connect the device to line voltage. An AC power source may also be used to charge the battery of the device.

Claim 1:
A method (<NUM>) of securely communicating data from a beacon (<NUM>) to an owner (<NUM>) of the beacon (<NUM>), the method comprising a sighter (<NUM>):
receiving (<NUM>), from the beacon (<NUM>), a packet including an end-to-end encrypted ephemeral identifier, E2EE-EID, and the data, the E2EE-EID being generated by the beacon (<NUM>) using a time value at which the E2EE-EID is generated and a common key shared between the beacon (<NUM>) and the owner (<NUM>);
generating (<NUM>) a message for the owner (<NUM>) including the received data and the received E2EE-EID;
selecting (<NUM>) a private key;
computing (<NUM>) an exchanged key using the private key and the received E2EE-EID;
extracting (<NUM>), from the exchanged key, a common symmetric key;
encrypting (<NUM>) the message using the common symmetric key; and
sending (<NUM>), to a resolver (<NUM>), a sighter message, wherein the sighter message comprises the time value, the received E2EE-EID, the exchanged key, and the encrypted message;
the method further comprising:
identifying (<NUM>), by the resolver (<NUM>), based on the E2EE-EID in the sighter message, the owner (<NUM>) of the beacon (<NUM>); and
in response to the resolver (<NUM>) identifying the owner (<NUM>) of the beacon (<NUM>), transmitting (<NUM>), by the resolver (<NUM>), the sighter message to the owner (<NUM>).