It’s hard to fathom why so many devices are being developed for the Internet of Things without a thought to security. When you consider the inherent security risks in connected environments, you’d expect IoT vendors to be scrambling to ensure that their devices are compliant and prevent data leaks and other such privacy breaches. As I explained in my recent presentation at LicensingLive! 2015, misplaced trust in the IoT’s complexity seems to be the main reason behind people’s laissez-faire attitude towards security.

In IoT we trust

How does trust manifest in the IoT? Is it enough to demonstrate a proven track record in a particular niche to be considered trustworthy?

The simple answer is that experience alone doesn’t guarantee security. When you enable a device, you’re creating totally new attack surfaces that are often beyond the expertise of the device manufacturer.

Consider an IoT-connected safe. Merchants deposit their cash; the cash gets registered, added up, and instantly credited to their account. Then, at the end of the day, the safe reports back to the transport company how much money is inside. This lets the transport company know the optimal time to collect the money (i.e., when it reaches a certain limit) so they can minimize the associated security risks.

The perfect crime

Of course, as Dan Petro and Oscar Salazar demonstrated at DefCon, not even IoT-connected safes are infallible. A determined enough hacker will see the standard USB port on the safe and try to mount an attack. All it takes is for them to insert a USB drive containing some scripts, and they can bypass the user interface, access the file system, and get to the money. Not only that, if they purge the records from depositing the money, it’s as if the money was never there to begin with! Thus, the trust I mentioned earlier is not just about ensuring that the money is secure; it’s also about protecting the accounting process.

A more promising way to gain trust in the IoT is to allow an independent lab to inspect the device and run a blackbox audit on it. This can reveal obvious security vulnerabilities relatively quickly, whereas a deeper analysis requires substantial effort to uncover the underlying issues, as Michael Auger and Runa Sandvik proved with their Black Hat presentation. As far as IoT devices go, sniper guns might not seem like the most obvious example, but those configurable via mobile app can be considered borderline IoT. The last thing you would want is someone tampering with parameters as sensitive as target distance, wind speed, temperature, and ammunition type.

Their blackbox audit determined whether:

  • The Wi-Fi passcode had adequate security
  • The web API used by the app employed authentication
  • The app supported digitally signed firmware updates

A full reverse-engineering revealed additional problems, such as hidden admin APIs and questionable root of trust management.

When it comes to understanding the security problems of a device, blackbox auditing is an incomplete solution that’s both costly, requires a lot of effort, and is therefore highly inefficient. A more preferable option would be to integrate security analysis into your IoT development process, taking into account the attacks you need to address and those you feel brave enough to disregard because they carry a lower risk.

Building a secure system

One of the key questions you should ask yourself when building a secure system is, “What do I really need to secure?” Remember, the more complex the system, the more likely it is to be exploited due to its extended attack surface. Protecting the shell around your device (e.g., using Secure Boot, application authentication, etc.), while important, does nothing to prevent a hacker from finding vulnerabilities in the code itself. By taking a focused approach, you can accurately verify the code and put it through a rigorous security audit.

Your code is a crucial piece of your application. If it didn’t behave correctly, or if the data produced was somehow compromised, it could hurt your brand. One way around that would be to ensure the application is capable of monitoring itself, as well as the configuration data it uses, for any tampering attempts. If you were responsible for a machine that sterilizes milk, for example, you would want to make sure that no one was tampering with the configuration settings. A self-monitoring application would be able to verify that these parameters are actually coming from the person controlling the device. Gemalto’s ongoing investment in enveloping technology makes it possible for IoT vendors to ensure the integrity of their application and verification of its data.

Tamper-proof = future-proof

A device’s longevity is dependent on your ability to issue updates in the event of bugs or security leaks. For this, you will need a secure way of verifying the update packet, so the code performing the verification is protected against any kind of modification. This verification also includes the secure provisioning of the root of trust – the public key used to verify all delivered modules. Doing so ensures that no one can introduce unauthorized firmware or software updates.

Trust no one

Taking a stand against exploits make it harder for the hacker to analyze your code. Whether you use encryption to ensure that only authorized personnel have access to your device, IP protection to prevent reverse engineering of crucial code, or some other security technique, the ultimate goal is the same: to create an application that’s harder to get into than Fort Knox.

Reconsider what you trust – don’t assume that connected environments protect your application by virtue of their complexity. Don’t assume that the physical isolation of a device makes it secure either. Sidestep these issues altogether by integrating both security analysis and secure update handling at the design stage of your application. Finally, be sure to protect the core of the device – your application and its data – by having it protect and monitor itself. With these security measures in place, you can rest assured that you won’t become the topic of discussion at the next Black Hat or DefCon!