阅读说明：本技术 三方密码握手协议 (Three-way cryptographic handshake protocol ) 是由 马塞尔·M·M·容 大卫·拉扎罗夫 于 2021-04-05 设计创作，主要内容包括：本文档描述一种无线网络中的三方密码握手协议,其中观测器从信标接收包括随机值的乘幂和代理值的分组,并且从随机值的乘幂和代理值生成端到端加密的短暂标识符(E2EE-EID)。观测器生成针对所有者的消息,选择私钥,并且使用私钥和E2EE-EID来计算交换的密钥。观测器从交换的密钥中提取公共对称密钥,使用公共对称密钥来对消息进行加密,并且将经加密的消息传送到所有者。(This document describes a three-way cryptographic handshake protocol in a wireless network, in which an observer receives a packet from a beacon that includes 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 observer generates a message for the owner, selects the private key, and computes the exchanged key using the private key and the E2 EE-EID. The observer extracts the public symmetric key from the exchanged keys, encrypts the message using the public symmetric key, and transmits the encrypted message to the owner.)

1. A method of securely communicating a message from an observer to an owner, the method comprising:

receiving a packet from the beacon including an end-to-end encrypted ephemeral identifier E2 EE-EID;

generating a message for the owner;

selecting a private key;

computing an exchanged key using the private key and the E2 EE-EID;

extracting a public symmetric key from the exchanged keys;

encrypting the message using the public symmetric key; and

transmitting the encrypted message to the owner.

2. The method of claim 1, further comprising the observer:

receiving data in the packet from the beacon; and is

Wherein generating the message for the owner comprises: the observer includes the received data in the message for the owner.

3. The method of claim 1 or claim 2, wherein generating the message for the owner comprises the observer:

including data from the observer in the message.

4. The method of claim 3, wherein the data from the observer comprises a location of the observer when the observer received the packet from the beacon.

5. The method of any of the preceding claims, further comprising the observer:

receiving an authentication tag for the packet from the beacon and in the packet; and is

Wherein generating the message for the owner comprises: the observer includes the authentication tag in the message for the owner.

6. A method of securely communicating a message from an observer to an owner, the method comprising:

receiving a packet including a power of a random value and a proxy value from a beacon;

generating an end-to-end encrypted ephemeral identifier E2EE-EID from the power of the random value and the proxy value;

generating a message for the owner;

selecting a private key;

computing an exchanged key using the private key and the E2 EE-EID;

extracting a public symmetric key from the exchanged keys;

encrypting the message using the public symmetric key; and

transmitting the encrypted message to the owner.

7. The method of claim 6, further comprising the observer:

receiving data in the packet from the beacon; and is

Wherein generating the message for the owner comprises: the observer includes the received data in the message for the owner.

8. The method of claim 6 or claim 7, wherein generating the message for the owner comprises the observer:

including data from the observer in the message.

9. The method of claim 8, wherein the data from the observer comprises a location of the observer when the observer received the packet from the beacon.

10. The method of any of claims 6 to 9, further comprising the observer:

receiving an authentication tag for the packet from the beacon and in the packet; and is

Wherein generating the message for the owner comprises: the observer includes the authentication tag in the message for the owner.

11. A method of securely communicating a message from a beacon to an owner, the method comprising the beacon:

determining a public key shared between the beacon and the owner;

generating an end-to-end encrypted ephemeral identifier E2EE-EID using the public key and a time value;

generating a beacon packet including the E2 EE-EID; and

transmitting the beacon packet, the beacon packet usable by an observer to transmit a secure message to an owner.

12. The method of claim 11, wherein generating the beacon packet comprises: the beacon includes data in the beacon packet.

13. The method of claim 12, wherein the data is data from a sensor included in the beacon.

14. The method of any of claims 11 to 13, further comprising the beacon:

generating an authentication tag for the beacon packet; and is

Wherein generating the beacon packet comprises: the beacon includes the authentication tag in the beacon packet.

15. A method of securely communicating a message from a beacon to an owner, the method comprising the beacon:

generating a power of a random value shared between the beacon and the owner;

storing the random value and a power of the random value;

generating a multiplicative inverse of the random value;

storing a multiplicative inverse of the random value;

generating a proxy value using the stored value of the multiplicative inverse and a time value;

generating a beacon packet including the proxy value and the power of the random value; and

transmitting the beacon packet, the transmitting effective to cause an observer to generate an ephemeral identifier E2EE-EID that can be used to transmit end-to-end encryption of a secure message to the owner.

16. The method of claim 15, wherein generating the beacon packet comprises: the beacon includes data in the beacon packet.

17. The method of claim 16, wherein the data is data from a sensor included in the beacon.

18. The method of any of claims 15 to 17, further comprising the beacon:

generating an authentication tag for the beacon packet; and is

Wherein generating the beacon packet comprises: the beacon includes the authentication tag in the beacon packet.

19. An electronic device, comprising:

a wireless transceiver;

a processor; and

