Confining network traffic in an internet-of-things realm

Abstract

A method is performed by a pivot device communicating with a network gateway and a plurality of sensor devices The method includes communicating with a pair of sensor devices to obtain a pair of private keys, wherein each of the sensor devices is associated with a combination of public key and private key. The method derives at least one transformation key based on the pair of private keys, and communicates to the network gateway the at least one transformation key with an indicated association with the pair of sensor devices.

Description

CONFINING NETWORK TRAFFIC IN AN INTERNET-OF -THINGS REALMTECHNICAL FIELD

[0001] The present disclosure relates to communications between sensor devices, network gateways, and application servers.BACKGROUND

[0002] Home networks can include numerous types and numbers of sensors within home boundaries and which have varying wireless network connectivity capabilities. Some home network analysis metrics which are used when choosing sensors for deployment include cost efficiency and resource optimization (e.g., price per sensor or radio interface, battery consumption, etc.), reliability, and scalability (e.g., ease of adding more sensors to a given network). However, the operational security of such deployments and their ease of user configuration are other significant analysis aspects considered when choosing a suitable home network deployment.

[0003] A typical home network deployment model may correspond to a so-called hub-and- spoke arrangement where different home sensors are connected to the same home network gateway for the next three types of traffic communications (hereafter referred to as “type-1, type 2, and type-3”): (1) inter-sensor communications (“type-1”) take place in deployments where sensors collaborate to achieve a specific job or where a given event produced by one sensor can be input to another sensor (e.g., a motion-sensor event triggering a light sensor event); (2) communications with the gateway (“type-2”) are natural since the network gateway (also "gateway") is often an administration point for various tasks (e.g., commanding the sensors for a “night” scene or a local alarm, etc.); (3) traffic with the Internet (e.g., with a network node, such as an application server) (“type-3”), via the gateway, is necessary in case of troubleshooting (sensor events being collected by the sensor provider for troubleshooting), or direct remote access to sensor, etc.

[0004] While the radio connectivity capabilities of such home sensors may be of a specific nature making it possible for the type-1 (inter-sensor communications) to bypass the gateway, the hub-and-spoke model is considered a very recurrent arrangement. Here, the sensors need to embed just a simple radio stack to attach and connect only to the home gateway, without necessarily a full IP stack. This leads to chipset cost reductions.

[0005] An important security guarantee should be provided for all produced and consumed sensor traffic (i.e., uplink - UL and downlink - DL): traffic must be exchanged over encrypted channels with the gateway. This typically implies that the gateway (hub) and the sensors (spokes) share traffic encryption keys in one or the other setup: either (1) the gateway is fully trusted to decrypt all sensor traffic regardless of its destination, and therefore each sensor maintains a minimum number of traffic encryption / decry ption keys; or (2) each sensor must share a different traffic encryption key with its pairs, with the number of keys per sensor rapidly increasing in larger deployments.

[0006] The current known solutions for hub-and-spoke deployments as described in the previous section are known to feature one or a combination of the following.

[0007] Some other deployments are directed to establishing a complete radio stack with IP capabilities for sensors. While it is often preferrable for end-point sensors to be fully capable of global reachability in many scenarios, this does not resonate with the chipset cost efficiency and / or resource optimization tenet mentioned above. There are known home network deployments where a simpler chipset and less IP capable sensors are appropriate.

