The Internet of Things (IoT) has been a buzzword for years, but have you noticed the changes around you? Think about your home: How many connected devices do you own? From routers to televisions, to air conditioning and wireless devices, our homes today are interconnected with devices.
Home network topology
A smart home is equipped with connected appliances and devices that can be monitored and controlled remotely. Typically, three types of connected devices function at home:
- Devices connected directly to the internet via a (wireless) router at home
- Devices connected to a smartphone, which is connected to the internet
- Devices connected to each other and to a gateway, which is connected to the internet
Together, these devices combine to form the home network topology shown in Figure 1.
A smart device is typically connected to its vendor’s cloud, with a smartphone application from each vendor controlling the device and building automation.
This causes one of the smart home automation pain points, as the devices from different vendors communicate through vendor-specific solutions, which leads to device interoperability and reliability problems with the growth of device networks within the home.
Source: Synopsys
Wireless protocols at home
Protocol selection for a smart device is based on needs for bandwidth, range, and topology. Here, widely used wireless protocols are as listed:
- Wi-Fi/WLAN. Wireless LAN provides internet connection for all home devices with ultra-high-resolution video-level streaming bandwidth. Most devices with high bandwidth requirements and no power constraints select WLAN for the communication protocol.
- Bluetooth. There are two types of Bluetooth devices: Classic and Low Energy (LE). Classic is mostly used for transmitting audio, like streaming music to a speaker. LE is more apparent in sensors, like health and wearable devices connected to smartphones.
- Zigbee. This low-cost, low-powered mesh network is widely deployed for controlling and monitoring applications like lighting, plugs, security sensors, and locks. Zigbee devices communicate with each other, and a gateway device is needed to allow communication with the internet.
- Thread. Thread protocol is used for the same purpose as Zigbee, the main difference is that Thread devices are IPv6 addressable and can speak to the internet (and each other) via native IP. For this reason, Thread is selected for low-layer transport protocol in the new Matter standard.
About the Matter Smart Home standard
The Matter Smart Home Standard is an ongoing industry push to create a smart home technology standard that provides secure, reliable, and seamless communication across smart home devices, mobile apps, and cloud services. Thus far, it includes IP-level standardization on top of selected transport layers, which are Ethernet, WLAN, and Thread.
Secure and reliable communication with fuzz testing
Many device vendors are partaking in protocol-specific certification programs to increase interoperability. Certification testing is mostly functional which provides valid inputs, with outputs compared to a correct or expected value. It verifies normal functionality, but what if it’s exposed to unusual inputs?
Fuzz testing or fuzzing is an automated software testing method that injects invalid, malformed, or unexpected inputs into a system to reveal software defects and vulnerabilities. It complements functional testing. Fuzzing is proven to discover security, performance, and other quality issues within test targets.
Smart bulbs have made blinking and dropping from the mesh network due to fuzzing, which makes you imagine the effort of rebuilding the network for all the lights in your house. In a worst-case scenario, the fuzz data can bypass the network protection mechanisms and inject data into the network.
Here, a malicious attacker can pollute wireless networks and utilize vulnerabilities (such as information leakage found by fuzzing a wireless protocol) to get access from a smart device to the home network, and then provide backdoor access from the internet.
Robustness in unexpected conditions
A malformed wireless frame can be the result of a cybersecurity attack, but it can also appear from a device that interprets protocol specifications differently, has a coding error, or has a hardware malfunction.
A model-based, protocol-aware fuzz testing tool will test, for example, the minimum and maximum values for each field in the protocol with a message that has all the checksums, lengths, and encryption is done according to protocol specifications.
It is advised to add vendor-specific data to a protocol to provide extra functionality. Some protocols provide mechanisms for this, but vendor-specific data can piggyback on a valid protocol message and be added into protocol-reserved blocks or at the end of a valid structure.
This is usually not a problem as other devices are not aware of the additional data or are not handling it. If both vendors are doing the piggybacking, they might handle additional data that isn’t valid for them. Even without extensions, different protocol versions and adaptation errors add risk to having nonsense data appear on the network.
Another example is a hardware malfunction. A sensor reports temperature, humidity, and air pressure, and each value is a 16-bit number, so one message should have all three values. Let’s say an air pressure-sensing component suddenly stops answering.
A sensor code can report to the network 0x0000, 0xFFFF, or leave the value out of the message. Is the code handling the sensor value prepared for all these possibilities? There might be a divide-by-zero crash since air pressure should never be zero.
One typical mistake is to handle unsigned values with signed types when unsigned maximum values lead to unexpected situations. Repeated or missing data can also lead to unhandled situations in code. Again, a protocol-aware fuzzer can test all these conditions before there is a broken sensor in the network.
In the table below, the maximum value can cause two types of problems:
- The value is read to a signed variable and gets a negative
- The value is used in calculations leading to integer overflow (value=VALUE_MAX+1) or underflow (value=VALUE_MIN-1).
The industry pumping out devices that communicate seamlessly with each other, which is good for consumers. However, this leads to large networks with a mixed set of devices from different vendors. From a device perspective, you cannot trust device quality in the same network.
It’s important to ensure that devices work in all unexpected conditions in a network with a mix of different devices. With that, to implement a secure and reliable smart home device, it is advisable to have protocol fuzz testing on your task list.