instructions executable by the processor to configure the electronic device to perform the method of any of claims 1 to 18.

20. A computer-readable storage medium comprising instructions that in response to execution by a processor cause performance of the method recited in any one of claims 1-18.

Background

Beacon systems using ephemeral identifiers are designed to give the developer control over which clients are able to utilize their beacon signals. The ephemeral identifier and secret key shared between the beacon and the owner of the beacon enable the resolver service to determine the owner of the beacon when an observer (viewer) sends the ephemeral identifier to the resolver service. Communication between the observer and resolver of the beacon and between the resolver and the owner is secure; however, any communication between the beacon and/or observer and the owner is insecure and visible to the resolver.

Disclosure of Invention

The present disclosure is provided to introduce a simplified concept of a three-way cryptographic handshake protocol. This simplified concept is 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 instrumentalities are described for a three-way cryptographic handshake protocol in a wireless network in which an observer receives a packet from a beacon that includes an end-to-end encrypted ephemeral identifier (E2 EE-EID). The observer generates a message for the owner, selects the private key, and computes the exchanged key using the private key and the E2 EE-EID. The observer extracts the public symmetric key from the exchanged keys, uses the public symmetric key to encrypt the message, and transmits the encrypted message to the owner.

In aspects, methods, devices, systems, and instrumentalities are described for a three-way cryptographic handshake protocol in a wireless network in which an observer receives a packet from a beacon that includes a power of a random value and a proxy value and generates an end-to-end encrypted ephemeral identifier (E2EE-EID) from the power of the random value and the proxy value. The observer generates a message for the owner, selects the private key, and computes the exchanged key using the private key and the E2 EE-EID. The observer extracts the public symmetric key from the exchanged keys, uses the public symmetric key to encrypt the message, and transmits the encrypted message to the owner.

In aspects, methods, devices, systems, and instrumentalities are described for a three-way cryptographic handshake protocol in a wireless network, in which a beacon determines a public key shared between the beacon and an owner. The beacon uses the public key and the time value to generate an ephemeral identifier (E2EE-EID) encrypted end-to-end. The beacon generates a beacon packet including the E2EE-EID and transmits the beacon packet, which can be used by an observer receiving the beacon packet to transmit a secure message to the owner.

In aspects, methods, devices, systems, and instrumentalities are described for a three-way cryptographic handshake protocol in a wireless network, in which a beacon generates a power of a random value shared between the beacon and an owner and stores the random value and the power 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 the time value and generates a beacon packet that includes the proxy value and the power of the random value. The beacon transmits a beacon packet that effectively causes an observer receiving the beacon packet to generate an ephemeral identifier (E2EE-EID) that can be used to transmit end-to-end encryption of the security message to the owner.

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

Drawings

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

FIG. 1 illustrates an example environment in which various embodiments of a three-way cryptographic handshake protocol can be implemented.

FIG. 2 illustrates example data and control transactions between devices in accordance with aspects of a three-way cryptographic handshake protocol.

Fig. 3 illustrates an example method of a three-way cryptographic handshake protocol in accordance with an embodiment of the technology described herein.

Fig. 4 illustrates an example method of a three-way cryptographic handshake protocol in accordance with an embodiment of the technology described herein.

Fig. 5 illustrates an example method of a three-way cryptographic handshake protocol in accordance with an embodiment of the technology described herein.

Fig. 6 illustrates another example method of a three-way cryptographic handshake protocol in accordance with an embodiment of the technology described herein.

Fig. 7 illustrates an example network device that can be implemented in a network environment in accordance with one or more embodiments of the technology described herein.

Fig. 8 illustrates an example beacon device that can be implemented in a network environment in accordance with one or more embodiments of the technology described herein.

Detailed Description

Low power wireless beacons, such as Bluetooth Low Energy (BLE) beacons, transmit information in beacon packets (e.g., advertisement packets). The beacon may transmit broadcast information that can be directly identified (e.g., unencrypted data) or broadcast an identifier that changes every few minutes, i.e., an ephemeral identifier (ephemeral ID, EID). The ephemeral identifier can be resolved into useful information by the owner who shares a key (ephemeral identity key or EIK) with the individual beacon. Although the following discussion often refers to BLE, BLE is an example wireless technology discussed for simplicity, but the ephemeral identifiers discussed herein may also be applied in a similar manner to another wireless technology (e.g., Ultra Wideband (UWB), Wireless Local Area Network (WLAN), NFC, Personal Area Network (PAN), IEEE 802.15.4, ZigBee, Thread, etc.).

Using e.g. Eddystone^TMThe beacon system of ephemeral identifiers in the open beacon format is designed to give the developer control over which clients are able to utilize their beacon signals. By using pre-agreedTo share state between the beacon and the owner, the beacon can enable an observer with an algorithmic approach to make the channel to the owner secure without knowing who the owner is or without accessing the owner. By enabling the observer to ensure that the channel to the correct owner who shares the key with the beacon is secure, the owner can decrypt and check the authenticity of the message received from the observer. The parser that parses and finds the owner of the beacon cannot access the content of the message sent by the observer to the owner.