[0008] Some other deployments are directed to establishing many traffic encryption keys per sensor. If the gateway must not be a type-l / -3 traffic decryption point, then each sensor should typically establish a session encryption / decryption key with each of its pairs. This not only leads to handling of many secret keys per home network deployment, but also may imply managing some sensor authentication credentials (e.g., certificates and possibly a (public key infrastructure (PKI)), which may be a cumbersome task.

[0009] Some other deployments are directed to a fully trusted gateway for all types of sensor traffic. The gateway represents a traffic decryption / encryption endpoint for the three types of traffic (type-l / -2 / -3) mentioned in the previous section. This is expected for type-2 traffic and also acceptable for type-3 traffic (especially if the sensors do not embed an IP stack). However, this means the gateway has access to cleartext data not intended to itself in case of type-1 traffic (i.e., in uplink data is first decrypted by the gateway then encrypted again for downlink, with different keys) and this may be problematic. Since the gateway is facing the Internet, it is more exposed to malicious accesses; in case it is compromised, adversaries gain access to sensors’ traffic meant to be confined at home (type-1), which potentially leads to serious privacy breaches.

[0010] Overall, these features highlight some problems in current home network deployments: either the sensors bring in (1) expensive chipsets and several encryption keys to be handled depending on the produced / consumed traffic type; OR (2) more cost effectivechipset (i.e., cheaper) but with strong trust assumptions in the home gateway, i.e., the gateway is fully trusted to access all sensor cleartext data (including clear type-1 traffic), which is against the least-privilege security principle.SUMMARY

[0011] Some embodiments disclosed herein are directed to a method by a pivot device communicating with a network gateway and a plurality of sensor devices. The method includes communicating with a pair of sensor devices to obtain a pair of private keys, wherein each of the sensor devices is associated with a combination of public key and private key. The method derives at least one transformation key based on the pair of private keys, and communicates to the network gateway the at least one transformation key with an indicated association with the pair of sensor devices.

[0012] Some other embodiments are directed to a method by a network gateway communicating with a pivot device and a plurality of sensor devices. The method includes obtaining transformation keys from the pivot device. Pairs of transformation keys are associated with different pairs of the sensor devices, and the transformation keys in each pair of transformation keys are associated with different directions of communication between the associated pair of sensor devices. The method receives a message including a first identifier of a first sensor device that is a source of the message and including a second identifier of a second sensor device that is a destination of the message. The method identifies a transformation key among a set of the transformation keys obtained from the pivot device, based on the first and second identifiers and based on the direction of communication from the first sensor device to the second sensor device. The method transforms cyphertext in the received message into transformed cyphertext using the identified transformation key and a transformation function, and sends the transformed cyphertext in another message toward the second sensor device.

[0013] Some other embodiments are directed to a method by a first sensor device communicating with a pivot device and a network gateway. The method includes storing a private key and a public key which are associated with the first sensor device. The method communicates the private key to a pivot device to derive at least one transformation key associated with at least one direction of communication between the first sensor device and a second sensor device. The method obtains first cleartext for communication from the first sensor device to the second sensor device. The method performs an encrypt function totransform the first cleartext into first cyphertext using at least the public key, and communicates the cyphertext to the second sensor device via the network gateway.

[0014] Some other related embodiments are directed to a pivot device communicating with a network gateway and a plurality of sensor devices. The pivot device includes circuitry operative to communicate with a pair of sensor devices to obtain a pair of private keys, wherein each of the sensor devices is associated with a combination of public key and private key, derive at least one transformation key based on the pair of private keys, and communicate to the network gateway the at least one transformation key with an indicated association with the pair of sensor devices.

[0015] Some other related embodiments are directed to a network gateway communicating with a pivot device and a plurality of sensor devices. The network gateway includes circuitry operative to obtain transformation keys from the pivot device. Pairs of transformation keys are associated with different pairs of the sensor devices, and the transformation keys in each pair of transformation keys are associated with different directions of communication between the associated pair of sensor devices. The circuitry is further operative to receive a message including a first identifier of a first sensor device that is a source of the message and including a second identifier of a second sensor device that is a destination of the message, and identify a transformation key among a set of the transformation keys obtained from the pivot device, based on the first and second identifiers and based on the direction of communication from the first sensor device to the second sensor device. The circuitry is further operative to transform cyphertext in the received message into transformed cyphertext using the identified transformation key and a transformation function, and send the transformed cyphertext in another message toward the second sensor device.

[0016] Some other related embodiments are directed to a first sensor device communicating with a pivot device and a network gateway. The first sensor device includes circuitry operative to store a private key and a public key which are associated with the first sensor device, and communicate the private key to a pivot device to derive at least one transformation key associated with at least one direction of communication between the first sensor device and a second sensor device. The circuitry is further operative to obtain first cleartext for communication from the first sensor device to the second sensor device. The circuitry is further operative to perform an encrypt function to transform the first cleartext into first cyphertext using at least the public key, and communicate the cyphertext to the second sensor device via the network gateway.

[0017] As will be explained in further detail below, potential advantages which may be provided by these and other embodiments may include any one or more of the following. In hub-and-spoke network deployments, secure communications of traffic are provided while reducing or minimizing assumed trust in the home gateway, relaxing requirements on sensor capabilities, and simplifying configurations. The operations may implement secure traffic confinement at home with a minimum number of secret credentials per sensor (one key-pair). The operations may eliminate the assumption of a fully trusted gateway, which can no longer (does not need to) access cleartext data corresponding to type-1 (inter-sensor) traffic. The operations may prevent adversaries who can control or access the home gateway from accessing type-1 traffic. The operations may empower the home user to control sensors interactions (i.e., type-1 traffic) with a simplified administration and without extra access control (firewall) rules at home. The operations may enable type-1 traffic troubleshooting via a pivot device the home user can control. The operations may eliminate the need for advanced configurations in home networks (e.g., no need to manage certificates / PKI (public key infrastructure)). The operations do not require availability or use of advanced sensor capabilities such as an IP stack.

[0018] Other pivot device, network gateways, and sensor devices and related methods according to embodiments will be or become apparent to one with skill in the art upon review of the following drawings and detailed description. It is intended that all such pivot device, network gateways, and sensor devices and related methods be included within this description, be within the scope of the present disclosure, and be protected by the accompanying claims. Moreover, it is intended that all embodiments disclosed herein can be implemented separately or combined in any way and / or combination.BRIEF DESCRIPTION OF THE DRAWINGS

[0019] Aspects of the present disclosure are illustrated by way of example and are not limited by the accompanying drawings. In the drawings:

[0020] Figure la illustrates a system with type-1 inter-sensor communications between sensor devices using operations by a pivot device configured in accordance with some embodiments;

[0021] Figure lb illustrates a system with type-2 communications between a sensor device and a network gateway using operations by a pivot device configured in accordance with some embodiments;

[0022] Figure 1c illustrates a system with type-3 communications between a sensor device and a network node using operations by a pivot device configured in accordance with some embodiments;

[0023] Figure 2a illustrates a flowchart of operations for type-2 traffic communications between a sensor device and a network gateway in accordance with some embodiments;

[0024] Figure 2b illustrates a flowchart of operations for type-3 traffic between a sensor device and a network node in accordance with some embodiments;

[0025] Figure 3 illustrates a flowchart of operations for type-1 traffic communications between first and second sensor devices using operations by a pivot device and a network gateway in accordance with some embodiments;

[0026] Figure 4 illustrates a flowchart of operations for type-1 traffic communications between first and second sensor devices with troubleshooting activated using operations by a pivot device and a network gateway in accordance with some embodiments;

[0027] Figure 5 illustrates a flowchart of operations by a pivot device in accordance with some embodiments;

[0028] Figure 6 illustrates a flowchart of operations by a network gateway in accordance with some embodiments;

[0029] Figure 7 illustrates a flowchart of operations by a sensor device in accordance with some embodiments; and

[0030] Figure 8 illustrates components of a computing device, which may be used as a pivot device, a sensor device, and / or a network gateway, and which can operate in accordance with some embodiments.DETAILED DESCRIPTION

[0031] Inventive concepts will now be described more fully hereinafter with reference to the accompanying drawings, in which examples of embodiments of inventive concepts are shown. Inventive concepts may, however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of various present inventive concepts to those skilled in the art. It should also be noted that these embodiments are not mutually exclusive. Components from one embodiment may be tacitly assumed to be present / used in another embodiment.

[0032] Embodiments of the present disclosure may overcome one or more of the aforementioned problems, through secure communications in home networks deployed in thehub-and-spoke model for the three types of sensor traffic with only one key -pair per sensor device (also "sensor" for brevity) as sensitive credentials to protect.

[0033] For type-1 traffic (inter-sensor traffic, identified as being the main challenge), some embodiments are directed to using an asymmetric encryption scheme and a particular cryptosystem, to provide the right properties so that the network gateway (also "gateway" for brevity) no longer has access to type-1 cleartext data. These embodiments can provide a secure type-1 traffic confinement while allowing secure traffic troubleshooting under the home user control.

[0034] For type-2 traffic (sensor-gateway traffic), some embodiments are directed to using a sensor-to-gateway encrypted channel based on the asymmetric scheme.

[0035] For type-3 traffic, some embodiments are directed to using the sensor-gateway and gateway-network node (e.g., application server) encrypted channels and which can allow the gateway to access cleartext which can be particularly helpful without assume IP-capable sensors and without introducing specific requirements on the network node (e.g., application server) itself.

[0036] Secure type-1 traffic confinement at home can be provided relying on the smallest number of keys (one key -pair per sensor), in hub-and-spoke network deployments where the gateway no longer can be fully trusted to access type-1 cleartext traffic. Also, some embodiments provide operations which enable secure type-1 traffic troubleshooting at home via a pivot device which can be under the control of a home user. The pivot device can also be used in a preliminary configuration step for the cryptosystem, for example when a new sensor device is introduced (onboarded) in the home network and is expected to be part of type-1 traffic.

[0037] Operations that can be performed by a pivot device are described below in accordance with various non-limiting embodiments. When a pivot device is deployed in a home network environment, it may include, but is not limited to, smartphone, laptop computer, tablet computer, desktop computer, etc. which can be subject to the home network user(s)’ control and therefore trusted and considered secure with a specific application (depending on the type of sensor) intended for configuration and administration tasks. Example configuration and administration tasks may include onboarding sensors in the home network by pairing each sensor with the gateway (may include exchanging the public keys between the paired sensor and the gateway), performing the keys operations, and troubleshooting operations on e.g., type-1 traffic that does not reach the application server, etc.

[0038] Potential advantages that may be provided by one or more operational embodiments of the present disclosure are now discussed by example without limitation to the scope of these and other embodiments. In hub-and-spoke network deployments, secure communications of traffic are provided while reducing or minimizing assumed trust in the home gateway, relaxing requirements on sensor capabilities, and simplifying configurations. The operations may implement secure traffic confinement at home with a minimum number of secret credentials per sensor (one key-pair). The operations may eliminate the assumption of a fully trusted gateway, which can no longer (does not need to) access cleartext data corresponding to type-1 (inter-sensor) traffic. The operations may prevent adversaries who can control or access the home gateway from accessing type-1 traffic. The operations may empower the home user to control sensors interactions (i.e., type-1 traffic) with a simplified administration and without extra access control (firewall) rules at home. The operations may enable type-1 traffic troubleshooting via a pivot device the home user can control. The operations may eliminate the need for advanced configurations in home networks (e.g., no need to manage certificates / PKI (public key infrastructure)). The operations do not require availability or use of advanced sensor capabilities such as an IP stack.

[0039] Figures la, lb, and 1c illustrate a hub-and-spoke network deployment with a network gateway 110 that serves as communication hub for routing communications between a first sensor device 120 ("sensor device 1") and a second sensor device 120 ("sensor device 2"), a pivot device 100, and a network node 130 (e.g., application server) via the Internet 140 and / or a private network.

[0040] Figure la illustrates a system with Type-1 inter-sensor communications between the first and second sensor devices 120 using operations by the pivot device 100 configured in accordance with some embodiments;

[0041] Figure lb illustrates a system with Type-2 communications between the first sensor device 120 and the network gateway 110 using operations by the pivot device 100 configured in accordance with some embodiments;

[0042] Figure 1c illustrates a system with Type-3 communications between the first sensor device 120 and the network node 130 using operations by the pivot device 100 configured in accordance with some embodiments.

[0043] The first and second sensor devices 120 may be paired with the network gateway 110 using their respective radio technologies. The first and second sensor devices 120 are not required to operate to provide or maintain an embedded IP stack. For example, one or moreof following assumptions may be generic with respect to the first and second sensor devices 120 and the network gateway 110 capabilities:Data packets generated by sensor devices 120 include an indication as to their destination, which is used to by the network gateway 110 to process the packets, such as to either consume (for type-2 traffic) or relay (switch) the packets on a downlink channel (for type-1 traffic) or on a TLS / IP (Transport Layer Security / Internet Protocol) session for type-3 traffic.The network gateway 110 has IP connectivity to the Internet 140 (necessary for type- 3 traffic and for user remote administration).

[0044] The pivot device 100 in Figures la, lb, and 1c may be configured to be controlled by the home user(s) (e.g., via a cellphone with a specific application depending on the sensor device type) and may be used for some configuration and administration tasks, which may include any one or more of:Onboarding sensor devices 120 in the home network by pairing each sensor device 120 with the network gateway 110. This operation can include exchanging the public keys between the paired sensor device 120 and the network gateway 110;Performing keys operations in accordance with one or more of the embodiments described below; andTroubleshooting operations on, e.g., type-1 traffic that does not reach the network node 130 (e.g., application server).

[0045] As explained, objectives can include providing secure communications for all type of traffic in Figures la, lb, and 1c, with reduced or minimized trust needed in the network gateway 110, and without strong assumptions for the sensor device capabilities. These objectives can be satisfied by operations where: 1) all types of traffic are encrypted; 2) type-1 traffic is accessible only by the source sensor device (producer) and the destination sensor device (consumer / recipient); 3) the network gateway 110 is not able to (is not trusted to) decrypt traffic type-1 traffic; and 4) the number of (encryption) keys per sensor is minimal.

