News and Events

June 30th, 2016

Not too long ago Bluetooth® SIG announced that Bluetooth® is going mesh, giving a rise to a new wave of interest to Mesh networking. Although the interest is growing rapidly, solutions available on the market keep using just the trusted star topology. But what are the real possibilities?

Mesh, Ad hoc and MANET

Most networks on the market are declared to be “mesh ad hoc,” so in most cases these terms are used together in turn blurring the difference between them. But there is a difference and it’s important to highlight it.

Mesh network is a kind of a network topology where all the possible connections between nodes are established. This leads to the main mesh network feature – self-healing, where broken routes can be restored using different access links between devices.

Ad hoc network is a decentralized wireless network that does not require any infrastructure to form and maintain. Nodes connection depends on its possibility. This network is self-configuring, which means that devices can join or form it on the fly.

In this way, mesh network is the most robust static type of ad hoc networks. But when both terms are used together, they typically mean ad hoc only. Mesh explains just the physical layer of wireless communication that is broadcasting from its nature where all devices that are close enough hear each other (i.e., connected) and form enough links for self-healing. To be completely accurate, it should be mentioned, that “ad hoc” means that the nodes are stationary. There is a term for mobile nodes – Mobile ad hoc networks (MANET’s). But today in PAN/LAN context (Wi-Fi, Bluetooth, ZigBee) nodes are assumed to be static due to their use cases, even if they can be moved sometimes from place to place.

Wi-Fi

Wi-Fi is an area that already has ad hoc solutions available through documents and open source. Official specification IEEE 802.11S is the less effective and innovative one. It introduces two new kinds of devices: Mesh portals and Mesh points. Mesh portals are ordinary Access points with wired connection to the Internet. Mesh points act as wireless routers between stations and portals. Everything that has “mesh” prefix is connected together where it is possible. The standard is completely the same as B.A.T.M.A.N. adv Wi-Fi mesh that is already included in the Linux core.

In parallel, open source community works on cjdns (Hyperboria) that is a real candidate for the DarkNet set of protocols. Cjdns is developed in the way to create a wireless mesh network that is totally disconnected from the Internet. Its core advantages are:

  • End-to-end encryption
  • Tunnels between segments over the Internet
  • Decentralized generation of IP addresses
The last one is a headache for all Wi-Fi ad hoc networks. Old DHCP conflicts with the essence of the ad hoc network and mobility.

Mesh networking using Wi-Fi sounds ready but not for small low-power devices. Thus, we better pay attention to Bluetooth® Low Energy (BLE) and ZigBee®.

Bluetooth®

The first thing that Mesh-network-sceptics say about Bluetooth® is that it was not designed for Mesh networking. However it is widely spread, so why not to try using it?

Existing solutions on BLE are nothing more than trying to sell things that we already have in ZigBee® under the “Mesh network” label. To build a “mesh” the customer should buy a BLE gateway that forwards packets to the cloud. All main-powered BLE devices act as routers and interconnected with each other, while battery powered devices talk to routers only. Nothing special.

But BLE wins in that it is already in devices that have the Internet connection through 3G, LTE, Wi-Fi, and even the cable. That means that in theory the customer can get more than one gateway connected by the Internet. Moreover, customer’s tablets and smartphones bring the mobility to such network.

The power of the Wi-Fi + BLE collaboration has already been explored by Apple: check out the Multipeer connectivity framework for iOS 7 and, for example, FireChat application that proudly announces “Internet is not needed to chat.”

ZigBee®

When talking about ZigBee® one thing should be kept in mind – it was initially designed to be ad hoc. The routing mechanism implemented in ZigBee® is called Ad hoc On-Demand Distance Vector (AODV). Although RFC is operating IP frames, there are no major differences. The algorithm is quite simple for CPU and gentle to ROM and is available even for a bulb or smart socket or any other main-powered device.

As it was mentioned earlier, ZigBee®-based systems on the market currently prefer to use star topology, even though it has everything to be a mesh network and should be used as such. When Wi-Fi or BLE implement mesh, it is not only a technological step forward, but a marketing reason. The truth is ZigBee® is already a step ahead in terms of technology, but maybe a step behind in terms of marketing.

One might mot like that ZigBee® network is not using IPv6. Well, neither does BLE, but it does not disturb it. Nevertheless, there is IEEE 802.15.4 + IPv6 + UDP solution called 6Lowpan and Thread or JupiterMesh built over it. Though they haven’t still made a splash on the market, probably nobody has positioned them as “mesh.”

As we can see, if the market wants mesh/ad hoc/MANET, there are all the pre-requisites for it. It is already around but the customer is not aware of it because either the market is too “shy” or that field has not yet been covered in depth. Anyway, the results will come soon and they will come from Wi-Fi, BLE, ZigBee or even a collaboration between them.