Example Environment

FIG. 1 illustrates an example environment 100 in which various embodiments of a three-way cryptographic handshake protocol can be implemented. Environment 100 includes a beacon 110, an observer 120, a resolver 130, and an owner 140. Beacon 110 is a device that periodically broadcasts (e.g., transmits) a beacon packet, such as a BLE beacon, headset, and the like, as shown at 102. The observer (or watcher) 120 is a device, such as a smartphone, capable of receiving beacon packets and forwarding the received packets to a resolver service, as shown at 104. For example, the observer 120 forwards the received packets to the parser service 130 via the internet 150. In this example, the internet 150 represents any combination of wired and/or wireless networks, local and/or wide area networks interconnecting the observer 120, resolver 130, and/or owner 140. A parser 130, such as a cloud-based parser service (parsing service), compares the received EID to the shared key and hash values (hash values) associated with the owner to determine the correct owner and forwards the received packet to the correct owner 140, as shown at 106. Alternatively or additionally, the owner 140 can query the parser 130 for packets or messages received from the observer 120 for any beacons 110 associated with the owner 140. The owner 140 is a device or service associated with the beacon 110, such as a smartphone, computer, or cloud-based service. The owner 140 may own one or more beacons 110 and store a shared key for each of those beacons 110.

The three-way cryptographic handshake protocol can be used with any suitable device configured for communication as illustrated in fig. 1. The owner 140 may be any owner computing system. Beacon 110 may be any device associated with an owner computing system. Communications from the device to the owner computing system are anonymous (by hiding the identity of both the device and the owner computing system) and involve a routing system (e.g., resolver 130) to resolve anonymity to the identity of the owner computing system and the device and to connect the device to the owner computing system. The observer 120 may be any observer system that is an intermediary device that receives beacon packets from devices regardless of anonymity and sends observation information regarding observations of the devices to its owner computing system. The observation information is secure to the resolver (and any other network nodes) except the owner computing system.

Beacon 110 is a device that periodically transmits (broadcasts) a beacon packet (e.g., a BLE advertisement packet) that includes an Ephemeral Identifier (EID) generated from a shared secret key (EIK) shared between beacon 110 and owner 140 and the time at which the EID was generated by beacon 110. Beacon 110 calculates the new EID at a slew rate known to beacon 110 and its owner 140. The beacon 110 may have limited computational and power resources and broadcast a beacon packet over a limited range. The observer 120 can receive beacon packets from the beacon 110 and can access a remote network (e.g., a wide area network, WAN). The observer 120 can connect to a cloud-based service, such as a resolver 130, over a remote network. This enables the observer 120 to forward the received beacon packets to the cloud-based parser 130. Resolver 130 may be a device (server) or a collection of devices that form a cloud-based service. Resolver 130 stores owners 140 and associated sets of EIDs for those owners. Parser 130 compares the received EID from the beacon packet to its stored EID set to determine the associated owner 140 of the received beacon packet. Once the owner 140 is identified for the received beacon packet, the resolver 130 can forward the beacon packet to the correct owner 140 of the packet.

Upon initialization of the beacon 110, the beacon 110 and the owner 140 exchange a secret key (EIK) shared between the beacon 110 and the owner 140 using an elliptic curve Diffie-Hellman key agreement protocol, as shown at 108. The shared EIK enables resolver 130 to resolve the identity of beacon 110 from the EID based on time and direct messages from beacon 110 and/or observer 120 to owner 140. Communication between the observer 120 and the parser 130 and communication between the parser 130 and the owner 140 are guaranteed using Transport Layer Security (TLS). However, any communications between the beacon 110 and/or observer 120 and the owner 140 are visible to the resolver 130. Adding a secure (encrypted) end-to-end communication channel from the observer 120 to the owner 140 provides privacy for messages from the beacon 110 and/or observer 120 to the owner 140 using the parser 130 as a routing element that cannot access the encrypted payload of messages between the observer 120 and the owner 140.

Three-way cryptographic handshake protocol

When beacon 110 pairs with owner 140, beacon 110 and owner 140 initiate a common status and agree on a public key (EIK) as described above. From this common state, the beacon 110 and the owner 140 can decide on a common rotation key based on the PRF. The observer 120 uses a PRF-based key (e.g., a PRF-S key) to encrypt messages to be sent to the owner 140. This pairing and initiation is performed in a secure physical environment based on proximity and the absence of other nearby devices to ensure that only the beacon 110 and owner 140 know the key.

Upon broadcast by the beacon 110, the beacon 110 will assist the observer 120 in establishing a secure channel between the observer 120 and the owner 140 based on the PRF-S coordinated at that time. Optionally or additionally, there may be an authentication rotation key based on the PRF shared between the owner 140 and the beacon 110 to privately sign (e.g., with a message authentication code, MAC) the time with an authentication tag transmitted from the beacon 110 (e.g., an authentication tag created using a PRF tag key (PRF-T key)). This authentication tag ensures that parser 130 cannot send forged messages to owner 140 without involving observer 120. As noted above, beacon 110 has its channel to resolver 130 for establishing its identity and its owner 140 and a secure channel for sending a secure payload.

