0

The internet of things (IoT) devices have been around for a number of years now, but very few smart sensors have any decent level of data security. For many organisations the issue of data security and secure remote updates to legacy products has become of paramount importance. Unfortunately, many of the engineers who design sensor products have little or no understanding a security algorithms, leading to systems that can be easily hacked – the fiasco of the UK smart meter system is a good example.

 Algorithms to the rescue

Algorithms and mathematics are usually regarded by many organisations as ‘academic black magic’ and are generally overlooked as a solution for a robust IoT commercial application. Nevertheless, some of you may be surprised by how old the concept of algorithms actually are in solving real world problems.

A few weeks ago, I looked through my old PhD thesis and stumbled across a reference to one of world’s first documented algorithms from the 9th century mathematician, Al-Khwarizmi (where, the word ‘algorithm’ is derived from al-Khwarizmi’s name).

Al-Khwarizmi undertook pioneering work in algebra, which was popularized in his book, “al-Mukhtasar fi Hisab al-Jabr wa l-Muqabala” and altered society’s perspective of analyzing problems, be they a simple domestic chore or a complex mathematical concept.

 An excerpt from “Al-Mukhtasar fi Hisab al-Jabr wa l-Muqabala” for the solution to x^2 + 10x = 39.

Translation: For the squares and roots equal to a number, it is as saying: a square and ten of its roots is equal to thirty-nine dirhams. The solution is to halve roots, equal to five in this problem, then, multiplying the root by itself then this will be twenty-five. Then add it to thirty-nine and this will be sixty-four. Then take the square root, which will be eight and subtract from it half the root, which is five. The remainder is three and that is the root you are seeking and the square is nine.

I had forgotten (well, it was 14 years ago!) how elegant Al-Khwarizmi work actually was, and how I’m sure he would probably smile at the challenges that we’re facing today. Nevertheless, without his pioneering work, we wouldn’t have any of the IoT and security algorithms that we take for granted today.

Solutions in the 21st century

We’ve been pleasantly surprised by the rich offering from commercial IC vendors, such as: Atmel, NXP and Analog Devices in producing secure micro-controllers for the IoT market. Many of these micro-controllers include all of the necessary hardware encryption building blocks needed for building a secure IoT sensor, and some even offer a decent amount of processor power for data analytics algorithms.

Sounds ideal, right?

The Achilles heel of all of these solutions is how engineers implement them in a system. The micro-controller itself may be ‘secure’, but what about the system architecture (i.e. the algorithmic building blocks and and how they interact with each other). And what about encryption keys? How are they stored and updated? For the UK smart meter system mentioned above, the system just used one key for the whole system – not very secure ! It is this fact that is painfully overlooked by many, and as such, which eventually leads to the system being hacked and rendered useless.

In short, hardware based encryption technology is a great step in right direction for IoT device security, but without good understanding of encryption technology as part of the system architecture the solution is doomed to failure.

0
1+

It’s estimated that the global smart sensor market will have over 50 billion smart devices in 2020. At least 80% of these IoT/IIoT smart sensors (temperature, pressure, gas, image, motion, loadcells) will use Arm’s Cortex-M technology – where the largest growth is in smart Image sensors (ADAS) & smart Temperature sensors (HVAC).

IoT sensor measurement challenge

The challenge for most, is that many sensors used in these applications require a little bit of filtering in order to clean the measurement data in order to make it useful for analysis.

Let’s have a look at what sensor data really is…. All sensors produce measurement data. These measurement data contain two types of components:

  • Wanted components, i.e. information what we want to know
  • Unwanted components, measurement noise, 50/60Hz powerline interference, glitches etc – what we don’t want to know

Unwanted components degrade system performance and need to be removed.

So, how do we do it?

DSP means Digital Signal Processing and is a mathematical recipe (algorithm) that can be applied to IoT sensor measurement data in order to clean it and make it useful for analysis.

But that’s not all! DSP algorithms can also help in analysing data, producing more accurate results for decision making with ML (machine learning). They can also improve overall system performance with existing hardware (no need to redesign your hardware – a massive cost saving!), and can reduce the data sent off to the cloud by pre-analysing data and only sending what is necessary.

Nevertheless, DSP has been considered by most to be a black art, limited only to those with a strong academic mathematical background. However, for many IoT/IIoT applications, DSP has been become a must in order to remain competitive and obtain high performance with relatively low cost hardware.

Do you have an example?

Consider the following application for gas sensor measurement (see the figure below). The requirement is to determine the amplitude of the sinusoid in order to get an estimate of gas concentration (bigger amplitude, more gas concentration etc). Analysing the figure, it is seen that the sinusoid is corrupted with measurement noise (shown in blue), and any estimate based on the blue signal will have a high degree of uncertainty about it – which is not very useful if getting an accurate reading of gas concentration!

Algorithms clean the sensor data

