Securing Bluetooth Mesh
Proxy Applications

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.

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.