[0046] These operations embodiments can be based on asymmetric encryption, with only one private-public key -pair per sensor device. For type-1 traffic, a proxy -re-encryption mechanism can be performed at the network gateway 110, which enables traffic-1 troubleshooting using operation of the pivot device 100.

[0047] Before describing how type-1 traffic is confined at home, operations for securing type-2 traffic and type-3 traffic are described according to the asymmetric scheme.

[0048] Figure 2a illustrates a flowchart of operations for type-2 traffic communications between a sensor device 120 and a network gateway 110 in accordance with some embodiments. Referring to Figure 2a, the source sensor device 120 encrypts 200 data traffic in the uplink (UL) using the public key of the network gateway 110 (pub key gw). The source sensor device 120 adds 202 an indication to the data header with semantics for usage by the network gateway 110. The network gateway 110 then decrypts 204 the UL traffic using its private key.

[0049] Figure 2b illustrates a flowchart of operations for type-3 traffic between a sensor device 120 and the network node 130 (e.g., application server) in accordance with some embodiments. Referring to Figure 2b, the source sensor device 120 encrypts 210 data traffic in the UL using the public key of the network gateway 110 (pub key gw). The source sensor device 120 adds 212 an indication to the data header with semantics for usage by Internet 140 (e.g., and network node 13). The network gateway 110 then decrypts 214 the UL traffic using its private key and sends it over a TLS session with the network node 130 (e.g., application server ("AppServer")).

[0050] In downlink (DL), the network gateway 110 uses the sensor device’s public key to encrypt data, which is then communicated to and decrypted by the sensor device 120 using the sensor device's private key.

[0051] Operations for providing type-1 traffic confinement are now described in accordance with some embodiments.

[0052] Embodiments can operate using asymmetric encryption in order to secure the type-1 traffic and fulfill one or more of the requirements mentioned. Algebraic constructs allow the network gateway 110 to perform a transformation on type-1 encrypted traffic without accessing the sensor device's secret keys and without revealing any type-1 cleartext.

[0053] Elements of some embodiments can include any one or more of the following.