At the end of last year, a group of researchers from Cognosec presented their “ZigBee exploited” report at the BlackHat conference in the USA. They demonstrated a tool that allows an intruder to open your doors, shut up motion sensors off and even turn the lights off in your bedroom, of course only if these devices are controlled via ZigBee.

IT and for the most part non-IT sources repeated the news many times with excessive drama effect and as a result, we had got a categorical accusation of lack of security in ZigBee and even the entire IoT. Based on the forecast that there will be 29 billion of IoT devices in the not so far 2020, “experts” convinced their readers that it is not the problem of the future but the present and that all devices are vulnerable. Now when the panic has calmed down, let’s see what happened in terms of ZigBee.

First, let’s talk about silent motion detectors. Motion detection in the system that was hacked works the following way: when a sensor detects a movement it sends a ZigBee message to a gateway (you may call it smart hub, ZigBee hub, etc.), which uses TCP/IP to deliver this message to the user. Cognosec researchers used a jammer to break the ZigBee link between the sensor and the gateway. Even when the jammer had been turned off, the motion alarm was not retransmitted because the retransmit attempts were over or the sensor decided that the link was lost (we can only guess). Samsung, whose hub was attacked during the research, has already given the proper comment and we agree with it 100%: ZigBee Motion sensors are not designed to be a professional, highly secure alarm system. We wonder if anybody has already seen a professional alarm based on a wireless protocol. Although the jammer attack is not specially a weakness of ZigBee, it may be useful for those customers, who want to get an alarm but do not want to pay a high cost.

Moving on, now we are going to discuss the weakness that was introduced as a supermassive hole in the ZigBee security, but it is actually not ZigBee specification’s fault. The reality is that a large number of ZigBee devices available on the market use the default Trust center link key to encrypt active network key transport. This key is open and there is not much difference for security in sending the network key as plain text or encrypted by the default key. ZigBee specification warns developers about such threat and recommends out of band or not-by-the-air methods to deliver an initial master key to both the trust center and the device. Researchers criticize this recommendation because it is not a requirement when the required by the specification default trust center link key in its turn breaks the security. But why shouldn’t the not in-band key delivery be a part of wireless protocol specification? Moreover, as anybody, even researchers, agree, unsecured key transport is ideally performed only once, during an association and most likely is not a threat, of course unless a maniac with an enabled ZigBee sniffer is spying on your house 24/7. And here the thing that everyone is talking about comes to the surface. Assuming that a quick, low-power, unsecured key transmission is performed once, hackers enable their jammer again to force link loss. When the link is lost, there are two ways to get the key:

  • A “typical” user triggers association one more time when an intruder’s sniffer is enabled;
  • Device tries an unsecured rejoin (that is allowed by the specification).
Respectively, there are two ways to dispute:
  • Strictly saying a “typical” user will most likely reset the device, reset doesn’t mean a factory reset, just power off/on. The reset will trigger a rejoin process and now we move on to the second point;
  • Although ZigBee allows unsecured rejoin, secured one is not forbidden; it’s just a policy, an option that can be configured by the manufacturers. The problem wouldn’t exist if the devices under the test implemented secured rejoin. There also wouldn’t be any problem, if there weren’t high security requests to the devices that implement unsecured rejoin.

The main conclusion from our dispute is that the found exploit is not a “ZigBee” one, it’s “Current ZigBee implementation exploit.” It will not be superfluous to say that researchers from Cognosec are ZigBee users too and they pointed out that ZigBee specification provides all the good recommendations to build a secure system. But dramatic headlines and maybe mass hysteria turned the device problem into the core standard one. There won’t be any panic, if anybody interested in IoT (or ZigBee), based their opinion on the original source:

https://www.youtube.com/watch?v=9xzXp-zPkjU

https://www.blackhat.com/docs/us-15/materials/us-15-Zillner-ZigBee-Exploited-The-Good-The-Bad-And-The-Ugly.pdf

The Internet of Things (IoT) often brings us convenience, economy, fun, and security, but it’s also a source of numerous challenges for developers, installers, and maintainers. In this article, we are talking about one facet of the global IoT challenge – secure remote access.

Every small piece of a Smart Home, be it a Thermostat, a Security Sensor, or a Light bulb, has direct, or more often indirect, access to the Internet. Local or near-field security is a very important topic – but its meaning can’t be compared with security of access to the Cloud services responsible for configuring, notification, alarms, and all other things that make our homes smart. Personal computers, smartphones, printers, NAS have network connectivity that lasts a very long time, but we should not forget that compromising some of the small home devices mentioned above would allow an attacker some control over the physical world, which is definitely a different type of risk than associated with a personal computer.

