A hacker may be born or may be made. Let put this argument to debate sometime later, but in an engineer’s perspective, the early years of his or her ability to found out loop and loopholes in the system is a god given gift. It could be used for good or for evil and the sides are to be chosen. Let’s foray into the good part of an engineer who has been working to save us from security vulnerabilities which are sometimes overlooked even by experts.This article is written based on the insights given by Mohammed Pota, Hardware Security Researcher and Nitesh Malviya, Security Consultant, Payatu.
Starting with Hardware security
It has been found that the security standards are evolving but well established (most threats and their styles are known) and across the globe. Of all the security threats, software and cybersecurity seems to have stolen the limelight. There is not much emphasis on hardware security. “Even if you ask an engineer in the security domain if he knows about vulnerabilities in the hardware side of devices, they would still be wondering if the hardware could be hacked w.r.t IoT security”, says Mohammed.
Converging the concerns
IoT has changed a lot in the past five years. The devices are increasing year by year and predicted to reach 20 billion devices against 8 billion devices today. This brings to an accurate conclusion that is security is not established on the initial layer, there could be a ripple effect across the many numbers of devices connected to the network. This could pave a way to access to deeper components especially in hardware which an outsider is not supposed to. In electronics five major communication protocols namely UART, I2C, SPI and JTAG between chips at hardware layer takes place. One must know that encryptions must be implemented even this minute stage during IoT product development lifecycle. Most of the times, the keys are to be stored securely and most of the time they are stored in plain text. If someone gets access to breaking this encryption one can crack into the firmware stored in EEPROM and change the commands to their will.
Going beyond usual examples
UART is one of the hardware interfaces for debugging any device and could be used for IoT devices as well. If a hacker is able to read what information is sent through the UART chip, one can know what is run by the firmware. This could be read and firmware made malicious to devices made by the same company and sold to masses in case a hacker finds a vulnerability. Another example surrounding Bluetooth communication is also interesting. When the Bluetooth communication happens, communications can be intercepted between the mobile application and IoT device in the ecosystem. Though blue jacking on BLE based communication is easier than Bluetooth itself, the attacker can reverse engineer the protocols and change the properties of the IoT device or a product to anything he likes to. A smart bulb connected to BLE could be an easy target though codes and commands controlling the behavior are unique for particular IoT devices. The intercepted packets exchanged on Bluetooth are replaced with the codes and commands written by the hacker himself and Once hacked, the device could be operated remotely (switching on or switching off).
Security breach in proprietary products
In the world of security, there are chances that propriety vendors can also be at the risk of vulnerabilities if they haste product development in the market just not to miss the deadlines. Many companies also try to make their platforms unique and code quite creatively in order to make their products stand out without being copies by the competitor. Interestingly this also leads to vulnerabilities. If an attacker really wants to know the firmware inside a smartwatch and let’s say he succeeds in doing so, all he has to do it simply flash his version firmware and we are back to square one. Many hackers do this by sending in electrical signals in the chip pins and test their outputs and study their patterns before hacking or flashing the firmware.
Making sure it’s not hackable
In the real world, experts can only make sure that their devices are not least possible. At the chip level, there are few things that can safeguard the whole device. While flashing the firmware, one can make sure that they tick the read-only button and proceed with rest of the procedure. This will make sure it is a read-only chip (especially in a PSOC chip.). the other way is to use a shorting method where if someone tries to re-flash the firmware, the pins short and the chip is no longer available for operation. Not every company can afford a PSOC chip but this in one way.
It is possible to make devices secure on a design perspective but not from a technological perspective which has already been build. Generally, firmware extraction accesses are denied, the firmware cannot be removed. The trick is again in the design and designing better security at this stage really helps secure IoT devices at various level upwards.
For more such interesting stories, read more.
To know more, attend Mohammed Pota and Nitesh Malviya workshop on “WORKSHOP ON HOW TO PERFORM HARDWARE REVERSE ENGINEERING“ at EFY Conferences 2018