[0054] For each sensor device 120, operations provide support for the encryption and / or decryption functions using one private-public key pair (privKey, pubKey). Secure storage of these keys can be provided. These keys are used for the encryption (in UL) and decryption (in DL) of type-1 traffic. The sensor device 120 key -pair can be generated based on known techniques, alternatives of which may include: the key-pair is embedded in the sensor device 120 during manufacturing, the key-pair is generated by the sensor device (e.g., periodically or on demand), or the key -pair is provided by the pivot device 100 when the sensor device 120 is onboarded in the network. Operations can storage and use the network gateway 110 public key in type-2 and type-3 UL traffic encryption (e.g., Figures 2a and 2b)

[0055] For the network gateway 110, operations provide support for a transformation function (transFunc) on type-1 encrypted traffic. In addition to type-1 encrypted traffic, the transformation function may take as input a transformation-key derived by the pivot device 100 as described below.

[0056] For the pivot device 100 (e.g., under the user control), operations can provide support for interacting with each sensor device 120 to onboard it in the network (e.g., no secret key is handled in this step) and to pair it with the network gateway 110. The operations share the network gateway 110 public key with each sensor device 120.

[0057] For the pivot device 100, the operations can also provide support for deriving the transformation-key to be used by the network gateway 110, given any pair of sensor devices 120 that are subject to type-1 traffic. In the cryptosystem, the transformation-key derivation takes as input the private keys (privKeys) of the sensor devices 120. A given transformationkey reveals no information on the original privKeys. Therefore, the transformation-key can be handled by untrusted parties such as the network gateway 110. Nonetheless, this key derivation can be (or is) a sensitive step in itself and, may (or should be) performed under the user control, and is performed by the pivot device 100 interacting with each sensor device 120 privately (e.g., communications with a sensor device 120 close network proximity, shielded environment).

[0058] Transfer of the transformation-keys to the network gateway 110. The chosen cryptosystem is proven to reveal no information on the original private keys for a given transformation-key. Existence of a derived transformation-key for a pair of sensor devices 120 is equivalent to having controlled that the two sensor devices 120 are allowed to interact in type-1 communications.

[0059] For the pivot device 100, the operations can also provide support for type-1 traffic troubleshooting. When neither the network node 130 (e.g., AppServer) nor the network gateway 110 have access to type-1 cleartext, it is necessary to enable the pivot device 100 (e.g., under the user control) to perform traffic troubleshooting, which is described below with regard to Figure 4.

[0060] The home user can trust the pivot device 100 to operate to (optionally) onboard sensor devices 120 in the network, perform transformation-keys derivation, and transfer the transformations-keys to the network gateway 110.

[0061] These and other operations are now further described in accordance with some nonlimiting embodiments as follows:

[0062] Each sensor device 120 in a set S of sensor devices 120 at home is associated with a key pair (privKey, pubKey). The privKey should never leave the sensor device 120, except when the pivot device 100 interacts with the sensor device 120. Each sensor device 120 is provided, by the pivot device 100, the pub_key_gw (public key of the network gateway 110), which is necessary for type-2 and / or type-3 UL traffic encryption.

[0063] For type-1 traffic, each sensor device 120 can operate to support the next functions: encrypt • K x M -> C, encryptfk, m) = c, decrypt • K x C -> M, decrypt(k, c) = m, with K, M and C sets of binary keys, cleartext and ciphertexts, respectively.

[0064] These functions are configured so that the output c (ciphertext) of the encrypt function produced by one sensor device 120 cannot be decrypted by any party, but only by the producer sensor (itself). In other words, encrypt() is almost equivalent to the following: encryption^unctionui = c, meaning that the decryption of c requires thecorresponding own private key, i.e., decrypt private_own_key, c) = m.

[0065] These properties are necessary so that the network gateway 110 cannot obtain m (type-1 cleartext traffic).

[0066] The pivot device 100 applies the following transformation-key generation function for any pair of sensors subject to type-1 communications: trans KeyGenFunc : PrivK X PrivK ->TransK , with transKeyGenFuncfprivKeyf privKey' ) = transf ormationKey2, with PrivK being the set of privKeys and TransK being the set of transformation-keys keys used by the network gateway 110 for type-1 traffic.

[0067] Note that a transformation-key is unique per pair of sensor devices 120 and per traffic direction (i.e., transf ormationKey2used to transform encrypted traffic from sensor^o sensor2is not equal to trans formationKey^ , given the pair of sensor i and sensor_2).

[0068] The network gateway 110 applies the following transformation function on type-1 encrypted traffic: transFunc : TransK x Cl -> C2, trans FuncftransformationKey2, cl) = c2, transforming a ciphertext by sensor- 1 (cl, output of encrypt() function), into a ciphertext for sensor-2 (c2), based on the transf ormationKey2key.

[0069] This transFunc is not a decryption followed by an encryption and reveals no information on the secret private keys privKeyl and privKey2 of the two sensor devices.

[0070] Table 1, below, summarizes the distribution of functions among the different entities and the stored information at each level for type-1 traffic.

[0071] Figure 3 illustrates a flowchart of operations for type-1 traffic communications between first and second sensor devices 120 using operations by the pivot device 100 and the network gateway 110 in accordance with some embodiments.

[0072] Referring to Figure 3, a message m is sent by sensor-1 to sensor-2 in accordance with elements from Table-1. Operational interaction with the pivot device 100 can occur prior to this exchange.

[0073] The pivot device 100 can perform operations to facilitate onboarding 300 of the sensor-1 and sensor-2 with the gateway 110. The onboarding operations 300 can include facilitating communications relating to pairing sensor-1 and sensor-2 to the gateway 110. The pivot device 100 separately communicates with sensor- 1 and sensor-2 that will be communicating with each other (type-1 communications) to derive 302 a transformation key for that pair of sensor-1 and sensor-2. The pivot device 100 can obtain (e.g., receive from) the private keys of each of sensor- 1 and sensor-2, and derive (generate) 302 the transformation key based on combination of the private keys, e.g., trans f ormationKey^ = transKeyGenFunc(privKeyl, privKey2). The transformation key may be derived 302 based on a function of the direction of communication between the sensor devices 120, e.g., onetransformation key derived for communications in the direction from sensor- 1 to sensor-2 and another transformation key derived for communications in the opposite direction from sensor-2 to sensor- 1. For example, the order of the private keys as an input to the transformation function can be defined based on the direction of communication, e.g., communication from sensor- 1 to sensor-2 corresponds to trans f ormationKey^ = transKeyGenFunc(privKeyl, privKey2) and communication from sensor-2 to sensor- 1 corresponds to trans f ormationKey^ = transKeyGenFunc(privKey2, privKeyl). Alternatively, the same transformation key can be used for communications in either direction between sensor-1 and sensor-2. The pivot device 100 can install 304 the transformation key into the gateway 110 for use in its communication with the sensor devices 120.