After ‘cleaning’ the sinusoid (red line) with a DSP filtering algorithm, we obtain a much more accurate and usable signal which helps us in estimating the amplitude/gas concentration. Notice how easy it is to determine the amplitude of red line.

This is only a snippet of what is possible with DSP algorithms for IoT/IIoT applications, but it should give you a good idea as to the possibilities of DSP.

How do I use this in my IoT application?

As mentioned at the beginning of this article, 80% of IoT smart sensor devices are deployed on Arm’s Cortex-M technology. The Arm Cortex-M4 is a very popular choice with hundreds of silicon vendors, as it offers DSP functionality traditionally found in more expensive DSPs. Arm and its partners provide developers with easy to use tooling and a free software framework (CMSIS-DSP) in order to get you up and running within minutes.

1+
1+

With the advent of smart cities, and society’s obsession of ‘being connected’, data networks have been overloaded with thousands of IoT sensors sending their data to the cloud, needing massive and very expensive computing resources to crunch the data.

Is it really a problem?

The collection of all these smaller IoT data streams (from smart sensors), has ironically resulted in a big data challenge for IT infrastructures in the cloud which need to process

massive datasets – as such there is no more room for scalability. The situation is further complicated with the fact, that a majority of sensor data is coming from remote locations, which also presents a massive security risk.

It’s estimated that the global smart sensor market will have over 50 billion smart devices in 2020. At least 80% of these IoT/IIoT smart sensors (temperature, pressure, gas, image, motion, loadcells) will use Arm’s Cortex-M technology, but have little or no smart data reduction or security implemented.

The current state of play

The modern IoT eco system problem is three-fold:

  • Endpoint security
  • Data reduction
  • Data quality

Namely, how do we reduce our data that we send to the cloud, ensure that the data is genuine and how do ensure that our Endpoint (i.e. the IoT sensor) hasn’t been hacked?

The cloud is not infallible!

Traditionally, many system designers have thrown the problem over to the cloud. Data is sent from IoT sensors via a data network (Wifi, Bluetooth, LoRa etc) and is then encrypted in the cloud. Extra services in the cloud then perform data analysis in order to extract useful data.

So, what’s the problem then?

This model doesn’t take into account invalid sensor data. A simple example of this, could be glue failing on a temperature sensor, such that it’s not bonded to the motor or casing that it’s monitoring. The sensor will still give out temperature data, but it’s not valid for the application.

As for data reduction – the current model is ok for a few sensors, but when the network grows (as is the case with smart cities), the solution becomes untenable, as the cloud is overloaded with data that it needs to process.

No endpoint security, i.e. the sensor could be hacked, and the hacker could send fake data to the cloud, which will then be encrypted and passed onto the ML (machine learning) algorithm as genuine data.

What’s the solution?

Algorithms, algorithms….. and in built security blocks.

Over the last few years, hundreds of silicon vendors have been placing security IP blocks into their silicon together with a high performance Arm Cortex-M4 core. These so called enhanced micro-controllers offer designers a low cost and efficient solution for IoT systems for the foreseeable future.

A lot can be achieved by pre-filtering sensor data, checking it and only sending what is neccessary to the cloud. However, as with so many things, knowledge of security and algorithms are paramount for success.

1+
2+

When looking at undertaking a NPD (new product development) it’s always tempting to take short cuts in order make the development more attractive to management or a client. I’ve lost count as to the number of times that I’ve heard,

 If we had the budget and time, of course we’d do it properly.

The problem with this, is that after doing this several times, it becomes the norm, and taking short cuts and in order to potentially save money usually leads to more problems in the long run.

 Follow the yellow brick road

For those of you who remember the Wizard of Oz, following the yellow brick road led Dorothy to Emerald city. The NPD process is the same, and is nicely described on Wiki and many other great resources, so there’s no reason to ignore it. If you can’t get the information out of clients, propose a workshop or private session, where you can discuss all requirements and get a clear picture of the clients vision/expectations. Remember that before taking on any new development, you should undertake the task of defining specifications:

  •  User specifications: a document that specifies what the user(s) expects the product (e.g. software) to be able to do.
  •  Functional specifications: are requirements that define what a system is supposed to do. A functional specification does not define the inner workings of the proposed system, and does not include the technical details of how the system function will be implemented.
  • Technical specifications: based on the Workshops, User and Functional requirements, you can finally construct the technical specifications documentation. This document(s) will contain all technical details of how the system will be implemented, and usually includes tables, equations and sketches of GUI layouts and hardware block diagrams.
  • Review: the specifications and findings with the client, and make sure that they understand what they will be getting (i.e. the deliverables).

Although it’s tempting to ignore these steps and start playing with software, following the aforementioned steps keeps you focused and almost always leads to shorter development times.

About the author: Sanjeev Sarpal is director of algorithms and analytics at Advanced Solutions Nederland BV. He holds a PhD in signal processing and has over 20 years commercial experience with the design and deployment of algorithms for smart sensor applications.

2+