*Our article on network security in connected lighting systems was originally published in the April’17 issue of the LEDs Magazine.

After a short break, we now return to our series of blogposts on what matters and what makes a difference in commercial lighting environment – from the point of view of wireless technologies used in connected lighting control systems. This time around, we’ll focus on network security.

Security is clearly among the hottest topics in the Internet of Things today. Multiple media reports on security flaws found in all kinds of smart devices keep heating things up – to the point where some even herald that the proliferation of connected “things” will trigger the coming of a massive wave of cyber criminal activity that could potentially affect any of us. There is no reason to panic, though. Doomsday scenarios always sell well, as opposed to gradual, painstaking work carried out by security experts day by day. What we must be aware of is that when it comes to connected technologies, we are all still early on the learning curve. This mirrors the challenges faced by the technology industry in the early days of networking. Security was a mess back then, but effective mechanisms were eventually developed, allowing us to use the Internet and all types of electronic devices on a regular basis to process payments and manage confidential information. As long as we – end users – follow common sense, today’s IT can be considered safe. The IoT will be safe, too. And smart lighting will be no different.

That said, security threats of course need to be taken very seriously – particularly now, at the beginning of the technology adoption curve. The IoT undeniably offers new levels of exposure to security threats, and smart lighting is a perfect example. In the era of traditional wired lighting control systems, security wasn’t even an issue. It simply wasn’t needed, which is why “wired” protocols – such as BACnet, DALI or KNX – didn’t have any security mechanisms implemented. Instead, cables were hidden deep in the walls and were therefore considered safe. While taking control over such a system is theoretically possible, the effort required to do so is simply bigger than the reward. If a criminal is able to enter a building and drill through its walls then lighting controls are probably the last thing he’d be interested in anyway. But smart lighting is a different story. Connected LEDs with flawed security can potentially be taken over remotely by someone who’s not even inside a given building. Furthermore, such an intruder might get access to much more than lighting controls. The abundance of data that can be generated by sensory networks is one of the biggest benefits of commercial smart lighting systems, but this data might be attractive also for cyber criminals. In certain scenarios, configuration data obtained from smart LEDs might even allow them to gain access to companies’ internal IT networks. This would require multiple errors to be made in the process of smart lighting network design and implementation, but it is certainly possible in certain circumstances. Finally, many risks will become more relevant as IoT solutions mature. With modern buildings embracing technology at a rapid pace, smart lighting systems can be expected to become more and more integrated with building management systems and other key infrastructure, such as HVAC systems. This means that ultimately connected LEDs will be an even more tempting target for cyber criminals.

For these reasons, security is a must in wireless environment. This is one of the most profound differences between wired and wireless lighting control systems. And part of the reason why we hear about security issues so often is that the resource-scarce nature of connected devices makes designing security particularly hard. Flawless security measures and guarantees cannot be achieved by copying the solutions and methods known from traditional IT systems, since smart things usually offer very small storage space and very low processing power. Plus, there is the security versus ease-of-use challenge that developers struggle with. If a given security scheme is too time-consuming or too difficult to apply, customers will stay away from products using it.

In many applications, security is often mistakenly associated almost exclusively with encryption. A system is considered secure if no one can find out what’s going on inside of it, e.g. what commands are exchanged between individual devices. While encryption is an important part of the security architecture, it is not what security is all about. The exchange of data between a wireless switch and a lighting fixture basically wouldn’t have to be encrypted in any way. If someone eavesdrops the signal sent between the two, the obtained information is going to be pretty much useless. You don’t need sophisticated decryption techniques to guess what a switch could say to an LED, and just by looking at a given space or an office building window you can determine what types of commands are being exchanged at a given time. Sensor data might be a bit more sensitive, though. While some sensors transfer publicly available data, others might generate more or less commercially sensitive information. In such case, appropriate encryption mechanisms obviously need to be applied.

So if encryption isn’t the crucial part, then what is more important? Authentication. This is what prevents unauthorized access to the lighting control infrastructure. A smart fixture needs to be sure that a command it receives originates from an authorized entity, be it a smartphone or a wireless switch on the wall. In addition, the integrity of the exchanged data must be ensured – so that no one can alter the message before it reaches its recipient. Authentication is also an absolutely crucial part of the onboarding process, preventing potential intruders or Trojan horses from sneaking into the system when a new device joins the network.