The beacon 110 assists the observer 120 in establishing a secure channel with the owner 140. The beacon 110 uses an ephemeral identifier (E2EE-EID) encrypted end-to-end. E2EE-EID is represented to parser 130 for identifier parsing and owner identification at time t. Otherwise, time t may be obtained or guessed by owner 140.

The beacon 110 evaluates:

x(t)＝PRF-S(t) (1)

where the joint key (EIK) and x (t) are located in fields (field elements) for exponentiation. In Elliptic Curve Cryptography (ECC), elliptic curve multiplication is used for this operation.

Beacon 110 calculates E2 EE-EID:

g(t)＝G^{x(t)} (2)

and transmits g (t) (E2EE-EID) in its beacon packet. This calculation uses exponentiation or, in the case of ECC, curve elements after curve multiplication. G is a generator that performs elliptic curve Diffie-Hellman key exchanges agreed upon in the system.

Optionally to add an authentication tag to the message sent to the owner 140, the beacon 110 also evaluates:

v(t)＝PRF-T(t) (3)

which is used to authenticate the value of the reporting time from the beacon 110. Note that the beacon 110 is in a transmit-only broadcast mode, so an interaction mode is not possible, and the beacon 110 does not have an authenticated signature scheme. v (t) calculation similar to pre-authentication to ensure that with a relatively light weight calculation, the owner 140 can verify that the message m is from the correct beacon 110, with the resolved ID reported by the observer 120. The authentication tag is included in a different part of the packet sent from parser 130 to owner 140 than the payload of the message. The three-way cryptographic handshake protocol works without v (t) computation; if resolver 130 can be trusted, resolver 130 can calculate t.

The beacon 110 transmits (broadcasts) a beacon packet to the observer 120 that includes g (t) and optionally v (t). Optionally, the beacon 110 may include data in the beacon packet, such as the status of the beacon 110, the remaining battery capacity of the beacon 110, sensor readings from sensors included in the beacon 110, and the like. Upon receiving the beacon packet, the observer 120 generates a message m to be sent to the owner 140, including private information that the parser 130 will not be able to read. The message m may include the data received in the beacon packet as well as additional information included by the observer 120, such as the location at which the observer 120 received the beacon packet, additional sensor data from the observer 120, and so forth. The observer 120 selects the private key y (t), and computes:

gy(t)＝g(t)^{y(t)} (4)

i.e., the exchanged key, where g (t) (E2EE-EID) is the public key broadcast by beacon 110. The observer 120 extracts the public symmetric key k (t) from the exchanged keys for encrypting and authenticating messages sent by the observer 120 by using this key k (t) to cryptographically decrypt the message m using the following items that encrypt the message:

C(t，m)＝E(k(t)，m) (5)

the observer 120 sends an observer message to the parser 130 that includes: t, g (t), gy (t), C (t, m) and optionally v (t).

As described above, the parser 130 parses the E2EE-EID in the message from the observer 120 to find the owner 140. Once owner 140 is found, resolver 130 forwards the observer message (message m) to owner 140 along with time t at which resolver 130 finds a match with E2EE-EID received in the message.

Optionally, the owner 140 calculates PRF-t (t) and matches it with v (t) to authenticate the reporting time in the beacon packet. If the values of PRF-t (t) and v (t) match, the owner 140 calculates x '(t) ═ PRF-s (t) and G' (t) ═ G ^ { x '(t) }, and the owner 140 compares G' (t) with G (t) received from the observer 120. Note that this validation may not be required if resolver 130 can be trusted not to forge the message, such as if resolver 130 and owner 140 were owned by the same organization.

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

As a result of using the three-way cryptographic handshake protocol, the owner 140 can receive the secret message from the beacon 110 and/or the observer 120 via the resolver 130 and based on the broadcast of the beacon 110 being received by the observer 120. The message is only authenticated by the owner 140 and can only be decrypted by the owner 140, while the parser 130 or any other node along the network between the observer 120 and the owner 140 does not have access to the content of the message. For messaging operations using a three-way cryptographic handshake protocol, it is only assumed that parser 130 will correctly route message m to owner 140. The nature of the three-way cryptographic handshake protocol all results from the initial sharing of the key between the beacon 110 and the owner 140.

Proxy encryption

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

At initialization, the random power g ^ s is calculated and stored in the beacon 110 together with the random value s. And calculating the multiplication inverse element 1/s. 1/s is the inverse of the multiplication in the field calculated by calculating 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 extended GCD gives: a and B make As + Bd 1, and since d is the zero order in the field, this gives As 1, so a 1/s. A (the multiplicative inverse of s) is also stored in the beacon 110. Performing this initialization is a relatively expensive mechanism but runs only once, and optionally, the owner 140 can perform these calculations for the beacon 110 at the time of pairing.

Upon broadcast, the beacon 110 evaluates x (t) as shown in equation 1 above. The beacon 110 calculates the proxy value prox (t) using scalar multiplication in a multiplicative group, where:

prox(t)＝A*x(t) (6)

beacons transmit g ^ s and prox (t) in beacon packets. When the observer 120 receives a beacon packet, the observer 120 exponentiates { g ^ s } { prox (t)) }, which is equal to g { x (t)) }. Observer 120 is a proxy for generating an exponentiation (or elliptic curve point multiplication) on behalf of beacon 110 to generate E2 EE-EID. The observer 120 cannot learn s, and the beacon 110 only performs online (e.g., post-supply) scalar multiplication. The observer 120 then continues the protocol as described above.

