We expect that these services will be delivered to us securely, and that is largely the case. But each method of implementing wireless communications, be it Bluetooth, ZigBee or cellular, has security strengths and weaknesses. Understanding these, and making informed trade-offs between the level of security each provides and the likely threats to your application, is vital to the proper implementation of wireless data transport.
One basic concern about wireless communication is to make it resistant to jamming by devices that transmit high-power noise on the frequencies used by your chosen protocol. One way to mitigate this issue is to ensure that the protocol you use has a mechanism to acknowledge the successful receipt of sent data. This, in turn, demands that a device which is largely meant to receive signals, such as a light bulb whose light can be turned on and off by a cloud service to acknowledge the command. Implementing bidirectional communication also opens up opportunities to use it for exchanging encryption keys, to help you ensure that you’re sending data to the right partner, and to detect attempts to jam the channel.
One major challenge in wireless data transport security is the fact that so many of the available protocols work over a common set of licence-free and publicly available frequencies – the ISM (for industrial, scientific, medical) bands. Bluetooth, Wi-Fi, ZigBee, ANT, SigFox, LoRa, Thread, RFID, and NFC all work in this spectrum.
The three most popular ISM bands in Europe are 433MHz, 868MHz and 2.4GHz. They differ in the amount of power a device is allowed to transmit, the available bandwidth, and the allowed duty cycle. Each of these factors has an impact on security. The 868MHz band, for example, has a bandwidth of 600kHz, while the 2.4GHz band has a bandwidth of about 85MHz. This means that you can establish more data channels in parallel at 2.4GHz, to overcome situations in which some frequencies are already in use by others.
The 868MHz band has a more strictly regulated duty cycle than the 433MHz band, which limits for how long you can send data. This may create a security issue if another nearby device, such as wireless headphones that stream audio continuously on the band, stop your application sending a critical data packet.
Many popular wireless standards already address these issues. For example, 2.4GHz technologies based on the IEEE802.15.4 specification (such as ZigBee, Thread and some others) use 16 channels with 5MHz modulation per channel, which makes them more robust to small signal disturbances. Wi-Fi uses 20MHz per channel, for similar reasons.
Classic Bluetooth uses the same frequencies, but split into 79 channels of 1MHz each, and then changes the channel 1600 times per second to improve robustness. Bluetooth Low Energy takes a slightly different approach, keeping to the same channel until it detects a disturbance, but using 2MHz per channel as a compromise.
Many smartphones use well-recognised protocols such as Bluetooth, WiFi, ANT and NFC to enable short-range connections, for example to portable speakers or home networks. The benefit of this approach is that the protocols are widely implemented and well understood: the drawback to this wide uptake is that it provides a large incentive to hackers to try and attack the protocols. One way to overcome this dilemma, especially if you’re building devices that only ever need to communicate with each other, is to create a proprietary wireless data transport protocol.
This approach has some advantages from a security point of view. You have full control inside your own network. No device from another company will be able to delay or interrupt your data transmission – this is the reason why most of the wireless smoke detector systems in public buildings use a secret protocol defined by their vendors. Another advantage is that, although your application may be important to you and your customers, it may not be very attractive for a hacker to invest a lot of time to hack your device. Most hackers look to compromise larger ecosystems, because the financial return of a successful zero-day attack on such ecosystems is higher. The flipside of this is, of course, that if something goes wrong with your proprietary approach, it will be up to you alone to solve the problem.
For designers working on implementing a wireless data transport system, the important thing is to make the right trade-offs. If you use a standard wireless technology, such as Bluetooth, its features are defined by the standards body and support for working with it means relying upon its developer community. If you want to create a proprietary wireless protocol, using the ISM bands as a carrier, you should ensure that you have understood the seven-layer ISO-OSI-model of a communication system, as a starting point, and that you check the regulations held on the ETSI website to understand the advantages and disadvantages of each ISM band.