Bluetooth® mesh allows selected network nodes to act as proxy nodes. A proxy node supports both Bluetooth GAP/GATT and Bluetooth mesh communication and allows GATT clients, such as mobile, desktop, or web applications, to be part of a Bluetooth mesh network — often providing a GUI (graphical user interface) for monitoring and control purposes. Such applications may be referred to as proxy applications.

Proxy applications use GATT operations to send and receive Bluetooth mesh proxy PDUs which usually encapsulate mesh network PDUs. The proxy node relays messages from the proxy application to the Bluetooth mesh network or from the Bluetooth mesh network to the proxy application.

The Bluetooth mesh specifications provide information about network and device security. But solution architects may need to consider additional issues which are not covered by the Bluetooth mesh specifications when they design their solutions. In this article, I’m sharing some thoughts on some of the issues to consider and address when your Bluetooth mesh solution includes one or more proxy applications.

Figure 1 – Bluetooth LE applications and mesh proxy nodes

Bluetooth Mesh Security Keys

At the heart of Bluetooth mesh security are three types of security key which are used to encrypt, authenticate, and obfuscate Bluetooth mesh messages.

A network key, or NetKey, provides access to a specific network or subnet and is used to encrypt and authenticate those fields in a Bluetooth mesh message that are part of the lower layers of the stack.

An application key, or AppKey, provides access to a specific Bluetooth mesh network application, such as lighting or air-conditioning. It is used to encrypt and authenticate those fields in a Bluetooth mesh message that are part of the upper layers of the stack. An AppKey is bound to a specific NetKey, meaning that a device must possess both the AppKey and the specific NetKey it is mathematically related to in order to be used in securing Bluetooth mesh messages.

A device key, or DevKey, is used to secure direct communication with a specific Bluetooth mesh device. It is typically only used when configuring a device. Each device in a Bluetooth mesh network has a unique DevKey.

Keys are created and issued by the provisioning and configuration processes.

What Are We Provisioning and Configuring?

Designing a Bluetooth mesh proxy application raises some questions about Bluetooth mesh security. These questions concern issues which fall outside the scope of the specification, which is concerned with the collection of Bluetooth mesh protocols and associated procedures.

Usually, keys are issued to and associated with a specific device. For example, a particular light switch would be equipped with a specific NetKey, one or more AppKeys, and a unique DevKey. Through being in possession of these keys, the device then has the ability to participate in the required way in the network.

Proxy applications, whether they are mobile applications, desktop applications, or web applications, also need to be provisioned and configured so that the appropriate keys are available to secure the application’s interaction with other Bluetooth mesh nodes via a proxy node. The same fundamental Bluetooth mesh security rules outlined above apply to proxy applications too. If something, anything, wants to produce or process Bluetooth mesh messages, it must possess and apply the right keys to the messages it sends and receives.

Mobile and desktop applications generally take the form of some compiled or interpreted code installed on a specific machine, such as a laptop. Provisioning and configuration could be used to issue that machine with Bluetooth mesh keys. But would that be correct, and would that be sufficiently secure? Desktop and mobile devices generally act as platforms with sophisticated operating systems which can host multiple applications. If the act of provisioning and configuration makes the Bluetooth mesh security keys available to the whole platform, then all of its applications are being given the potential to be part of your Bluetooth mesh network. It seems unlikely that this is what you would want to do, and this could introduce a weakness in your Bluetooth mesh network security. But only you, the architect, can decide the true requirement.

It’s more likely that you should be issuing the keys to a specific application on a specific machine. You’d, therefore, want to ensure that the keys were stored in a location on the device which was only accessible from the associated application. Most operating systems provide ways in which the file system can be securely partitioned to meet requirements such as these. Applications are often described as operating within a sandbox with a private file system, accessible only by that application. This could be a candidate location for storing Bluetooth mesh keys that belong to a specific application.

Who Are We Provisioning?

Web applications add an extra dimension to the question of what exactly it is that new Bluetooth mesh keys are to be associated with. The nature of web applications means that they can be accessed from any device on the network that has a suitable web browser. There are likely to be multiple web applications on the IP network, but use of these applications will not be linked to a specific machine, as is the case with native fat client application instances.

Typically, a user accesses a web application from a machine on the IP network by pointing their web browser at the URL for that web application. Usually, they then need to somehow authenticate with the web application before being granted access to it. But again, this could well be happening from any one of a large number of machines of various types.

Having authenticated, it may be that the web application will limit the user to the use of a certain subset of available features, whereas another user might be able to use all features. These feature subsets might correspond to distinct Bluetooth mesh network applications and therefore, AppKeys. For example, when accessing the building monitoring and control web application, one user might only be able to access the lighting control application whereas another can control all building systems, not just lighting.

Furthermore, one user might be limited to controlling the devices in a specific Bluetooth mesh subnet, perhaps relating to a given floor of the building. This would correspond to a particular NetKey.

Which Bluetooth mesh keys should be used when user Alice logs into the building’s Bluetooth mesh monitoring application from her colleague’s desktop PC on the third floor? And how exactly would this work? This is the type of question we must be able to answer in our requirements and solution design.

