Golioth recently announced support for Bluetooth-to-Cloud connectivity, opening up the benefits of our cloud platform to a massive new segment of connected products: those without IP addresses. While Bluetooth support is the headline feature, the underlying protocol, pouch, is designed to support many different types of device networks, including those based on CAN, LoRa, and other transports. Today we’ll give you a glimpse into how we think about connected device networks at Golioth, and how our engineering team went about designing a solution that will enable any product to leverage Golioth for secure, flexible, and efficient cloud connectivity.

Devices and Gateways

A network is traditionally conceptualized as a set of nodes and edges. While the term node is intentionally loosely defined, in connected device networks a node can be thought of as a device. From the perspective of the Golioth platform, in any data transmission there is a single device that acts as the “last hop” in delivering data to the cloud, and a “first hop” in delivering data back to devices. In more traditional network terms, these devices are those that share an edge with the Golioth platform. We refer to this subset of devices as gateways.

Gateways are equipped with hardware and software that allows them to directly connect to the internet over cellular, Wi-Fi, Ethernet, Thread, etc., and they transmit data on behalf of other devices represented on the Golioth platform. Both of these attributes must be present to be considered a gateway. For example, prior to the introduction of Bluetooth-to-Cloud connectivity, all devices represented on the Golioth platform were directly connected, but were unable to transmit data on behalf of other devices. Likewise, an intermediary device may “forward” data between an originating device and a gateway, but does not directly connect to the Golioth platform. Neither of these types of devices would be considered gateways.

Managed and Unmanaged Devices

The Golioth platform has always included a concept of a device. As the product has grown and evolved, we have endeavored to represent heterogeneous devices through a consistent interface, ensuring that operators do not have to think about how any one device is communicating with the platform. This has been challenging at times, and ultimately led us to say “no” to features that would be useful for some devices but not generally applicable.

As we moved towards supporting devices that are not directly connected to the Golioth platform, we reached a breaking point with this ethos: some products dictate that nodes in a network are unable to be represented via the current device entity on Golioth. For example, many products utilize a mobile application as a gateway between Bluetooth devices and the internet. This application is likely to be distributed and updated via an app store, not managed via Golioth’s device management services. The smartphone itself may be owned by an end user, which must authenticate to a Golioth customer’s service in order to use the product, before it ultimately brokers communication between the product and the Golioth platform. In short, the gateway device communicates securely with Golioth, but it is not managed by it.

Similarly, devices that produce data that flows to Golioth via a gateway may not be managed by the platform. The most obvious example of this type of device is a BLE beacon that identifies itself and may emit sensor readings, but cannot be made to run arbitrary firmware. A gateway in proximity to this type of device may want to deliver the data to Golioth, including information about the originating device. This has always been possible with Golioth, as the gateway could enrich the payload with an identifier for the originating device (example). However, the originating device was not natively represented on the Golioth platform, placing the onus on the customer to construct a representation of their network topology externally.

To address both of these use cases, we developed the concept of an unmanaged device. This is a device that can be represented as an entity on the Golioth platform, but does not make use of Golioth’s device management services. Unmanaged devices cannot be manipulated directly, but they may be inputs to network level operations (e.g. access control lists, routing configuration, etc.). Their identity is managed externally, though any device that communicates directly with the Golioth platform must be able to authenticate with valid credentials. Managed devices utilize Golioth credentials, whereas unmanaged devices leverage identity federation.

With the definitions of devices and gateways, as well as the distinction between managed and unmanaged, any device that communicates directly or indirectly with Golioth can be categorized into one of the boxes above. Importantly, a single fleet of devices could be comprised of both managed and unmanaged devices and gateways.

Impersonation and Proxying

The combination of managed and unmanaged devices and gateways results in a few permutations of network types. To accommodate each of them, we needed to develop two new capabilities on the Golioth platform.