For example, imagine an attacker has access to notifications from the home’s Thermostat. He can’t control the Thermostat, however, he has access to current mode and temperature. And using this harmless data he not only violates the abstract privacy, but most likely also knows the schedule of the house occupants, as well as if someone is home at that particular moment.

The recent research published by Symantec shows the following vulnerabilities are common for almost all Smart Home Solutions.

While passwords, encryption, account enumeration, and supply chain attacks are more or less obvious and are usually related to the user experience or the corresponding standards, attacks and issues on remote access security (including web vulnerabilities, mitm attacks, and firmware tampering) should be mitigated during design and development.

So yes – it’s recommended to have secure access from Smart Home devices or Gateways. And of course there are dozens of solutions suitable and secure, at least at the current technical level. However, sometimes even a security professional asking, “what to secure?” forgets about the “when.”

What percent of devices in the field are manufactured inside a vendor’s own facilities and prototyping factories? It’s hard to know the exact answer without using floating-point operations. And even the best scheme following all standards and guidelines can be compromised during manufacturing. So here’s where the challenge becomes really intriguing.

This leads to the following requirements:

  • Server side validation (e.g., server must be sure that the client is an approved device).
  • Client side validation (e.g., client must be sure it connects with the right server).
  • Client side security materials should not be accessible by the manufacturer.
With server side validation, everything is more or less standardized. The only thing required to add to the common pattern is custom security materials for each client for the purpose of client identification.

From the client side the solution is trickier – tens of thousands of devices are in sleep mode in a warehouse somewhere when it is discovered that the server is compromised, and, as a consequence, they can’t be reprogrammed. This leads to an additional server validation service. It can be, for example, a dedicated OCSP server or some custom solution with only one function – inform the device that the server’s security materials are compromised.

When talking about compromising during manufacturing, there’s another well known, but not so widely used option – updating security materials when the device is installed. It may be manual activation via the web or just an update on first connection.

In summary:

  • All clients should have pre-programmed security materials containing unique ID for each client that should be updated as soon as the device is installed.
  • Server should have validation scheme for each client. Something simple like white list is more than enough.
  • Separate validation service should be implemented to allow clients to at least detect that the server has been compromised. Note that for better security, it may be reasonable to set the lifetime of the security materials used for access of the validation service to a reasonably short value. For example, instead of years usually used for main services, use 20-30 days.
These 3 simple principles make the entire system much more secure and, as a bonus, this scheme can be implemented using open-source software as described below.

Sample Security Solution

Note that the scheme above is just a sample solution; the services can be replaced with some custom implementation or appropriate analogs.

  • Root CA – In Public Key Infrastructure (PKI) acts as Root Certificate Authority – it signs certificates for Manufacturer, OpenVPN server, and OCSP responder. In addition, you should maintain the list of compromised and expired server certificates as part of the Root infrastructure Certificate Revocation List (CRL).
  • openvpn-server.com – machine (or number of machines) that runs OpenVPN server and Application Server.
    • OpenVPN Server handles VPN connections from devices. Optionally, it can check if device ID extracted from the certificate is listed in the known device list. The device list is provided by the Manufacturer and contains IDs of issued devices. This list can be used to control number of devices issued by the Manufacturer.
    • Note: Server always “knows” if the certificate is issued by the Manufacturer or by the Root CA and can replace certificate on the device after the first successful connection.
  • Manufacturer – 3rd party in the PKI acts as an intermediate Certificate Authority – it issues certificates for devices. In addition, Manufacturer should maintain the list of IDs for all issued devices and provide this list back.
  • Field device – runs different applications. Application sends the gathered info to Data Server performing the following steps:
    • establishes tunnel to OpenVPN server using OpenVPN client
    • checks (using request to OCSP server) that OpenVPN server certificate was not revoked
    • sends data using VPN tunnel to Data Server
    • closes VPN tunnel
  • ocsp-server.com – Instance of OCSP Server.
  • OCSP Server – Online Certificate Status Protocol responder. This is the special service that can be used to check if the OpenVPN server certificate was revoked. Note that the OCSP certificate is equally important as the Root CA certificate since it can be used to block all VPN connections. So it is good idea to run the OCSP service on a separate machine where no additional services are running.
DSR Corporation has been held over by the ZigBee® Alliance to again showcase the seamless interoperability available through ZigBee wireless standards. Via the development of a Connected Home display wall at the Light + Building 2016 show in Frankfurt, this display wall will feature certified ZigBee home automation products from numerous manufacturers located around the world. Full text of the press release available here .
Anatoli Pechkov is talking about the current problems and perspectives of the smart home market. You may the full text here.

Show more