One possibility is that Bluetooth mesh keys are associated with an authenticated user and specific web application, rather than a specific, physical device. This is the type of question architects must be able to answer in their requirements and solution design.

How Should Proxy Applications be Provisioned?

If the application technology supports it, proxy applications should be provisioned in exactly the same way as any other node in a Bluetooth mesh network. A mobile application, for example, should be capable of supporting the provisioning protocol over one or more of the provisioning transports and bearers.

But in some cases, this may not be possible. A web server which hosts a Bluetooth mesh web application is unlikely to have any sort of Bluetooth stack. In this case, a proprietary method for generating and distributing keys to the server will need to be devised by the solution architect. Each of the issues addressed by the standard provisioning procedure and protocols, such as authentication and key confidentiality, should be considered when devising proprietary solutions for unusual cases such as this.

Key Storage

If we decide to bind Bluetooth mesh keys to a user and their use of a particular application, rather than to a device, and our solution requirements stipulate that the user must be able to access the application from any machine on the IP network, we have little choice but to store the Bluetooth mesh keys on a central server. We’d need to design a database capable of associating key sets with the user and application and think about the security of those centrally stored keys. We should not need to invent anything new and break new security ground here. The secure storage of critical data, including security keys, is a common requirement in various applications, especially web applications. We’d certainly want to ensure physical security was in place to protect the server and that keys could only be accessed at the server by authorised personnel, perhaps those in possession of a suitable passphrase for accessing an encrypted key store.

Performing Cryptographic Operations

Proxy applications must formulate Bluetooth mesh proxy PDUs and this involves three distinct steps where Bluetooth mesh security keys are involved in cryptographic algorithms. The AppKey must be used to encrypt and authenticate the Bluetooth mesh access payload. A key called the Encryption Key, which is derived from the Bluetooth mesh NetKey must be used to encrypt and authenticate the Bluetooth mesh network PDU. The Bluetooth mesh network header, consisting of the CTL, TTL, SEQ, and SRC fields, must be obfuscated using a Privacy Key which is derived from the NetKey.

Where should these cryptographic calculations be performed? We can choose between performing the calculations at the client, within the proxy application itself or having the server secure our network PDU and return the results to the client for use in a proxy PDU.

From a security point of view, centralising the performance of those cryptographic functions could be the preferred way to go. You may need to take into account other considerations, however. Centralising at the server will require sufficient processing power and perhaps a hardware security module to offload the work from the CPU. You may think that downloading keys from the server to enable calculations to take place locally within the client offers some benefits, but it will also complicate your security requirements and solution. If that’s your preference, the Bluetooth mesh keys and any other sensitive data should always be downloaded over a TLS-secured IP connection and the server itself should be authenticated. The latter points are basics in the world of web security, of course.

In my opinion, for web applications, where any number of different physical client devices might be used, keeping the Bluetooth mesh keys in a physically secure, central location, which they never leave, seems the best approach.

Figure 2 – Possible architecture of Web Bluetooth mesh proxy application

Other Configuration Issues for Proxy Applications

Bluetooth mesh security keys are not the only aspect of Bluetooth mesh that might be impacted by the kinds of proxy application considerations discussed in this article. All Bluetooth mesh devices must have a unique, unicast address, for example. When the originator and ultimate receiver of Bluetooth mesh messages is a web application accessed from any number of machines by a variety of users, what should the unicast address used in Bluetooth mesh messages be? As you can imagine, a similar train of thought is likely to lead us to similar conclusions and perhaps each combination of user and proxy application could have a distinct unicast address allocated to it. Your configuration client will need to be able to allocate unicast addresses in a suitable use for non-standard, out of band assignment.

Other configurable Bluetooth mesh properties, per the configuration server model, should be assessed in the light of the overall solution requirements and dealt with in a similar way.

Alternative Architectures

The Bluetooth mesh proxy node offers one way for non-mesh Bluetooth applications to interact with a Bluetooth mesh network. It’s part of the standard and full implementation of the procedures and protocols will provide the benefit of interoperability and the ability to use standard provisioning and configuration tools. As described though, there may be occasions where requirements, solution architecture, and application technology constraints introduce situations which fall outside the scope of the formal Bluetooth specifications, and some part of the solution will then need to be proprietary.

Using proxy nodes is not necessarily the only way to integrate applications with a Bluetooth mesh network, however. An alternative architecture could include an IP to mesh gateway which converts between an IP-based protocol and the Bluetooth mesh protocols. With a gateway in the architecture, mobile, desktop, and web applications could use IP and be completely isolated from Bluetooth protocols. A standard for an IP to Bluetooth mesh gateway has not yet been defined and therefore this too would need to be a proprietary part of the solution architecture.

Summary

Creating secure Bluetooth mesh proxy applications requires solution architects to address issues that the Bluetooth specifications do not cover. There is a need to consider what it is we’re securing and the manner in which applications will be accessed and used. But we shouldn’t need to invent anything completely new. Bluetooth mesh proxy applications can leverage tried and tested approaches from the world of web, mobile, and client/server applications to create secure GUI applications for Bluetooth mesh network monitoring and control.

To learn more about Bluetooth mesh networking, download Bluetooth Mesh Networking: An Introduction for Developers.