FIG. 2 illustrates data and control transactions between devices in accordance with aspects of a three-way cryptographic handshake protocol. Although not illustrated for clarity of illustration, various acknowledgments to the messages illustrated in fig. 2 may be implemented to ensure reliable operation of the three-way cryptographic handshake protocol.

At 205, and as described above, the beacon 110 is paired with the owner 140. Pairing includes sharing keys for a three-way cryptographic handshake protocol.

At 210, the beacon generates an E2EE-EID based on the current time. Optionally at 215, the beacon 110 generates an authentication tag for the beacon packet.

At 220, the beacon 110 generates a beacon packet. Beacon 110 includes E2EE-EID in the beacon packet with an authentication tag (optionally, if generated). Optionally, the beacon 110 may include payload data (such as sensor data) in the beacon packet. Note that based on the predetermined rotation rate of E2EE-EID, beacon 110 repeats operations 210, 215, and 220 for each successive cycle (not shown in fig. 2) of the rotation. At 225, the beacon 110 transmits a beacon packet. The beacon 110 may transmit a beacon packet one or more times during each cycle of the rotation.

At 230, upon receiving the beacon packet from the beacon 110, the observer 120 generates a message to be sent to the owner 140. Optionally, the observer 120 may include additional data in the message, such as the observer's location when the beacon packet is received. As part of generating the message, the observer 120 extracts the public symmetric key k (t) used to encrypt and authenticate the message and encrypts the message. At 235, the observer sends a message to parser 130.

At 240, resolver 130 resolves the identity of beacon 110 from the E2EE-EID based on time and compares the identity to owner 140 and the set of associated E2 EE-EIDs for those owners. If the resolver identifies the owner 140 for the received message, the resolver forwards the message to the owner 140 at 245. At 250, the owner decrypts the received message.

Policy control

The ability for the observer 120 to add information, such as the location from which the beacon packet was received, can enable one or more observers 120 to track the beacon 110. For example, the beacon 110 may be a device carried by a person or attached to a vehicle. If the observer 120 is also the owner 140, the rate at which the owner can obtain the observation data may not matter. If a large group of observers 120 are used to crowd-source the location of the beacon 110 over time, policy control of the rate and/or latency of providing trace data to the owner may be implemented. For example, a policy that sets a minimum time period between the receipt of a beacon packet by the observer 120 and the transmission of a message from the observer 120 to the owner 140 reduces the ability to track the beacon 110 in real time. In another example, the minimum time period between receiving the message at parser 130 and forwarding the message to owner 140 also reduces the ability to track the beacon 110 in real time. Additionally or optionally, messages from beacon observations may be batch buffered at the observer 120 and/or resolver 130, where transmission of the batch of messages is delayed to reduce the likelihood of real-time tracking.

Example method

Example method 300 is described with reference to respective fig. 3-6 in accordance with one or more embodiments of a three-way cryptographic handshake protocol. The order in which the method blocks are described is 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 the method or alternative methods. In general, 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 a computer-readable storage memory local and/or remote to a computer processing system, and implementations may include software applications, programs, functions, and so on. Alternatively or additionally, any of the functionality described herein can be performed, at least in part, by one or more hardware logic components such as, but not limited to: field Programmable Gate Arrays (FPGAs), Application Specific Integrated Circuits (ASICs), Application Specific Standard Products (ASSPs), system on chip (SoCs), Complex Programmable Logic Devices (CPLDs), and the like.

Fig. 3 illustrates an example method 300 of a three-way cryptographic handshake protocol, as typically associated with securely communicating a message from an observer to an owner. At block 302, an observer (e.g., observer 120) receives a packet including an end-to-end encrypted ephemeral identifier (E2EE-EID) from a beacon (e.g., beacon 110).

At block 304, the observer generates a message (e.g., message m) for an owner (e.g., owner 140). At block 306, the observer selects a private key (e.g., private key y (t)).

At block 308, the observer calculates the exchanged key (e.g., exchanged key gy (t)) using the private key and the E2 EE-EID. At block 310, the observer extracts a public symmetric key (e.g., public symmetric key k (t)) from the exchanged keys. At block 312, the observer encrypts the message using the public symmetric key, and at block 314, the observer transmits the encrypted message to the owner.

