This is the 3rd part in a series. The previous parts can be found here and here.
So far in our discussion, we have dealt with somewhat "normal" device classes, devices that largely we are familiar with technically. In this third part, we get well beyond that.
As discussed before, we're covering five device classes in this series:
In this article we will discuss the microcontroller class.
For many IoT scenarios, the first three classes provide a myriad of options, but reality is that there is a segment where those device classes don't work very well because of physical constraints (and potentially, cost). This is primarily where devices are deployed that do not have an easy power supply. Even a Raspberry Pi (class 1 or 2) requires a 5V power adapter, which is fine if we are near a power outlet. It becomes problematic when the device is deployed out in the field and by necessity has to operate on battery power.
We know how long a battery can last for a 32-bit+ device through the experience of our cell phones. If you don't make any calls, you may be able to get a couple of days out of the battery of a cell phone, but then it is time to recharge. What if I don't have that possibility?
Moreover, such devices may be deployed in places where there are not easy to service at all. They could be flow meters in gas or water pipelines. They could be soil composition or humidity sensors placed in agricultural fields. They may be embedded in walls or street surfaces, where deploying and replacing them requires construction crews. It is critical to extend life time as long as possible, up to five years, for instance.
For that you need a device that "sips" energy. That means a lower bit level for the processor itself, and also some interesting compromises for connectivity. Normal WiFi is way to energy demanding to work for this class of devices (if they cannot be connected by wire), so we see low-power wireless networks like SIGFOX and LoRa, which limit the transmission rate (~100 or so messages per day) as well as the size of each message (12 bytes for SIGFOX, for instance).
When you compromise on one end, you inevitably are going to lose something on the other: standard PKI encryption is either not going to work at all, or will be slow and drain battery power. As we saw above, we are constrained in connectivity as well, and low-power connectivity providers typically provide little to no security from the device to their network. We are likely to lose our end-to-end encryption and data integrity goals.
This is what the device class looks like when modeled. It is not that different from the GSM 32-bit+ device, where we had the Telco provider (including the inability to monitor the devices, since they are not on "our" network). However, at least in that case we had no problem running TLS over the communication, so the Telco provider only handled encrypted traffic. That is not the case with these low-power connectivity providers, where only from their network to our end-point do we have full strong encryption, but not from the device to the network (or inside of the low-power network). This means that the end point cannot distinguish between a manipulated message and a true message, nor does it have any guarantee that the message came from the device we think it came from.
This is problematic, because it means we cannot trust the data in any way. We just have to assume that it didn't get eavesdropped on, and that nothing got tampered with, or spoofed, or otherwise manipulated before it reached the end point. Since we also have no way to monitor the devices other than through the messages we receive, what we gain in power consumption, we clearly lose in security and integrity (let alone data privacy). This is not good.
To tackle this very problem, Laurent Gomez from our Security Research team in Southern France developed an encryption scheme specifically for this device class, in association with the University of Mannheim, well known for its cryptography expertise. A European patent has been awarded, an American one is pending. In a future blog we'll discuss in detail how it actually works - and its use cases well beyond data encryption alone - but for now we can share what it does for end-to-end encryption:
Each device is issued a secret key that is never shared. It then uses CMAC, a block cipher-based Message Authentication Code algorithm, to create intermediary keys (to allow for key revocation). This key is then used, together with the sequence number of the message and the device ID to create an encryption key and a hash key. The latter is used for integrity checks. The result of this is that each message for each unique device will have a unique encryption key. The message that is sent to our end point contains the encrypted data, a hash of the message with our hashkey, the sequence number of the message, and the device ID.
On the server-end, this is replayed when the message is received. The root key is retrieved (the server must know this) based on the device ID, and computes the steps the client has gone through either to 1) only check the integrity of the message without decrypting, or 2) check and decrypt. If the integrity check fails, we discard the message.
What this gives us, then, is data encryption, in a very power-efficient way. CMAC functions are very light compared to PKI, and similar in that way to hash functions. Think for instance of password hashing in web applications, where often 1,000s of passes of the hash function are used, without slowing down the logon process.
Moreover, what it also gives us is an ability to store our data encrypted, and only decrypt it on use or time of analysis. Since the integrity check through the hashkey allows us to verify the message without decrypting it, once this check has been achieved, we could decide to store the message while still encrypted. In fact, in a pilot project for a water and gas pipeline network, we only decrypt the messages on visualization of the data in the end user application.
As this scheme is designed for low-power, this should work for just about any device platform, as long as we can get our code onto the device. This will require the collaboration of hardware manufacturers, but with such cooperation, this scheme can secure the data sent from such devices.
The architecture used in pilot projects was as follows. We are looking to get this introduced into our IoT services on SAP Cloud Platform as standard. We will probably have more news about this in a few months. (Insert standard disclaimer here, etc. etc.)
I am really excited about this. This will absolutely help provide some relief in a device class that otherwise would give us major headaches. It restores the principle of end-to-end encryption that we believe so critical to ensure data integrity, and hides the data from all parties and components the message flows through before it reaches our end point. A pilot using WirelessHART connectivity suggests this is also an appropriate scheme to protect communication between devices connecting to an IoT gateway over IoT-specific protocols
There is one more interesting point in this, if you look at the diagram closely: while the connectivity between the device and the network provider goes over LPWAN and only has the data encryption, from the network provider to our end point, we add transport encryption (TLS) on top. This is a model we could potentially also apply in highly secure scenarios using 32-bit+ devices where TLS is possible from the device itself.
TLS is as good as we got, but it is not perfect. We have seen some vulnerabilities over the past few years in the most common implementations, and there have been issues with certificate authorities issuing certificates they shouldn't have, accidentally or otherwise. It will keep most bad actors at bay, but may not be sufficient against nation states. In such scenarios, considering added additional data encryption - using this scheme, for instance - may be a good idea, where it is critical the data transmission has to be secure.
Part 4: SCADA/ICS
So far in our discussion, we have dealt with somewhat "normal" device classes, devices that largely we are familiar with technically. In this third part, we get well beyond that.
As discussed before, we're covering five device classes in this series:
- "Dumb" 32-bit+ device
- Smart/Edge Processing 32-bit+ device
- GSM connected 32-bit+ device
- Microcontrollers
- SCADA/ICS, PLC systems
In this article we will discuss the microcontroller class.
For many IoT scenarios, the first three classes provide a myriad of options, but reality is that there is a segment where those device classes don't work very well because of physical constraints (and potentially, cost). This is primarily where devices are deployed that do not have an easy power supply. Even a Raspberry Pi (class 1 or 2) requires a 5V power adapter, which is fine if we are near a power outlet. It becomes problematic when the device is deployed out in the field and by necessity has to operate on battery power.
We know how long a battery can last for a 32-bit+ device through the experience of our cell phones. If you don't make any calls, you may be able to get a couple of days out of the battery of a cell phone, but then it is time to recharge. What if I don't have that possibility?
Moreover, such devices may be deployed in places where there are not easy to service at all. They could be flow meters in gas or water pipelines. They could be soil composition or humidity sensors placed in agricultural fields. They may be embedded in walls or street surfaces, where deploying and replacing them requires construction crews. It is critical to extend life time as long as possible, up to five years, for instance.
For that you need a device that "sips" energy. That means a lower bit level for the processor itself, and also some interesting compromises for connectivity. Normal WiFi is way to energy demanding to work for this class of devices (if they cannot be connected by wire), so we see low-power wireless networks like SIGFOX and LoRa, which limit the transmission rate (~100 or so messages per day) as well as the size of each message (12 bytes for SIGFOX, for instance).
When you compromise on one end, you inevitably are going to lose something on the other: standard PKI encryption is either not going to work at all, or will be slow and drain battery power. As we saw above, we are constrained in connectivity as well, and low-power connectivity providers typically provide little to no security from the device to their network. We are likely to lose our end-to-end encryption and data integrity goals.
This is what the device class looks like when modeled. It is not that different from the GSM 32-bit+ device, where we had the Telco provider (including the inability to monitor the devices, since they are not on "our" network). However, at least in that case we had no problem running TLS over the communication, so the Telco provider only handled encrypted traffic. That is not the case with these low-power connectivity providers, where only from their network to our end-point do we have full strong encryption, but not from the device to the network (or inside of the low-power network). This means that the end point cannot distinguish between a manipulated message and a true message, nor does it have any guarantee that the message came from the device we think it came from.
This is problematic, because it means we cannot trust the data in any way. We just have to assume that it didn't get eavesdropped on, and that nothing got tampered with, or spoofed, or otherwise manipulated before it reached the end point. Since we also have no way to monitor the devices other than through the messages we receive, what we gain in power consumption, we clearly lose in security and integrity (let alone data privacy). This is not good.
SAP encryption scheme for low-power devices
To tackle this very problem, Laurent Gomez from our Security Research team in Southern France developed an encryption scheme specifically for this device class, in association with the University of Mannheim, well known for its cryptography expertise. A European patent has been awarded, an American one is pending. In a future blog we'll discuss in detail how it actually works - and its use cases well beyond data encryption alone - but for now we can share what it does for end-to-end encryption:
Each device is issued a secret key that is never shared. It then uses CMAC, a block cipher-based Message Authentication Code algorithm, to create intermediary keys (to allow for key revocation). This key is then used, together with the sequence number of the message and the device ID to create an encryption key and a hash key. The latter is used for integrity checks. The result of this is that each message for each unique device will have a unique encryption key. The message that is sent to our end point contains the encrypted data, a hash of the message with our hashkey, the sequence number of the message, and the device ID.
On the server-end, this is replayed when the message is received. The root key is retrieved (the server must know this) based on the device ID, and computes the steps the client has gone through either to 1) only check the integrity of the message without decrypting, or 2) check and decrypt. If the integrity check fails, we discard the message.
What this gives us, then, is data encryption, in a very power-efficient way. CMAC functions are very light compared to PKI, and similar in that way to hash functions. Think for instance of password hashing in web applications, where often 1,000s of passes of the hash function are used, without slowing down the logon process.
Moreover, what it also gives us is an ability to store our data encrypted, and only decrypt it on use or time of analysis. Since the integrity check through the hashkey allows us to verify the message without decrypting it, once this check has been achieved, we could decide to store the message while still encrypted. In fact, in a pilot project for a water and gas pipeline network, we only decrypt the messages on visualization of the data in the end user application.
As this scheme is designed for low-power, this should work for just about any device platform, as long as we can get our code onto the device. This will require the collaboration of hardware manufacturers, but with such cooperation, this scheme can secure the data sent from such devices.
The architecture used in pilot projects was as follows. We are looking to get this introduced into our IoT services on SAP Cloud Platform as standard. We will probably have more news about this in a few months. (Insert standard disclaimer here, etc. etc.)
I am really excited about this. This will absolutely help provide some relief in a device class that otherwise would give us major headaches. It restores the principle of end-to-end encryption that we believe so critical to ensure data integrity, and hides the data from all parties and components the message flows through before it reaches our end point. A pilot using WirelessHART connectivity suggests this is also an appropriate scheme to protect communication between devices connecting to an IoT gateway over IoT-specific protocols
There is one more interesting point in this, if you look at the diagram closely: while the connectivity between the device and the network provider goes over LPWAN and only has the data encryption, from the network provider to our end point, we add transport encryption (TLS) on top. This is a model we could potentially also apply in highly secure scenarios using 32-bit+ devices where TLS is possible from the device itself.
TLS is as good as we got, but it is not perfect. We have seen some vulnerabilities over the past few years in the most common implementations, and there have been issues with certificate authorities issuing certificates they shouldn't have, accidentally or otherwise. It will keep most bad actors at bay, but may not be sufficient against nation states. In such scenarios, considering added additional data encryption - using this scheme, for instance - may be a good idea, where it is critical the data transmission has to be secure.
Part 4: SCADA/ICS
- SAP Managed Tags:
