THE DARK SIDE OF SMART LIGHTING FRAMEWORKSA Security Review

The Internet of Things can possibly change the world, pretty much as Internet did. On one side, if each device, gadget and every familiar part of the traditional home has started to be outfitted with smart hardware, conversely hackers are already in the news for rupturing 'web associated TV's, smart camera frameworks and even the smart lights. This article analyzes the threats connected with one classification of IoT's: Smart Lighting Systems, by making the conceivable attack vectors and proposing a few defenses to mitigate the risks associated with them.

-Parul SharmaCybersecurity Graduate Scholar

New York University

SMART LIGHTING SYSTEMSIn fact, a Smart lighting system is one that controls a group of smart bulbs over a wireless network. The entire thought behind such a framework is controlling a lighting situation with as much ease and intuitiveness as could be expected under the circumstances. Comprehensively, a smart lighting framework can be categorized into following categories:

Centrally Controlled Smart Lighting System: Smart lighting frameworks that uses bridges or hubs to make communication possible between the client and the knobs. The bulbs interact with one another utilizing protocols, for example, ZigBee.

Master/ Slave Smart Lighting System: Other smart lighting frameworks utilize a master/slave procedure, with one master knob taking control of the various globules in the lighting environment by means of 6LoWPAN or 802.15.4 mesh network.

ASSETS ON RISKParent Network Credent ials: Authentication credentials for any network is always a vital asset. The disclosure of Wi-Fi Key to which Smart bulbs are connected can be a huge concern. Hence preventing an attacker from getting unauthorized access to WLAN should be the primary goal of a secure smart lighting system.

Smart Knobs/ Persist ing Light : Lighting systems are meant to suppress darkness and hence persisting light, whenever needed, is an asset for this class of IoT?s. It should the goal of a secure smart lighting system to stop an unauthorized user from issuing an ?all lights off? instruction and causing a perpetual blackout condition.

THREA TSSEVERITY: HIGH

The smart l ight ing systems approve access ut i l izing a whitel ist of security tokens. In Some f rameworks, the secret whitel ist token is not random but rather the MD5 hash of the MAC address of the authorized

device, other than that , the tokens inside of whitel ist are produced just once at int roductory

setup.

SEVERITY: MEDIOCRETokens in whitel ist can't be un-registered. This can be an

enormous risk to Central ly Control led Smart Light ing System once a whitel isted device is misused.

SEVERITY: MEDIOCREIn some smart l ight ing f rameworks, Wi-Fi passwords are

shared between various knobs ut i l izing encoded communicat ion. Wi-Fi key can be t raded of f i f the encrypt ion qual if icat ions are hard coded in device

f irmware.

SEVERITY: LOWBlackout as an af teref fect of t raded of f third-party

plat forms, (for example, Facebook) synchronized with smart l ight ing f rameworks. The potent ial at tackers

could include social networking f riends making hacks just for the fun.

THREAT 1"The smart lighting systems approve access utilizing a whitelist of security tokens. In Some frameworks, the secret whitelist token is not random but rather the MD5 hash of the MAC address of the authorized device, other than that, the tokens inside of whitelist are produced just once at introductory setup."

POTENTIAL ATTACKERS: The potential assailants could incorporate neighbors, cheats or lawbreakers who are wanting to exploit dim surroundings to execute burglary or other crimes.

RISK- High: Attackers can acquire the MAC Address from ARP cache, and after that burn through every hash and issue 'all lights off' directions to the bridge and then cause an unending power outage.

DEFENSE 1: Use abundantly advanced mechanism to produce the whitelist. A proposed solution is including a discretionary number or a nonce during the process oaf authentication which must be util ized once for encrypted token. Other than that, the tokens in whitelist ought to have time limit after which the device should be verif ied once more. For every attempt of verif ication, the client which has lapsed tokens ought to issue a request to server for nonce. After the server/bridge has issued a nonce (pseudo arbitrary number and timestamp) to the client device, the device sends a register request with a hash (MAC_Add + Pswrd + Nonce). The server/bridge ought to not just util ize the hashed MAC address as tokens in the whitelist however the hashed (MAC_Add + Pswrd + Nonce). The nonce ought to be issued once the token in the whitelist get terminated (say, l ike clockwork) and the password can be the secret word for device that connects with the server/bridge and ought to be modif iable.