Before data exchange can be authenticated and ultimately processed, devices must first exchange authentication keys. What is crucial is the secure delivery of these keys. If this process is sabotaged, an unauthorized party can obtain some very sensitive security information. This was the case with the infamous security flaws in ZigBee devices that were presented during the Black Hat USA 2015 conference. Despite the fact that the protocol uses a 128-bit AES algorithm for data encryption, as well as three types of keys for managing authentication, it was demonstrated that ZigBee communication could be easily hijacked due to vulnerable device pairing procedure that allows external parties to sniff the exchanged network key.

As far as encryption is concerned, the abovementioned data encryption standard AES-128 is currently used by all of the leading low-power wireless communication protocols. It’s been around for a while, so one might wonder whether it still remains computationally secure against brute-force attacks. After all, technologies aimed at breaching popular security mechanisms keep developing rapidly – just like security technologies themselves. But there is a good reason why governments and businesses place such a great deal of faith in AES-128. The standard remains, realistically speaking, unbreakable. That’s because today there is no computationally feasible method to crack it. Doing so would require ridiculous amounts of time even when multiple supercomputers were involved in the process (and we’re talking about thousands and millions of years here). Even if cracking AES-128 becomes technologically feasible in any foreseeable future, such an attempt still wouldn’t make much sense, since it would be more expensive than the value of whatever the key is protecting. Currently, the U.S. National Institute of Standards and Technology (NIST) claims that AES-128 will be a totally secure encryption method at the very least up to 2030. What can be said for sure is that cheaper and more efficient low-power technologies will become available by that time, allowing us to use stronger encryption methods, such as AES-256 which is a bit too power-hungry for today’s generation of smart devices.

This shows that encryption isn’t an issue in smart lighting security today. Commonly used technologies are good enough to ensure that encrypted data cannot be deciphered. As already pointed out, authentication is much more sensitive and thus much more important. It is also the only effective weapon against the so-called replay attack, also referred to as playback attack, which can easily get around even the strongest encryption solutions we could ever come up with.

Long story short, a replay attack is about recording certain data packets and playing them back later on to achieve a desired result. The intercepted message does not have to be decrypted at any point. It’s re-transmitted in exactly the same form in which it was originally sent, to produce exactly the same result. Since encryption is helpless against such an attack, how can it be prevented? By appropriate authentication mechanisms. Once they are applied, the network from which the intercepted data packets originate won’t allow such re-transmitted messages to be executed. Authentication is also the only effective tool against man-in-the-middle (MITM) attacks which occur when communication between two devices is secretly monitored, captured and potentially altered by an unauthorized third party.

What authentication can’t prevent is the so-called trash can attack. Building administrators need to get used to the fact that each smart device within a network stores certain sensitive access data, such as network keys. Therefore, it would be wise to have certain carefully thought-out procedures implemented for discarding broken or worn-out devices. Unauthorized persons should be prevented from being able to retrieve security keys manually from e.g. a discarded bulb, because such attempts might be highly successful if non-volatile memory is poorly protected in such devices. What can manufacturers do to prevent that? Use only integrated memory instead of separate memory chips and disable debugging interfaces, while at the same time ensuring that attempts aimed at retrieving security keys will result in damaging the chip and destroying any data it contains. Do all of the vendors of smart LEDs use such preventive measures? Few of them, unfortunately.

One more thing to remember is that smart lighting security is a complex issue, and needs to be treated comprehensively if we want the applied mechanisms to be really effective. From hardware and software to wireless data exchange and cloud, there are several different areas where vulnerabilities might be found and exploited. They all interact with each other so it’s crucial to ensure that all of them are protected against potential attacks. After all, a chain is only as strong as its weakest link.

Similarly, interactions occur between different layers of the wireless communication process which are specified by the OSI model (more on OSI here). Solutions based on a combination of different technologies – e.g. with one technology taking care of the physical, network & transport layers, and another taking care of the application layer – often lack clear and agreed upon security architectures. As a result, such a patchwork system ends up being less secure than the individual technologies it is made up of. Not to mention that it is also much more difficult to update, and seamless over-the-air update capability is absolutely crucial for long-term security of smart lighting systems. For these reasons, ensuring true security is much easier in the case of full-stack technologies where relevant mechanisms can be implemented with the security by design approach.

Last but not least, if you really care about security then you should go for open standards and forget about proprietary solutions. Not only is a proprietary technology unlikely to be as secure as the one developed by multiple leading companies which share their expertise along the process, but the transparency of open standards guarantees that any potential vulnerabilities can be identified and addressed before someone decides to exploit them. In the case of proprietary technologies, it’s basically impossible to state whether one or another solution is secure. At most, it can be stated that it hasn’t been broken so far. But only open standards receive the scrutiny and attention that is necessary for true security.