Fig. 4 illustrates an example method 400 of a three-way cryptographic handshake protocol, as typically associated with securely communicating a message from an observer to an owner. At block 402, an observer (e.g., observer 120) receives a packet from a beacon (e.g., beacon 110) that includes a power of a random value (e.g., power g ^ s) and a proxy value (e.g., proxy value prox (t)). At block 404, the observer generates an end-to-end encrypted ephemeral identifier (E2EE-EID) from the power of the random value and the proxy value.

At block 406, the observer generates a message (e.g., message m) for an owner (e.g., owner 140). At block 408, the observer selects a private key (e.g., private key y (t)).

At block 410, the observer calculates the exchanged key (e.g., exchanged key gy (t)) using the private key and the E2 EE-EID. At block 412, the observer extracts a public symmetric key (e.g., public symmetric key k (t)) from the exchanged keys. At block 414, the observer encrypts the message using the public symmetric key, and at block 416, the observer transmits the encrypted message to the owner.

Fig. 5 illustrates an example method 500 of a three-way cryptographic handshake protocol, as typically associated with securely communicating a message from an observer to an owner. At block 502, a beacon (e.g., beacon 110) determines a public key shared between the beacon and an owner. At block 504, the beacon uses the public key and the time value to generate an end-to-end encrypted ephemeral identifier (E2 EE-EID).

At block 506, the beacon generates a beacon packet including the E2 EE-EID. At block 508, the beacon transmits a beacon packet that can be used by an observer (e.g., observer 120) to transmit a secure message to the owner.

Fig. 6 illustrates an example method 600 of a three-way cryptographic handshake protocol, as typically associated with securely communicating a message from an observer to an owner. At block 602, a beacon (e.g., beacon 110) generates a power of a random value (e.g., power g ^ s and random value s) shared between the beacon and an owner (e.g., owner 140). At block 604, the beacon stores the random value and the power of the random value.

At block 606, the beacon generates a multiplicative inverse of the random value (e.g., multiplicative inverse a). At block 608, the beacon stores a multiplicative inverse of the random value. At block 610, the beacon generates a proxy value (e.g., proxy value prox (t)) using the stored value of the multiplicative inverse and the time value.

At block 612, the beacon generates a beacon packet that includes the power of the random value and the proxy value. At block 614, the beacon transmits a beacon packet, the transmission effective to cause an observer (e.g., observer 120) to generate an ephemeral identifier (E2EE-EID) that can be used to transmit end-to-end encryption of the secure message to the owner.

Example apparatus

Fig. 7 illustrates an example network device 700, such as observer 120, resolver 130, or owner 140, that can be implemented as any of the network devices in the network in accordance with one or more embodiments of a three-way cryptographic handshake protocol as described herein. Network device 700 can be integrated with electronic circuitry, microprocessors, memory, input output (I/O) logic controls, communication interfaces and components, and other hardware, firmware, and/or software to implement the device in a network.

In this example, network device 700 includes a low power microprocessor 702 and/or a high power microprocessor 704 (e.g., a microcontroller or digital signal processor) that processes executable instructions. The device also includes an input-output (I/O) logic control 706 (e.g., to include electronic circuitry). Microprocessors may include integrated circuits, programmable logic devices, logic devices formed using one or more semiconductors, and components of other implementations in silicon and/or hardware, such as processors and memory systems (socs) implemented as system-on-a-chip. Alternatively or in addition, the apparatus can be implemented in 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 702 and the high power microprocessor 704 can also support one or more different device functionalities of the device. For example, the high power microprocessor 704 may perform computationally intensive operations, while the low power microprocessor 702 may manage less complex processes, such as detecting hazards or temperatures from one or more sensors 708. The low power processor 702 may also wake up or initialize the high power processor 704 for computationally intensive processes.

The one or more sensors 708 may be included and implemented to detect various properties, such as acceleration, temperature, humidity, water, power, proximity, external motion, device motion, acoustic signals, ultrasonic signals, optical signals, fire, smoke, carbon monoxide, Global Positioning Satellite (GPS) signals, Radio Frequency (RF), other electromagnetic signals or fields, and so forth. Thus, the sensors 708 may include any one or combination of the following: temperature sensors, humidity sensors, hazard related sensors, other environmental sensors, accelerometers, microphones, light sensors adapted to and including a camera (e.g., a charge coupled device or video camera), active or passive radiation sensors, GPS receivers, and radio frequency identification detectors. In implementations, the network device 700 may include one or more primary sensors and one or more secondary sensors, such as primary sensors that sense data centered on the core operation of the device (e.g., sensing temperature in a thermostat or sensing smoke in a smoke detector), while secondary sensors may sense other types of data (e.g., motion, light, or sound) that can be used for energy efficiency goals or smart operation goals.

