The 'Internet of Things' is a buzzword which is becoming more and more prevalent in today’s society. This is mostly due to the rise of crowd funding schemes and an insurgence of low power, highly capable microcontroller platforms such as Arduino.

The Equity Kicker expects 33 billion devices connected by 2020 with a large portion of them falling under the IoT umbrella term and Forbes are predicting some pretty mind-bending revenue estimates over the next few years.

Many of these devices are greatly enhanced by increased connectivity to the internet where they have access to large amounts of cloud based computing power.

The problem facing start-up companies

One problem facing hardware vendors, and in particular, the small start-up companies is that they design a piece of hardware, which likely connects back to cloud servers (either to process data or grab the latest firmware) and then those devices are handed to sub-contractors for manufacturing and eventually their customers, malicious or otherwise.

This can add up to a rather large attack surface and, as a business, they potentially have a lot invested in each product. It’s therefore important to consider the hardware design as being instrumental in protecting their intellectual property.

> See also: Apple and how to become an 'Internet of Things' hardware company

The last thing they want is to see a cheap clone of their product showing up on eBay or to have their server-side infrastructure compromised because someone has found a flaw in the software.

Many attackers are going to go after the low hanging fruit, things like web apps running on the device, unencrypted traffic between the product and the cloud or attacking our servers directly. These methods are well-known and covered elsewhere in detail so what I want to do here is look at the hardware itself and highlight some techniques and checks which can be easily employed during the design/production stage in order to make life difficult for an attacker.

Locking down your intellectual property

The simplest and probably most obvious method of protecting your investment is to prevent end users from getting access to the software running on the device. This is probably where most of the value lies within an embedded application.

If an attacker can gain access to the binary, including bootloader, they can then reverse engineer the program in an attempt to find further vulnerabilities, bypass licensing/software restrictions, copy any custom algorithms or even use it to flash a clone of the hardware which they can then sell at a reduced price.

> See also: The Internet of Things and security: is it time to slow down?

Modern microcontrollers such as ARM’s Cortex and Atmel’s AVR range often have lock bits or read-out protection fuses which, when set, will prevent a debugger from reading the flash memory. These protections are extremely effective because once a device has been programmed with the protection enabled, the only way to unlock the device is to erase the entire chip.

For example, any attempt to read from a locked ARM microcontroller will result in a bus error and if the read protection is subsequently disabled then the flash memory is automatically erased leaving an attacker with a blank chip and a non-operational device.

The specific method for locking down your code and disabling the debug port will be described in the datasheet for the particular microcontroller in question. As you can see this will offer decent protection for your software and will deter all but the most tenacious attackers. There are, of course, techniques which can be employed by an attacker in an attempt to bypass these restrictions as well as to bypass any security checks your software may do during normal operation.

The most notable of these attacks would be clock glitching, where an attacker may be able to bypass security checks done by the system by injecting extra clock cycles which are beyond the processor’s limit.

Traditionally, these attacks have been quite difficult, requiring specialist knowledge and hardware; while this is still the case for high-speed processors, an attack against a low speed (sub ~50MHz) microcontroller might be achievable for a determined attacker with a small budget. This is not a hard and fast rule however, as was demonstrated by the XBOX 360 glitch attack.

A serious attacker may well go to considerable lengths to bypass the security measures which have been put in place but there are certain decisions which can be made during the design process of a product which are of little cost but can set the bar high enough to make an attacker’s job complicated and expensive, possibly unfeasibly so.

Choosing the right package

The type of physical package chosen for the main processor/microcontroller can actually be an important decision from a security standpoint as well as from a design standpoint. In the 90’s and early 00’s many boards used DIP (Dual Inline Package) ICs and EEPROMS were commonly socketed.

This made it easy for anyone with basic electronics knowledge to remove the chip and download the data. EEPROMs commonly held configuration data which could be overwritten in order to change the functionality of the device. Many car ECUs used this method to store fuel and ignition timing data leading to a market for 'chipped' ECUs running custom maps.

Since then, we have seen an increased requirement for smaller, faster devices due in no small part to the increased prevalence of mobile computing (smartphones, tablets, etc.).

These devices have been pushing the limits of the manufacturing process leading to some impressive devices. This has meant that surface mount devices have become the norm and processor/microcontroller ICs have been getting smaller and smaller while also getting faster. It is now possible to package several technologies from different manufacturers into the same physical package.

This not only reduces the overall size needed for the PCB but also, as an added bonus, reduces the physical attack surface of the device and makes it almost impossible for an attacker to gain access to data busses, IO pins and clock pins etc.

For a small IoT start-up it is likely to be unfeasible to have one of these PoP (Package on Package) devices created, however, most microcontrollers including a range of ARM, Freescale and Atmel devices all offer their devices in a range of small, pin less packages including QFN (Quad Flat No-lead) and BGA (Ball Grid Array).

BGA packages especially are known to be difficult to design for, often requiring extra PCB layers and more complicated testing techniques however, this can be turned into an advantage from a security viewpoint because it allows vendors to use the inner layers to route the data busses. These data busses may be transferring sensitive information such as passwords or encryption keys while the device is in operation.

> See also: Will the Internet of Things be more damaging to security policies than BYOD?

Sniffing the data on a board within which, the data busses have been buried is going to be difficult, couple this with the use of ICs with no exposed pins means an attacker is going to require specialist tools and equipment in order to extract data. An attacker may be put into a catch 22 situation where, the only way to capture data is to remove the chip, but in doing so, it is likely to damage the component making normal operation impossible.

Storing sensitive data securely

If your device needs to store sensitive data such as passwords or encryption keys then there are specialist ICs which make this process more secure. Devices like the ATSHA204 from Atmel are specifically designed to handle secure authentication, validation and data storage. Devices like these can be used to authenticate the currently installed software and encrypt the download of updated firmware. It is also possible to use a device like this to keep tight control of the manufacturing process.

Using the one-time-programmable bits to store a manufacturer ID means that the software can validate the hardware and ensure that it is genuine. These devices also provide a level of control over who can produce the hardware including the quantity they can manufacture and will help prevent counterfeit devices being made by unauthorised manufacturers.

It is a good idea when storing especially sensitive data, such as payment information or encryption keys, that you implement some kind of tamper-evident mechanism which wipes any stored secrets when the product is opened.

This can be in the form of a simple switch and battery backup which detects when the case is opened and causes the microcontroller (or crypto IC) to zero out the passwords and encryption keys when it is tripped.

As you can see, there are several decisions which can be made during the design phase which will increase the security of the hardware and make it unfeasibly difficult for a hobbyist level attacker to gain access to the IP or sensitive data. Of course the software running on the device needs to be hardened against common attacks as well. If security is considered throughout the design process of both software and hardware then we should see many well-designed products coming to market which protect both the vendors and their customers.

Sourced from Joel Clark, security consultant and researcher, MWR InfoSecurity