DEFENSE 2: Using key generator, which needs execution of a software (key generator) on the bridge to create keys for authentication. There is additionally a software in controll ing device which can show keys. The bridge and the individual device might share a same key database and they can have an algorithm to register the particular key for a particular t ime.

DEFENSE 3: Using OAuth 2.0, the devices are furnished with an access token that can be util ized to get to the smart l ights. This token is revocable and can be made to be refreshed occasionally.

Sequence Diagram Showing Communicat ion Between The Device & The Bridge

THREAT 2"In some smart lighting frameworks, Wi-Fi passwords are shared between various knobs utilizing encoded communication. Wi-Fi key can be traded off if the encryption qualifications are hard coded in device firmware."

POTENTIAL ATTACKERS: The potential attackers for this situation can be the neighbors, programmers or digital culprits who are needing an entrance to a WLAN for executing an online misrepresentation or other digital violations.

RISK- Mediocre: Reverse engineering the firmware can prompt leakage of the encryption details and subsequently Wi-Fi key divulgence. This will allow an attacker unauthorized access to the WLAN. This might prompt further assaults. The assailant might access sensitive data on the network. This might even trade off the security of other ?Internet of things? devices in the network as most of the other appliances acknowledge messages from a trusted network with no confirmation.

DEFENSE: Use WI-Fi password word as a part of the validation key. This will wipe out the reliance on f irmware hard-coded encryption.

THREAT 3"Tokens in whitelist can't be un-registered. This can be an enormous risk to Centrally Controlled Smart Lighting System once a whitelisted device is misused."

POTENTIAL ATTACKERS: The potential attackers could incorporate any individual who can get an unauthorized access to the enlisted device in the whitelist and is wanting to access the WLAN for some fishy reasons.

RISK- Mediocre: If the registered device get lost or is misused by another user, it can bring about unauthorized devices being enrolled in the whitelist, and the entire framework could get exposed.

DEFENSE 1: Tokens in whitelist ought to be required to be re-authenticated after a while (say, 1 week). Contrarily, tokens should to be labeled as expired on the off chance that they don't pass the verif ication.

DEFENSE 2: Also, the framework can be made more adaptable by providing an administrator interface, and enable privileged user to modify the whitelist table.

THREAT 4"Blackout as an aftereffect of traded off third-party platforms, (for example, Facebook) synchronized with smart lighting frameworks. The potential attackers could include social networking friends making hacks just for the fun. "

POTENTIAL ATTACKERS: The potential attackers could include social networking friends making hacks just for the fun.

RISK- Low: Using IF This Then That or basically IFTTT, fully black pictures tagged to the victim can bring about the bulbs to radiate no light and cause a total blackout .

DEFENSE 1: Setup communication strictly when a client is approved. Shades should execute only if an approved user has tagged the pictures.

DEFENSE 2: Audit the tagged pictures for dim shades before permitting IFTTT to change the shade of the bulbs.

"The lighting industry was almost the same from last couple of decades until smart lighting systems came up with the advent of the Internet of Things. These smart lighting systems are not only efficient in terms of the technology which it uses but also consumes less energy and therefore saves a lot of bucks for its users. But on the contrary, these smart lighting systems has placed the security of its users on a huge risk. A loophole in this system could fetch the WiFi credentials for a hacker, or could lead to a total blackout suitable for trespassing. This article presented a precise security analysis of the smart lighting systems. It highlighted the threats that smart lighting frameworks can pose, rated the severity of the risks associated with those threats and presented solutions to patch the security loopholes in the system. "

-Parul Sharma