[0074] Sensor- 1 performs operations 306 which generates data or other traffic (m) for communication to sensor-2. Sensor-1 prepares 308 to send the traffic (m) by encrypting the traffic (m), e.g., using function cl=encrypt(m,pubKeyl) to output encrypted traffic cl which is sent 310 to the gateway 110 for routing (e.g., relay) to sensor-2.

[0075] Gateway 110 detects 312 the type-1 traffic from sensor-1 for routing to sensor-2, and applies 314 a transformation function based on the transformation key earlier installed 304 by the pivot device 100. The transformation key can be retrieved from local memory of the gateway 110 using the identities of the sensor- 1 and sensor-2 and, which the transformation keys are defined based on direction of communication, which direction of communication the traffic is traveling (e.g., sensor-1 to sensor-2). For example, the gateway 110 can generate further encrypted traffic c2 using the function c2 = transFunc(trans f ormationKey^, cl), and send 316 the encrypted traffic c2 to sensor-2.

[0076] Sensor-2 receives and decrypts the encrypted traffic c2 using its private key to output the unencrypted original traffic m (e.g., plaintext), e.g., using the decryption function m = decrypt(privKey2, c2).

[0077] Other embodiments which are directed to enabling traffic monitoring or troubleshooting are now described in the context of the non-limiting illustrative example of Figure 4. Figure 4 illustrates a flowchart of operations for type-1 traffic communications between sensor- 1 and sensor-2 with troubleshooting (or monitoring) activated using operations by the pivot device 100 and the network gateway 110 in accordance with some embodiments.

[0078] In order for operations to enable traffic monitoring or troubleshooting without interfering with sensor communications, activation of the type-1 traffic troubleshooting (or monitoring) implies opening access to type-1 cleartext traffic (unencrypted) to the pivot device 100 (which is considered secure since it may always be under the user’s control) for a given pair of sensors or for all sensors.

[0079] For example, the user via the pivot device 100 may send a notification to the gateway 110 (e.g., pivot device 100 and gateway 110 may be in the same IP network at home) to start mirroring type- 1 encrypted traffic.

[0080] The indication should be sent to the gateway 110 indicating how to mirror traffic, such as one or more of:- Mirror-1 : only input traffic before transFunc transformation is applied (a.k.a., pre- transFunc traffic)- Mirror-2: only transformed traffic after applying transFunc transformation (a.k.a., post-transFunc traffic)- Mirror-3 : both traffics before and after applying the transFunction. The advantage in this case is that the user is able to validate the integrity of the transformationKey(s) and of the transFunc() function itself.

[0081] The pivot device 100 receives the mirrored encrypted traffic from the gateway 110 over IP (for any of the Mirror-1 / 2 / 3 options above) and decrypts it locally.- In case Mirror-3 option is chosen, the pivot device 100 may have interacted with the sensors (sensor- 1 and sensor-2) to regenerate the transformationKey in order to use it locally on pre-transFunc traffic received from the gateway 110 and compare the outcome with the mirrored post-transFunc traffic. In case of a match, the gateway transformationKey may be considered fresh and the gateway transFunc() valid.

[0082] The user may take a decision to further send this type-1 decrypted traffic over a secure IP (TLS) channel to the network node (e.g., Application Server) 130 for further sensor troubleshooting.

[0083] With further reference to Figure 4, operations 400, 402, 404, 406 may be the same or similar to the operations 300, 302, 304, 306 earlier described for Figure 3. Type-1 traffic communicated between sensor- 1 and sensor-2 may be processed as described above for operations 308 to 318 of Figure 3.

[0084] A decision 410 is made, e.g., by user input or supervisor computer, to start type-1 traffic troubleshooting. Optional pivot device 100 interaction with each of sensor- 1 andsensor-2 to derive or re-derive the transformation key(s), e.g., trans f ormationKey^ = transKeyGenFunc(privKeyl, privKey2). The pivot device 100 signals 412 the gateway 110 to activate troubleshooting, mirror-3.

[0085] Sensor- 1 prepares 414 to send traffic m encrypted by applying an encryption algorithm to traffic m , e.g., cl = encrypt(m, pubKeyl), and sends 416 to encrypted traffic cl to gateway 110. Gateway 110 detects 418 type-1 traffic being communicated from sensor-1 to sensor-1, and sends 420 (e.g., mirrors) the encrypted traffic 1 (pre-transFunc traffic). Gateway 110 also applies 422 the transformation function to generate further encrypted traffic c2, e.g., c2 = transFunc^rans ormation / fey^, cl), and sends 424 the encrypted traffic c2 (post-transFunc traffic) to pivot device 100.

