Security in IoT is a process that relies on continuous security across five key dimensions of an IoT service. These five attributes are Secure Boot, Secure Firmware over the Air, Secure Physical Interface and APIs, Secure Physical Transport Layer and Robustness. Here, Mats Andersson, the senior director of technology for short range wireless at u-blox, explains to Robin Duke-Woolley, the chief executive of Beecham Research, the importance of each.
Robin Duke-Woolley: What is u-blox’s approach to security for IoT solutions?
Mats Andersson: We define five principles for security, also referred to as the five pillars of security. All current and future products should support these five principles.
The first one is Secure Boot. This is about the start-up software. If you cannot rely on the software you are running at start-up, then other security measures are not worth much.
RDW: Do you use root of trust in Secure Boot?
MA: Yes we do, to have a secure device identity to start with. That is very important to define so that you can know that it is this device that is talking to the world around it. Then of course the root of trust provides basic keys that cannot be tampered with. For Secure Boot, you need a normalised start-up process that has a key from somewhere. That key should not be able to be modified. Even if it is a public key you should not be able to modify it. So, there is a need to have a secure storage for that key and also a need to be able to show that this Secure Boot is the root of everything for booting up the system. Clearly, it is essential it cannot be tampered with or changed because otherwise you lose the root of trust for that.
The second principle is Secure FOTA (firmware over the air). This enables secure firmware updates. If you have a security problem in a device, we want to make sure you get the right update to fix that. We have a secure FOTA service today, and we’re still working on it to improve it further. It will be rolled out in new products over time. Not all modules are supported today but the plan is for more and more to be covered.
RDW: When talking about modules, what sort of modules do you mean? For example, are all cellular modules supported with Secure FOTA or not yet?
MA: Not all are supported yet but we have a wide range of short and long range modules that we offer. Short range includes Bluetooth and Wi-Fi. Regarding cellular modules, newer ones are being supported for secure FOTA from the beginning. Some older ones many not have the features in them that allow them to be supported. So this is more to do with generations of modules than anything else. For u-blox in short range, it is a bit different. Cellular modules are always connected to a network. On the other hand, short range modules – Bluetooth Low Energy modules for example – may not be connected to the network at all. For these, we need some sort of proxy to download from the central server and then download to each individual device. So there are different issues for different products.
Also, Cat M and NB-IoT cellular modules will not talk very much to the network and have very low bandwidth. This has a specific challenge that if you want to upgrade the firmware over the air, the time taken versus the power available creates new difficulties. So, the issues in providing FOTA are specific to the particular hardware and specific arrangements need to be created for each type in order to conform to the principle.
The third principle is Secure Physical Interfaces and APIs (application programme interfaces). Because we make modules that companies use within their products, we have physical interfaces and APIs to our modules. We want as much as possible to make those secure. So for example, a customer’s host can control our modules and there must be an authorised access for that. Then there are other interfaces, like a debug interface, that needs even higher restrictions.
RDW: Is there a standards issue for that?
MA: The physical interface for a host to access the module will be something like UART, SPI, USB. In that case, there will be some form of authentication of the interface, with only the right authentication a user will be able to access the module.
There are specific interfaces like a debug interface. In that case, you are depending on the hardware the module is built into to support the debug interface. For example, sometimes we use a third-party chip. They might have a debug port that does not support authentication at the debug interface. In that case, we cannot add authentication, but on our own chips we do have this possibility for the future to add hardware support for authentication from the beginning. The debug interface can be important for support purposes. If the debug interface is disabled, should there be a problem in the product in operation and it needs to be returned for inspection, the ways to access the product are limited.
The fourth principle is Secure Physical Transport Layer. This is about securing the data from the source to the destination somewhere in the cloud. To secure the whole path, from the data source to the destination, requires both authentication and encryption of the link from one end to the other. Typically, we use protocols like TLS or DTLS to do that. That uses certificates to verify that you are talking with the right server, and there also might need to be certificates in the module that the server can trust the module as well. So, it goes in both directions. When you are authenticated you can use that certification information to encrypt the link as well so that no one can get in the middle of the link and carry out attacks on the server.
RDW: Do you have secure keys for the transport layer as well?
MA: Yes, we do. For the secure transport layer that may need to be a bit deeper because the customer might want to install the certificates that he has. For them we need to have the facility to install those certificates in a secure way in the device during the customer’s production and then lock them forever in the device.
RDW: Can you give an example of when a customer might want to use their own certificates?
MA: I can give an example from the short range world. We make Wi-Fi and Bluetooth short range modules. For the solution, the customer provides the cloud service which in turn is running on a cloud service provider’s facility, such as Amazon or Microsoft Azure. The customer and/or the cloud service provider have their own requirements about the certificates. So in that case, they provide a certificate which needs to run inside our module.
RDW: So the customer or service provider’s security certificate needs to pass through your customer’s application?
MA: Yes. The security certificate in this case is essentially part of the customer’s application. In the Secure Boot case, we provide the keys and all that is needed because it is us that guarantees the right software. In that case it is us that provides the certificates and the secure keys. So it’s a bit different here.
The fifth principle is Robustness, which may seem a bit strange as part of a security framework. This relates to activities like spoofing and jamming. That’s a big topic in wireless of course. In the GPS world, for example, it is rather common that people try to spoof the signal – trying to tell the service provider that they are somewhere other than where they actually are. Spoofing the satellite signals is more difficult in encrypted message links, but still an issue. Then there is jamming, which is about disturbing the link completely – trying to send an erroneous signal to block out the normal communication.
RDW: So how do you deal with those particular challenges?
MA: There are various things we can do. Firstly, we can detect that we are spoofed or jammed. We can tell the customer’s application that there is someone trying to do that. One example of this might be to use other means to clarify the situation. So if you have a method of dead reckoning at the same time as you have a process using GNSS, if they are not agreeing then it raises the issue. You can also use more complex algorithms for that purpose.
RDW: How can you deal with jamming?
MA: Jamming can be more difficult to deal with than spoofing. It could be a very broad band of disturbance. For example, on our radio communication link you may not get any real signal at all if it is really badly jammed. By having very good radios and very good filtering it can be more resilient to jamming. It means detecting the real signals from the noise.
RDW: Are there other ways you can deal with jamming as well?
MA: Yes there are. The protocols that are used for the connectivity might also support dealing with jamming by using counter-measures. For example, Bluetooth low energy is a good example with frequency hopping. It can hop to other frequency bands. There might also be ways to do something in the protocols to find a frequency band that avoids disturbances that you expect could be jamming. Bluetooth does that by hopping. Some more advanced Wi-Fi supports that as well. Of course, some jamming can be very difficult to handle at all. Then it is important to detect that it is ongoing, and tell the customer’s application that in this case there may be a need to do something else. Use another radio, for example.
RDW: So those are the five principles and ublox is progressively introducing those into new modules. Do the most recent modules have all of these?
MA: That depends. Some of the newest ones just coming out now will have most of them. In short range, we have introduced a Wi-Fi module now that has Secure Boot and the Secure Transport Layer to start with, but does not have Secure Interfaces right now because we do not see that as important in that particular case – it does not have a lot of interfaces.
RDW: So for different use cases there will be different priorities.
MA: Yes, different priorities. There will always be products that do not need everything. Maybe some of the interfaces are not secured because they are not such as high priority. Also, maybe some of the measures cannot be performed on the device because it has limited processing capabilities for example. You decide intentionally to take some of those things away as not so important for the specific use case.
RDW: So these principles represent almost dimensions that you can add or take away from as appropriate for each use and each new module?
MA: Yes. When we make decisions for new products, we always look at those five principles. If we make an exception from it we need to explain why we are doing that. So the five principles are a sort of rule book to start from and then if we do an exception from those, there is a reason for doing that. It is the framework we use.