Impersonation allows a gateway to send data as if it was another device. It is relevant for networks comprised of managed gateways and typically unmanaged devices. To do so, the gateway must authenticate to Golioth as itself, then send data with a header indicating that it wishes to impersonate another device in the same Golioth project. Network policies in the project determine whether the operation is permitted. If so, the gateway is able to interact with all device management services and data streaming pipelines as the impersonated device.

Proxying requires a managed device that can encrypt messages to be securely delivered to and from Golioth, and either a managed or unmanaged gateway to deliver them. An advantage of this strategy is that gateways are unable to view or modify the data that they proxy, which allows for scenarios in which the gateway cannot be trusted. It can also dramatically simplify the implementation of a gateway, only requiring that it is able to generically pass encrypted data between devices and Golioth. We have developed a new protocol for this use case: pouch. It defines the structure for these messages, as well as how they can be delivered to the Golioth platform. We’ll share more about the details of pouch in a future post, but it guarantees privacy and authenticity, ensuring only originating devices and Golioth are able to access the transmitted data.

Common Use Cases

To illustrate these various configurations, it is helpful to enumerate a few common use cases and how they can be deployed on Golioth.

Industrial Machine Monitoring

Category: Managed Gateway, Managed Device

On production lines where downtime can have significant negative financial impact, proactively monitoring, servicing, and replacing machines is imperative. With a large number of machines, it is desirable for monitoring devices to be low-cost and low-power such that they can be deployed widely and do not have to be replaced frequently. At the same time, improvements to sensor processing, such as the development of new machine learning models, necessitate the ability to remotely update firmware across a fleet. Golioth provides this capability out of the box for managed devices. Similarly, it may be desirable for gateways in this setting, which have a large number of devices connected, to perform edge processing or caching. It may also be necessary to remotely push network policies to gateways.

The device and gateway are both managed in this scenario, and both possess Golioth credentials. The managed device utilizes pouch to securely transmit data to Golioth, preventing intermediate parties from viewing or manipulating payloads. The managed gateway uses traditional security protocols, such as TLS or DTLS to both securely send its own data to the Golioth platform, as well as proxy the encrypted pouch messages for the managed device. As previously mentioned, impersonation can also be leveraged in the “managed gateway, managed device” scenario. This can reduce overhead and allow for more intelligent caching techniques across devices. However, it also introduces more complex gateway logic and presents additional security requirements.

Electric Scooter and Mobile Application

Category: Unmanaged Gateway, Managed Device

Micro-mobility solutions, such as electric scooters, frequently have companion mobile applications that allow for users to temporarily unlock and use the vehicle. In this case, the maker of the vehicle distributes the mobile application, but does not own or control the gateway that it runs on (i.e. user’s smartphone). The scooter itself communicates with Golioth via the mobile application, enabling streaming of telemetry data and performing OTA firmware updates.

The mobile application is an unmanaged gateway, leveraging federated credentials to securely connect to Golioth, but it is unable to be managed or manipulated from the platform. It proxies on behalf of the scooter, which is a managed device, possessing Golioth credentials and capable of using pouch to securely deliver data to and from Golioth. There may be an additional secure channel established between the gateway and device using native transport capabilities, such as BLE Secure Connections, without involving any Golioth components.

Asset Tracking

Category: Managed Gateway, Unmanaged Device

Knowing the status and location of assets has become important for quality control and operational efficiency. With a typically large volume of assets, driving down the cost of tracking devices is a top priority. Because assets are moving between controlled environments, such as trucks and warehouses, simple off-the-shelf BLE tags can be used to broadcast identifiers and relevant sensor readings. These potentially short-lived devices perform simple operations and typically cannot run custom firmware.

The majority of the functionality in this case lives in the managed gateway, which authenticates using Golioth credentials. It utilizes impersonation to send data on behalf of the unmanaged device, enabling data to be associated with that device on Golioth, even though the device itself cannot authenticate directly.

Building Your Network

Building a connected product that requires a device network? Sign up for Golioth’s Bluetooth-to-Cloud Connectivity private access program, or join us in the forum to tell us more about your use case! Over the next few weeks we’ll be sharing more information about pouch, identity federation, network management, and many other capabilities that enable device networks.