[0086] Pivot device 100 decrypts 426 cl and c2. For example, cl may be decrypted based on cl : m = decrypt(privKey 1, cl). Pivot device 100 can decide whether to send m to the network node 130, e.g., Application Server. Encrypted traffic c2 may be decrypted based on c2'=transFunc(trans ormation / <’e 2, cl). Pivot device 100 may compare c2' with c2 to determine if there is an error (e.g., debug), and may determine, if equal (e.g., c2' = c2), then trans format ionKey^ on gateway is fresh.

[0087] Gateway 110 can send 428 encrypted traffic c2 to sensor-2, which can decrypt 430 c2 to output traffic m, e.g., based on m = decrypt(privKey2, c2).

[0088] Various embodiments have been described in the context of the specific examples of Figures 3 and 4. However, these and other embodiments are not limited to those examples. Various embodiments are therefore now described more broadly with reference to the flowcharts of Figures 5 to 7.

[0089] Figure 5 illustrates a flowchart of operations by a pivot device communicating with a network gateway and a plurality of sensor devices in accordance with some embodiments.

[0090] Referring to Figure 5, the pivot device communicates 600 with a pair of sensor devices to obtain a pair of private keys, wherein each of the sensor devices is associated with a combination of public key and private key. Pivot device derives 602 at least one transformation key based on the pair of private keys, communicates 604 to the network gateway the at least one transformation key with an indicated association with the pair of sensor devices.

[0091] In some further embodiments, for each pair of sensor devices which are to communicate with each other, the device derives one transformation key of a pair of transformation keys based on the pair of private keys obtained from the pair of sensor devicesand based on one direction of communication between the pair of sensor devices, and derives the other transformation key of the pair of transformation keys based on the pair of private keys obtained from the pair of sensor devices and based on an opposite direction of communication between the pair of sensor devices. The pivot device communicates to the network gateway the pair of transformation keys with an indicated association with the pair of sensor devices.

[0092] The pivot device may store (temporarily) in a local memory of the pivot device, the private keys and the pairs of transformation keys with an indicated association with the pairs of sensor devices. The keys may be retained in the local memory only while a session is active between the pair of sensors, and then cleared from the local memory.

[0093] The pair of sensor devices can be a first sensor device associated with a first private key and a second sensor device associated with a second private key. The operation to derive the at least one transformation key can include to derive a first transformation key based on the first and second private keys and based on a first direction of communication from the first sensor device to the second sensor device, and to derive a second transformation key based on the first and second private keys and based on a second direction of communication from the second sensor device to the first sensor device. The first and second transformation keys are communicated to the network gateway with an indicated association with the first and second sensor devices, and the first and second transformation keys are shared with the first and second sensor devices. The first transformation key may be same as or different from the second transformation key.

[0094] The operation to derive the first transformation key based on the first and second private keys and based on the first direction of communication from the first sensor device to the second sensor device, can include to provide an ordered set of the first private key and the second private key as input to a key transformation function to output the first transformation key. The operation to derive the second transformation key based on the first and second private keys and based on the second direction of communication from the second sensor device to the first sensor device, can include to provide an opposite ordered set of the second private key and the first private key as input to the key transformation function to output the second transformation key, wherein the second ordered set has an opposite order of the first and second private keys relative to the first ordered set based on the opposite direction of communication.

[0095] In some further embodiments, the pivot device sends a notification to the network gateway to start relaying to the pivot device message traffic that is directed from the firstsensor device to the second sensor device and / or directed from the second sensor device to the first sensor device.

[0096] The notification may indicate that the message traffic is to be relayed to the pivot device without any transformation of cyphertext in the message traffic by a transformation function of the network gateway using the at least one transformation key. Alternatively, the notification may indicate that the message traffic is to be relayed to the pivot device after transformation of cyphertext in the message traffic by a transformation function of the network gateway using the at least one transformation key. Alternatively, the notification may indicate that two copies of the message traffic are to be relayed to the pivot device, where one copy of the message traffic is after transformation of cyphertext in the message traffic by a transformation function of the network gateway using the at least one transformation key, and the other copy of the message traffic is without any transformation of the cyphertext in the message traffic by the transformation function of the network gateway using the at least one transformation key.

[0097] In some further embodiments, the pivot device performs a decrypt function to transform cyphertext of a message in the message traffic into cleartext, and performs an encrypt function to transform the cleartext into test cyphertext using the transformation key and a transformation function. The pivot device determines whether to send information based on content of the message to a network node based on comparison of the cyphertext to the test cyphertext.

[0098] Figure 6 illustrates a flowchart of operations by a network gateway in accordance with some embodiments.

[0099] Referring to Figure 6, the network gateway obtains 600 transformation keys from the pivot device. The pairs of transformation keys are associated with different pairs of the sensor devices, and the transformation keys in each pair of transformation keys are associated with different directions of communication between the associated pair of sensor devices. The network gateway receives 602 a message including a first identifier of a first sensor device that is a source of the message and including a second identifier of a second sensor device that is a destination of the message. The network gateway identifies 604 a transformation key among a set of the transformation keys obtained from the pivot device, based on the first and second identifiers and based on the direction of communication from the first sensor device to the second sensor device. The network gateway transforms 606 cyphertext in the received message into transformed cyphertext using the identifiedtransformation key and a transformation function, and sends 608 the transformed cyphertext in another message toward the second sensor device.

[0100] The operation to identify the transformation key may include looking-up the transformation key among the set of the transformation keys using an index formed based on the first identifier of the first sensor device and the second identifier of the second sensor device ordered based on the direction of communication of the message from the first sensor device to the second sensor device.

[0101] The network gateway may store in a local memory the transformation keys each associated with a different combination of identifiers of the pair of the sensor devices and the direction of communication between the pair of the sensor devices. The transformation keys may be temporarily retained in memory while the communication session between sensor- 1 and sensor-2 is active, and then clear the transformation keys from memory.

[0102] Operations may further include to receive a notification from the pivot device to start relaying to the pivot device message traffic that is directed from the first sensor device to the second sensor device and / or directed from the second sensor device to the first sensor device.

[0103] Responsive to an indication of the notification, the operations may relay the message traffic to the pivot device without any transformation of cyphertext in the message traffic by the transformation function using the identified transformation key.

[0104] Responsive to another indication of the notification, the operations may relay the message traffic to the pivot device after transformation of cyphertext in the message traffic by the transformation function using the identified transformation key.

[0105] Responsive to another indication of the notification, the operations may relay two copies of the message traffic to the pivot device, where one copy of the message traffic is after transformation of cyphertext in the message traffic by the transformation function using the identified transformation key, and the other copy of the message traffic is without any transformation of the cyphertext in the message traffic by the transformation function using the identified transformation key.

[0106] Figure 7 illustrates a flowchart of operations by a sensor device in accordance with some embodiments.

[0107] Referring to Figure 7, a first sensor device communicates with a pivot device and a network gateway. First sensor device stores 700 a private key and a public key which are associated with the first sensor device, and communicates 702 the private key to a pivot device to derive at least one transformation key associated with at least one direction ofcommunication between the first sensor device and a second sensor device. The first sensor device obtains 704 first cleartext for communication from the first sensor device to the second sensor device. The first sensor device performs 706 an encrypt function to transform the first cleartext into first cyphertext using at least the public key, and communicates 704 the cyphertext to the second sensor device via the network gateway.

[0108] The first sensor device may operate to receive second cyphertext from the second sensor device via the network gateway, and perform a decrypt function to transform the second cyphertext into second cleartext using at least the public key.

[0109] Figure 8 illustrates components of a computing device 800, which may be used as a pivot device, a sensor device, and / or a network gateway, and which can operate in accordance with some embodiments.

[0110] Referring to Figure 8, operations of a pivot device, sensor device, and / or network gateway as described herein may be performed by components of the illustrated computing device 800. The computing device 800 includes at least one processor 810 ("processor"), at least one memory 820 ("memory") storing program code executable by the processor 810 to perform operations in accordance with one or more of the embodiments disclosed herein for a pivot device, sensor device, and / or network gateway. The computing device 800 includes a network interface 830 configured to communicate through, e.g., a radio communication interface with one or more other components of the system. The computing device 800 may include a user interface 840, such as a keyboard, display device, etc.

[0111] Further definitions and embodiments are now explained below.

[0112] In the above description of various embodiments of present inventive concepts, it is to be understood that the terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of present inventive concepts. Unless otherwise defined, all terms (including technical and scientific terms) used herein have the same meaning as commonly understood by one of ordinary skill in the art to which present inventive concepts belongs. It will be further understood that terms, such as those defined in commonly used dictionaries, should be interpreted as having a meaning that is consistent with their meaning in the context of this specification and the relevant art and will not be interpreted in an idealized or overly formal sense expressly so defined herein.

[0113] When an element is referred to as being "connected", "coupled", "responsive", or variants thereof to another element, it can be directly connected, coupled, or responsive to the other element or intervening elements may be present. In contrast, when an element is referred to as being "directly connected", "directly coupled", "directly responsive", or variantsthereof to another element, there are no intervening elements present. Like numbers refer to like elements throughout. Furthermore, "coupled", "connected", "responsive", or variants thereof as used herein may include wirelessly coupled, connected, or responsive. As used herein, the singular forms "a", "an" and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. Well-known functions or constructions may not be described in detail for brevity and / or clarity. The term "and / or" includes any and all combinations of one or more of the associated listed items.

[0114] It will be understood that although the terms first, second, third, etc. may be used herein to describe various elements / operations, these elements / operations should not be limited by these terms. These terms are only used to distinguish one element / operation from another element / operation. Thus, a first element / operation in some embodiments could be termed a second element / operation in other embodiments without departing from the teachings of present inventive concepts. The same reference numerals or the same reference designators denote the same or similar elements throughout the specification.

[0115] As used herein, the terms "comprise", "comprising", "comprises", "include", "including", "includes", "have", "has", "having", or variants thereof are open-ended, and include one or more stated features, integers, elements, steps, components or functions but does not preclude the presence or addition of one or more other features, integers, elements, steps, components, functions or groups thereof. Furthermore, as used herein, the common abbreviation "e.g.", which derives from the Latin phrase "exempli gratia," may be used to introduce or specify a general example or examples of a previously mentioned item and is not intended to be limiting of such item. The common abbreviation "i.e.", which derives from the Latin phrase "id Est," may be used to specify a particular item from a more general recitation.

[0116] Example embodiments are described herein with reference to block diagrams and / or flowchart illustrations of computer-implemented methods, apparatus (systems and / or devices) and / or computer program products. It is understood that a block of the block diagrams and / or flowchart illustrations, and combinations of blocks in the block diagrams and / or flowchart illustrations, can be implemented by computer program instructions that are performed by one or more computer circuits. These computer program instructions may be provided to a processor circuit of a general purpose computer circuit, special purpose computer circuit, and / or other programmable data processing circuit to produce a machine, such that the instructions, which execute via the processor of the computer and / or other programmable data processing apparatus, transform and control transistors, values stored inmemory locations, and other hardware components within such circuitry to implement the functions / acts specified in the block diagrams and / or flowchart block or blocks, and thereby create means (functionality) and / or structure for implementing the functions / acts specified in the block diagrams and / or flowchart block(s).

[0117] These computer program instructions may also be stored in a tangible computer- readable medium that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable medium produce an article of manufacture including instructions which implement the functions / acts specified in the block diagrams and / or flowchart block or blocks. Accordingly, embodiments of present inventive concepts may be embodied in hardware and / or in software (including firmware, resident software, micro-code, etc.) that runs on a processor such as a digital signal processor, which may collectively be referred to as "circuitry," "a module" or variants thereof.

[0118] It should also be noted that in some alternate implementations, the functions / acts noted in the blocks may occur out of the order noted in the flowcharts. For example, two blocks shown in succession may in fact be executed substantially concurrently or the blocks may sometimes be executed in the reverse order, depending upon the functionality / acts involved. Moreover, the functionality of a given block of the flowcharts and / or block diagrams may be separated into multiple blocks and / or the functionality of two or more blocks of the flowcharts and / or block diagrams may be at least partially integrated. Finally, other blocks may be added / inserted between the blocks that are illustrated, and / or blocks / operations may be omitted without departing from the scope of inventive concepts. Moreover, although some of the diagrams include arrows on communication paths to show a primary direction of communication, it is to be understood that communication may occur in the opposite direction to the depicted arrows.

[0119] Many variations and modifications can be made to the embodiments without substantially departing from the principles of the present inventive concepts. All such variations and modifications are intended to be included herein within the scope of present inventive concepts. Accordingly, the above disclosed subject matter is to be considered illustrative, and not restrictive, and the appended examples of embodiments are intended to cover all such modifications, enhancements, and other embodiments, which fall within the spirit and scope of present inventive concepts. Thus, to the maximum extent allowed by law, the scope of present inventive concepts is to be determined by the broadest permissibleinterpretation of the present disclosure including the following examples of embodiments and their equivalents and shall not be restricted or limited by the foregoing detailed description.

Claims

CLAIMS:

1. A method by a pivot device communicating with a network gateway and a plurality of sensor devices, the method comprising: communicating (600) with a pair of sensor devices to obtain a pair of private keys, wherein each of the sensor devices is associated with a combination of public key and private key, deriving (602) at least one transformation key based on the pair of private keys, and communicating (604) to the network gateway the at least one transformation key with an indicated association with the pair of sensor devices.

2. The method by the pivot device of Claim 1, wherein for each pair of sensor devices which are to communicate with each other, deriving one transformation key of a pair of transformation keys based on the pair of private keys obtained from the pair of sensor devices and based on one direction of communication between the pair of sensor devices, deriving the other transformation key of the pair of transformation keys based on the pair of private keys obtained from the pair of sensor devices and based on an opposite direction of communication between the pair of sensor devices; and communicating to the network gateway the pair of transformation keys with an indicated association with the pair of sensor devices.

3. The method by the pivot device of Claim 2, further comprising: storing in local memory of the pivot device, the private keys and the pairs of transformation keys with an indicated association with the pairs of sensor devices.

4. The method by the pivot device of any of Claims 1 to 3, wherein the pair of sensor devices has a first sensor device associated with a first private key and has a second sensor device associated with a second private key, and the deriving of the at least one transformation key further comprises:deriving a first transformation key based on the first and second private keys and based on a first direction of communication from the first sensor device to the second sensor device; and deriving a second transformation key based on the first and second private keys and based on a second direction of communication from the second sensor device to the first sensor device, wherein the first and second transformation keys are communicated to the network gateway with an indicated association with the first and second sensor devices, and the first and second transformation keys are shared with the first and second sensor devices.

5. The method by the pivot device of Claim 4, wherein: the first transformation key is different from the second transformation key.

6. The method by the pivot device of any of Claims 4 and 5, wherein: the deriving of the first transformation key based on the first and second private keys and based on the first direction of communication from the first sensor device to the second sensor device, comprises providing an ordered set of the first private key and the second private key as input to a key transformation function to output the first transformation key; and the deriving of the second transformation key based on the first and second private keys and based on the second direction of communication from the second sensor device to the first sensor device, comprises providing an opposite ordered set of the second private key and the first private key as input to the key transformation function to output the second transformation key, wherein the second ordered set has an opposite order of the first and second private keys relative to the first ordered set based on the opposite direction of communication.

7. The method by the pivot device of any of Claims 1 to 6, further comprising: sending a notification to the network gateway to start relaying to the pivot device message traffic that is directed from the first sensor device to the second sensor device and / or directed from the second sensor device to the first sensor device.

8. The method by the pivot device of Claim 7, wherein the notification indicates that the message traffic is to be relayed to the pivot device without any transformation ofcyphertext in the message traffic by a transformation function of the network gateway using the at least one transformation key.

9. The method by the pivot device of Claim 7, wherein the notification indicates that the message traffic is to be relayed to the pivot device after transformation of cyphertext in the message traffic by a transformation function of the network gateway using the at least one transformation key.

10. The method by the pivot device of Claim 7, wherein the notification indicates that two copies of the message traffic are to be relayed to the pivot device, where one copy of the message traffic is after transformation of cyphertext in the message traffic by a transformation function of the network gateway using the at least one transformation key, and the other copy of the message traffic is without any transformation of the cyphertext in the message traffic by the transformation function of the network gateway using the at least one transformation key.

11. The method by the pivot device of any of Claims 7 to 10, further comprising: performing a decrypt function to transform cyphertext of a message in the message traffic into cleartext; performing an encrypt function to transform the cleartext into test cyphertext using the transformation key and a transformation function; and determining whether to send information based on content of the message to a network node based on comparison of the cyphertext to the test cyphertext.

12. A method by a network gateway communicating with a pivot device and a plurality of sensor devices, the method comprising: obtaining (600) transformation keys from the pivot device, wherein pairs of transformation keys are associated with different pairs of the sensor devices, and the transformation keys in each pair of transformation keys are associated with different directions of communication between the associated pair of sensor devices; receiving (602) a message including a first identifier of a first sensor device that is a source of the message and including a second identifier of a second sensor device that is a destination of the message;identifying (604) a transformation key among a set of the transformation keys obtained from the pivot device, based on the first and second identifiers and based on the direction of communication from the first sensor device to the second sensor device; transforming (606) cyphertext in the received message into transformed cyphertext using the identified transformation key and a transformation function; and sending (608) the transformed cyphertext in another message toward the second sensor device.

13. The method by the network gateway of Claim 12, wherein: the identifying of the transformation key comprises looking-up the transformation key among the set of the transformation keys using an index formed based on the first identifier of the first sensor device and the second identifier of the second sensor device ordered based on the direction of communication of the message from the first sensor device to the second sensor device.

14. The method by the network gateway of any of Claims 12 to 13, further comprising: storing in a local memory of the network gateway, the transformation keys each associated with a different combination of identifiers of the pair of the sensor devices and the direction of communication between the pair of the sensor devices.

15. The method by the network gateway of any Claims 12 to 14, further comprising: receiving a notification from the pivot device to start relaying to the pivot device message traffic that is directed from the first sensor device to the second sensor device and / or directed from the second sensor device to the first sensor device.

16. The method by the network gateway of Claim 15, wherein: responsive to an indication of the notification, relaying the message traffic to the pivot device without any transformation of cyphertext in the message traffic by the transformation function using the identified transformation key.

17. The method by the network gateway of Claim 15, responsive to another indication of the notification, relaying the message traffic to the pivot device aftertransformation of cyphertext in the message traffic by the transformation function using the identified transformation key.

18. The method by the network gateway of Claim 15, responsive to another indication of the notification, relaying two copies of the message traffic to the pivot device, where one copy of the message traffic is after transformation of cyphertext in the message traffic by the transformation function using the identified transformation key, and the other copy of the message traffic is without any transformation of the cyphertext in the message traffic by the transformation function using the identified transformation key.

19. A method by a first sensor device communicating with a pivot device and a network gateway, the method comprising: storing (700) a private key and a public key which are associated with the first sensor device; communicating (702) the private key to a pivot device to derive at least one transformation key associated with at least one direction of communication between the first sensor device and a second sensor device; obtaining (704) first cleartext for communication from the first sensor device to the second sensor device; performing (706) an encrypt function to transform the first cleartext into first cyphertext using at least the public key; and communicating (704) the cyphertext to the second sensor device via the network gateway.

20. The method by the sensor device of Claim 19, comprising: receiving second cyphertext from the second sensor device via the network gateway; performing a decrypt function to transform the second cyphertext into second cleartext using at least the public key.

21. A pivot device communicating with a network gateway and a plurality of sensor devices, the pivot device comprising circuitry operative to: communicate with a pair of sensor devices to obtain a pair of private keys, wherein each of the sensor devices is associated with a combination of public key and private key,derive at least one transformation key based on the pair of private keys, and communicate to the network gateway the at least one transformation key with an indicated association with the pair of sensor devices.

22. A network gateway communicating with a pivot device and a plurality of sensor devices, the network gateway comprising circuitry operative to: obtain transformation keys from the pivot device, wherein pairs of transformation keys are associated with different pairs of the sensor devices, and the transformation keys in each pair of transformation keys are associated with different directions of communication between the associated pair of sensor devices; receive a message including a first identifier of a first sensor device that is a source of the message and including a second identifier of a second sensor device that is a destination of the message; identify a transformation key among a set of the transformation keys obtained from the pivot device, based on the first and second identifiers and based on the direction of communication from the first sensor device to the second sensor device; transform cyphertext in the received message into transformed cyphertext using the identified transformation key and a transformation function; and send the transformed cyphertext in another message toward the second sensor device.

23. A first sensor device communicating with a pivot device and a network gateway, the first sensor device comprising circuitry operative to: store a private key and a public key which are associated with the first sensor device; communicate the private key to a pivot device to derive at least one transformation key associated with at least one direction of communication between the first sensor device and a second sensor device; obtain first cleartext for communication from the first sensor device to the second sensor device; perform an encrypt function to transform the first cleartext into first cyphertext using at least the public key; and communicate the cyphertext to the second sensor device via the network gateway.

Images