Where are the key risks in RF and IOT systems and what steps do developers need to take to address them? By Dr Nick Wood.

We increasingly manage our lives via a bewildering array of technological devices and services and the IOT revolution offers us the promise of “everything connected” to make our lives simpler, freer, and healthier. However, our reliance on technology could also be a threat if malign actors can gain control of our devices and systems.

IOT devices have particular vulnerabilities, as they are typically based on limited resource devices where there may be limited features and capacity to implement advanced security.

Many devices use RF technology including Bluetooth or Wi-Fi and, in such cases, you are literally broadcasting your data for any snooper who wants to listen in.

Security designed in from the start

The first thing to note is that security is not something to be bolted on at the end of the design process as an afterthought. Security needs to be designed into a system from the start. Thinking about security should be integrated into the definition of the basics of the system. 

It is vital to begin by analysing the consequences of possible system breaches, entry points for an attacker, and the steps to be taken to mitigate any risks. Clearly not all systems carry the same level of risk. So, there is no one “right” level of security. The security for a medical or financial based system has different requirements to that of a simple monitoring system.

That said, you must always be careful. For example, a smart home system may primarily control the heating, and not seem particularly interesting. However, the data it generates can reveal when the owners are away on vacation and offer an opening for a burglary.

Entry points

Having decided what you are trying to protect against, the next step is to analyse where an attacker might gain entry to the system. The key is to take a wide-ranging approach to identifying the weakest link. For instance, you could design a highly robust architecture for the system yet neglect to adequately protect the step where devices are initially programmed in a subcontractors’ facility.

Transmission over the air

Although RF transmission may seem inherently insecure, it is rarely the prime weakness in a system. Most radio protocols incorporate suitable encryption such that even if a signal is intercepted, deciphering it would be immensely difficult.

Where vulnerabilities are more frequent and can enter a system is in initial configuration. This occurs when a Bluetooth device is first “paired” with another, or a network link is initially established. At this stage, devices often make themselves “open” for a period. This is when an opportunity might arise for an attacker.

If this setup can be done in a secure location, the risk is low. However, this is not always possible or practical. Typically, the weaknesses here are not inherent to the technology but due to weak implementation including default passcodes of 0000 or similar.

A further line of attack is exposed if systems are configured to allow updates or patches. This can be a valuable feature of a system. However, it also opens a window for malign code to be inserted into a system. Updates may be designed to address new, known security weaknesses, but can be a risk in themselves. The classic solution here is to implement end to end encryption, authentication and digital signing.

Keys, signatures and encryption

One important issue with IOT systems is their distributed nature. A device may communicate via Bluetooth to a phone.  That may in turn upload data over a cellular link, and onto a wired internet connection. Each link may be adequately secure. However, at each node on the network an opportunity for interception and interference can open, as data is forwarded from one link to another.

The best protection is to establish end to end encryption, authentication and digital signing, via a public-private key architecture. Under such a scheme, each device has a private key, and a related public key is made available to other parts of the system. The private key is used to authenticate the device, and thus the central system knows that it is truly the real end device communicating. Conversely, the system also has a public-private key pair, and the public key is then used to encrypt communications, so that only the central system can decrypt them using the private key.

In such a scheme, if data is intercepted midway, an attacker can’t really do anything with it. Digital signatures are used to ensure update packages are valid, and have not been tampered with, using keys combined with the data of the update package. Digital Signatures are widely used to validate Internet sites on PCs, but inside, there is a lot of “out of the box” support. A PC will come with a set of Root certificates securely pre-installed. In contrast, on an embedded system you will almost certainly have to implement the certificate handling processes yourself, at least for the time being.

There are cloud-based services that offer server-side support for encryption, authentication and digital certification, offered by large companies such Microsoft, Google and Amazon and others. Clearly using any such service relies on confidence in the relevant vendor.

Hardware support

Many of the newer devices available on the market have built-in hardware acceleration to support these cryptographic functions. They can also support secure key storage. Typically, keys can be written into a dedicated memory location, but never read out.

Even greater security can be achieved using hardware Secure Elements where encryption functions and keys are stored and executed in a separate device. This has two main advantages – firstly the security functions are clearly separated and encapsulated in a separate piece of hardware. Secondly the secure element is resistant to physical tampering. This means even complex hardware probing of the device is very unlikely to be successful in gaining access to the key data stored on board.

Key management

Key based security is only going to be as good as the security used when keys are generated and loaded in the first place. Whilst such a scheme can undoubtedly be a powerful asset, it is not trivial to load and manage all the relevant keys in a secure manner. For instance, bank cards, which use this kind of technique effectively, are handled in special secure locations where physical access is severely restricted. That may be overkill for some applications. Yet if system keys can be seen or manipulated at the start, any subsequent steps may be futile.

In conclusion

There will never be a “one size fits all” solution to the issue of RF and IOT security. Some of the techniques above will add significant cost and complexity to a solution and may not be justifiable. There will be trade-offs between useability and security, especially for any consumer-oriented solution.

However, it would be unwise to discount the creativity and persistence of the cyber-criminal. At the very least, any solution deserves a thorough analysis of the risks presented if a malign actor were to spy on data, interfere with or impersonate a device. 

A major security breach can cause real harm and irrecoverable reputational damage.

Author details: Dr Nick Wood, Director, Sales & Marketing, Insight SiP