Network device 700 includes a memory device controller 710 and a memory device 712, such as any type of non-volatile memory and/or other suitable electronic data storage. Network device 700 may also include various firmware and/or software, such as an operating system 714 maintained as computer-executable instructions by memory and executed by microprocessors. The device software may also include a messaging application 716 that implements an embodiment of a three-way cryptographic handshake protocol. Network device 700 also includes a device interface 718 for interfacing with another device or peripheral components, and an integrated data bus 720 that couples the various components of the wireless network device for data communication between the components. The data bus in a wireless network device may also be implemented as any one or combination of different bus structures and/or bus architectures.

The device interface 718 can receive input from a user and/or provide information to the user (e.g., as a user interface), and the received input can be used to determine settings. Device interface 718 may also include mechanical or virtual components that respond to user input. For example, a user can mechanically move a sliding or rotatable component, or a motion along a touch pad can be detected, and such motion can correspond to a setting adjustment of the device. The physical and virtual movable user interface components can allow a user to set settings along a portion of the apparent continuum. Device interface 718 may also receive input from any number of peripheral devices, such as buttons, keypads, switches, microphones, and imagers (e.g., camera devices).

Network device 700 may include a network interface 722, such as a wireless network interface for communicating with other wireless network devices in a wireless network, and an external network interface for network communications, such as via the Internet. The network device 700 also includes a wireless radio system 724 for wireless communication with other wireless network devices via a wireless network interface and for multiple different wireless communication systems. The wireless radio system 724 may include Wi-Fi, Bluetooth^TMBLE, mobile broadband, and/or point-to-point IEEE 802.15.4. Each of the different radio systems may include a radio, an antenna, and a chipset implemented for a particular wireless communication technology. The network device 700 also includes a power supply 726, such as a battery and/or to connect the device to line voltage. The AC power source may also be used to charge the battery of the device.

Fig. 8 illustrates an example beacon device 800 that can be implemented as a beacon device 110 in a network in accordance with one or more embodiments of a three-way cryptographic handshake protocol as described herein. Beacon device 800 can be integrated with electronic circuitry, microprocessors, memory, input output (I/O) logic controls, communication interfaces and components, and other hardware, firmware, and/or software to implement the device in a network.

In this example, the beacon device 800 includes one or more processors 802 (e.g., microcontrollers or digital signal processors) that process executable instructions. The device also includes input output (I/O) logic controls 804 (e.g., to include electronic circuitry). Processors may include integrated circuits, programmable logic devices, logic devices formed using one or more semiconductors, and components of other implementations in silicon and/or hardware, such as processors and memory systems implemented as systems on a 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.

One or more sensors 806 may optionally or additionally be included and implemented to detect various properties, such as acceleration, temperature, humidity, water, power supply, proximity, external motion, device motion, acoustic signals, ultrasonic signals, optical signals, fire, smoke, carbon monoxide, Global Positioning Satellite (GPS) signals, Radio Frequency (RF), other electromagnetic signals or fields, and so forth. Thus, the sensor 806 may include any one or combination of the following: temperature sensors, humidity sensors, hazard related sensors, other environmental sensors, accelerometers, microphones, light sensors adapted to and including a camera (e.g., a charge coupled device or video camera), active or passive radiation sensors, GPS receivers, and radio frequency identification detectors. In implementations, the beacon device 800 may include one or more primary sensors and one or more secondary sensors, such as primary sensors that sense data centered on the core operation of the device (e.g., sensing temperature in a thermostat or sensing smoke in a smoke detector), while secondary sensors may sense other types of data (e.g., motion, light, or sound) that can be used for energy efficiency goals or smart operation goals.

Beacon device 800 includes memory 808, such as any type of non-volatile memory and/or other suitable electronic data storage. Beacon device 800 can also include various firmware and/or software, such as an operating system 810 maintained as computer-executable instructions by memory and executed by a processor. The device software may also include a beacon application 812 that implements an embodiment of a three-way cryptographic handshake protocol. Optionally or additionally, the beacon device 800 also includes a device interface 814 for interfacing with another device or peripheral component. The beacon device 800 includes an integrated data bus 816 that couples various components of the beacon device for data communication between the components. The data bus in the beaconing device may also be implemented as any one or combination of different bus structures and/or bus architectures.

The device interface 814 can receive input from a user and/or provide information to the user (e.g., as a user interface), and the received input can be used to determine settings. Device interface 814 may also include mechanical or virtual components that respond to user input. For example, a user can mechanically move a sliding or rotatable component, or a motion along a touch pad can be detected, and such motion can correspond to a setting adjustment of the device. The physical and virtual movable user interface components can allow a user to set settings along a portion of the apparent continuum. Device interface 814 may also receive input from any number of peripheral devices, such as buttons, keypads, switches, microphones, and imagers (e.g., camera devices).

