Many readers may have come across this story regarding a brand of connected LED light bulbs which can be hacked to change the lighting, and worse, to reveal the homeowner’s Wi-Fi® Internet password. It’s a serious issue, and it has illuminated (pardon the pun) that security needs to be considered in depth when Internet of Things (IoT) devices are being developed.
On this note, I thought it would be worth allaying any fears that CSRmesh™, our game-changing protocol which allows for Bluetooth® Smart mesh networks, could be subject to similar breaches. We have considered security at every stage of the design and as such, it primarily prevents against eavesdroppers, man-in-the-middle attacks and replay attacks, and is considered highly robust.
To illustrate this, let’s consider how you add a new device into a CSRmesh network. The network is secured using an encrypted network key. This is derived from a password or phrase that the user is asked to input when they first download the app onto their smartphone. To make the process of adding devices into the CSRmesh network easier, it is possible to publish a ShortText code, barcode, or QR code with the device. This code may contain the device address (128-bit UUID), the 64-bit authentication code, and other short information that may be relevant. This is particularly useful for deployment of larger networks.
During device association, the smartphone app will exchange keys with the advertising device and an encrypted network key will be provided to the device upon completion of the association process
The next phase is about trusting the new device. Once each device has its peer’s public key, then they can start to generate a secret authorisation value using a complex algorithmic process. To test this authorisation value, both the configuring and new devices share a public key and then challenge the peer device’s knowledge of this authorisation value such that they can be assured that not only has the public key been distributed correctly, but that the peer device knows the authorisation value.
Once they have authenticated each other, only then will they distribute the network key, using AES-128 encryption. This mea
ns that nobody else can eavesdrop on this communication to determine the network key. All future messages sent over the network will be encrypted using the network key and only trusted members of the mesh network will know that key and be able to decrypt these messages. Messages containing a different structure or network key, such as those from neighbouring networks, cannot be decoded and are simply ignored and dropped. It is therefore not possible to control or listen-in to a neighbouring network, nor to derive the network key from it.
An optional authentication procedure can be employed using the private key to verify the validity of new devices before adding them to the network. A QR code or similar, containing this authentication code or private key, can be used for out-of-band authentication of devices appearing on the network and requesting access or association to the network. The smartphone, or associating device can scan the QR code from the device’s original packaging and thus securely obtain the authentication code “out-of-band”. When this device later appears on the network requesting association to the network and therefore requesting the network key, it can be challenged to also provide this out-of-band information or private key. This is then compared with what the associating device already gleaned from the QR code. If the two match, then the device is authenticated and the network key is encrypted and securely passed to the device being associated.
This authentication process therefore prevents an unknown device from accidentally or intentionally gaining access to the network, a process known as a “man-in-the-middle” attack.
The relaying of messages through the mesh network is also securely managed. To accomplish this, each device that relays messages must also know the encrypted network key. Only messages that can be authenticated against a known network key are relayed. This allows devices that are near other mesh networks, for example a device near to a neighbour’s property, to only relay messages for known networks and not for any foreign network messages.
There is always the potential for someone to steal the network key from a trusted network device, either by recording the encrypted information it is sending over the airwaves and playing it back at a later time, or by physically removing a device and reading its non-volatile memory. For this reason we prevent against ‘replay attacks’, someone trying to mimic a good network device message at a later time to try to gain access. A sequence number identifier is incremented and transmitted with each mesh message. If messages are replayed out of sequence then they are simply dropped and ignored. The network key data is not stored in a logical location in non-volatile memory, but is distributed across the memory hash table, making it very difficult to locate and identify. We would also recommend that any external trusted network devices use a separate network key that does not, for example, provide access to buildings or other secure areas.
The current release of CSRmesh for lighting supports only one network key per device, but a future version will support multiple network keys. This facilitates a ‘class of service’ structure for sub-networks within a building e.g. hotels which may require the enabling of different security zones.
Within the CSRmesh protocol there are also other security and control features such as:
- Time-to-Live (TTL) counter: which determines how many hops or relays a message is allowed to make within the mesh network. The TTL is decremented every time a message is relayed. When it reaches zero, the message can no longer be relayed. This limits the size of a network and sets a boundary
- TID message identifier: each message carries a unique TID. Devices receiving a new message compare its TID with the last few previously heard messages’ TIDs. If they are the same, that message is dropped, meaning that messages that have already been heard before are not repeated again. This limits the proliferation of messages and prevents echoes and infinite loops in the network
- A Seq sequence number: this maintains the location of messages within network and time. If messages appear out of sequence they are ignored, preventing record and replay attacks upon the network
As you can see, security is not something that is simple. Nor is it something that should be an afterthought in terms of design. It must be integral to the design of both the architecture and implementation of a networking solution. CSRmesh has been designed from the ground up to be as difficult as possible to be compromised, but it still includes the flexibility to increase the level of security over time as security algorithms improve.
Read more about the new CSRmesh protocol here. For a full list of features and information about ordering a CSRmesh Development Kit, click here.
If you have any security-related questions please post them below or on our support forum and we’ll get back to you.