Bluetooth® Mesh Networking allows selected network nodes to act as proxy nodes. A proxy node supports both Bluetooth GAP/GATT and Bluetooth Mesh Networking 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 Networking 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 Networking 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 Networking 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 Networking solution includes one or more proxy applications.
Bluetooth Mesh Networking security keys
At the heart of Bluetooth Mesh Networking security are three types of security keys 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 Networkingmessage 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 Networking 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 Networking 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 Networking proxy application raises some questions about Bluetooth Mesh Networking security. These questions concern issues which fall outside the scope of the specification, which is concerned with the collection of Bluetooth Mesh Networking 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 Networking nodes via a proxy node. The same fundamental Bluetooth Mesh Networking security rules outlined above apply to proxy applications, too. If something, anything, wants to produce or process Bluetooth Mesh Networking 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 Networking 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 Networking security keys available to the whole platform, then all of its applications have 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 would, 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 Networking 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 Networking subnet, perhaps relating to a given floor of the building. This would correspond to a particular NetKey.
Which Bluetooth Mesh Networking keys should be used when user Alice logs into the building’s Bluetooth Mesh Networking 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 Networking 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 Networking 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 Networking 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 Networking keys on a central server. We would 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 would certainly want to ensure physical security was in place to protect the server and that keys could only be accessed at the server by authorized personnel, perhaps those in possession of a suitable passphrase for accessing an encrypted key store.
Performing cryptographic operations
Proxy applications must formulate Bluetooth Mesh Networking proxy PDUs and this involves three distinct steps where Bluetooth Mesh Networking 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 Networking 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, centralizing the performance of those cryptographic functions could be the preferred way to go. You may need to take into account other considerations, however. Centralizing 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 Networking keys in a physically secure, central location, which they never leave, seems the best approach.
Other configuration issues for proxy applications
Bluetooth Mesh Networking security keys are not the only aspect of Bluetooth Mesh Networking that might be impacted by the kinds of proxy application considerations discussed in this article. All Bluetooth Mesh Networking devices must have a unique, unicast address, for example. When the originator and ultimate receiver of Bluetooth Mesh Networking 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 Networking 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 for a suitable use for non-standard, out-of-band assignment.
Other configurable Bluetooth Mesh Networking 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 Networking proxy node offers one way for non-mesh Bluetooth applications to interact with a Bluetooth Mesh Network. It is 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 Networking 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 Networking 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 Networking 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 are securing and the manner in which applications will be accessed and used. But we shouldn’t need to invent anything completely new. Bluetooth Mesh Networking 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.