The beacon device 800 may include a wireless radio system 818 for wireless communication. The wireless radio system 818 may include Wi-Fi, Bluetooth^TMBLE, mobile broadband, and/or point-to-point IEEE 802.15.4. The wireless radio system 818 may include a radio, an antenna, and a chipset implemented for a particular wireless communication technology. Beacon device 800 also includes a power supply 820, such as a battery and/or to connect the device to line voltage. The AC power source may also be used to charge the battery of the device.

Some examples are described below:

example 1: a method of securely communicating a message from an observer to an owner, the method comprising:

receiving a packet from a beacon including an end-to-end encrypted ephemeral identifier (E2 EE-EID);

generating a message for the owner;

selecting a private key;

computing an exchanged key using the private key and the E2 EE-EID;

extracting a public symmetric key from the exchanged keys;

encrypting the message using the public symmetric key; and

transmitting the encrypted message to the owner.

Example 2: the method of example 1, further comprising the observer:

receiving data in the packet from the beacon; and is

Wherein generating the message for the owner comprises the observer including the received data in the message for the owner.

Example 3: the method of example 1 or example 2, wherein generating the message for the owner comprises the observer:

including data from the observer in the message.

Example 4: the method of example 3, wherein the data from the observer includes a location of the observer when the observer received the packet from the beacon.

Example 5: the method of any of the preceding examples, further comprising the observer:

receiving an authentication tag for the packet from the beacon and in the packet; and is

Wherein generating the message for the owner comprises the observer including the authentication tag in the message for the owner.

Example 6: a method of securely communicating a message from an observer to an owner, the method comprising:

receiving a packet including a power of a random value and a proxy value from a beacon;

generating an end-to-end encrypted ephemeral identifier (E2EE-EID) from the power of the random value and the proxy value;

generating a message for the owner;

selecting a private key;

computing an exchanged key using the private key and the E2 EE-EID;

extracting a public symmetric key from the exchanged keys;

encrypting the message using the public symmetric key; and

transmitting the encrypted message to the owner.

Example 7: the method of example 6, further comprising the observer:

receiving data in the packet from the beacon; and is

Wherein generating the message for the owner comprises the observer including the received data in the message for the owner.

Example 8: the method of example 6 or example 7, wherein generating the message for the owner comprises the observer:

including data from the observer in the message.

Example 9: the method of example 8, wherein the data from the observer includes a location of the observer when the observer received the packet from the beacon.

Example 10: the method of any of examples 6 to 9, further comprising the observer:

receiving an authentication tag for the packet from the beacon and in the packet; and is

Wherein generating the message for the owner comprises the observer including the authentication tag in the message for the owner.

Example 11: a method of securely communicating a message from a beacon to an owner, the method comprising the beacon:

determining a public key shared between the beacon and the owner;

generating an end-to-end encrypted ephemeral identifier (E2EE-EID) using the public key and a time value;

generating a beacon packet including the E2 EE-EID; and

transmitting the beacon packet, the beacon packet usable by an observer to transmit a secure message to an owner.

Example 12: the method of example 11, wherein generating the beacon packet comprises the beacon including data in the beacon packet.

Example 13: the method of example 12, wherein the data is data from a sensor included in the beacon.

Example 14: the method of any of examples 11 to 13, further comprising the beacon:

generating an authentication tag for the beacon packet; and is

Wherein generating the beacon packet comprises the beacon including the authentication tag in the beacon packet.

Example 15: a method of securely communicating a message from a beacon to an owner, the method comprising the beacon:

generating a power of a random value shared between the beacon and the owner;

storing the random value and a power of the random value;

generating a multiplicative inverse of the random value;

storing a multiplicative inverse of the random value;

generating a proxy value using the stored value of the multiplicative inverse and a time value;

generating a beacon packet including the proxy value and the power of the random value; and

transmitting the beacon packet, the transmitting effective to cause the observer to generate an ephemeral identifier (E2EE-EID) that can be used to transmit end-to-end encryption of a security message to the owner.

Example 16: the method of example 15, wherein generating the beacon packet comprises the beacon including data in the beacon packet.

Example 17: the method of example 16, wherein the data is data from a sensor included in the beacon.

Example 18: the method of any of examples 15 to 17, further comprising the beacon:

generating an authentication tag for the beacon packet; and is

Wherein generating the beacon packet comprises the beacon including the authentication tag in the beacon packet.

Example 19: an electronic device, comprising:

a wireless transceiver;

a processor; and

instructions executable by the processor to configure the electronic device to perform the method of any of claims 1 to 18.

Example 20: a computer-readable storage medium comprising instructions that, in response to execution by a processor, cause a method as recited in any of claims 1-18 to be performed

Although embodiments of three-way cryptographic handshake protocols have been described in language specific to features and/or methods, the subject of the appended claims is not necessarily limited to the specific features or methods described. Rather, the specific features and methods are disclosed as example implementations of a three-way cryptographic handshake protocol, and other equivalent features and methods are intended to be within the scope of the appended claims. In addition, various embodiments are described, and it is to be understood that each described embodiment can be implemented independently or in conjunction with one or more other described embodiments.