IoT Security Infographic – Privacy, Authenticity, Confidentiality and Integrity of the Sensor Data. “The Invisible Asset”
By David Gascón, CTO of Libelium.
Security in the IoT is one the main concerns for municipalities as Smart Cities projects start being a reality. In the next article we will expose what is the security proposal developed by Libelium for its sensor devices and gateways: Waspmote, Plug & Sense! and Meshlium
In the current article we get into the four main features of Security:
Privacy: ensure that only the desired sensor devices and gateways are part of the network
Authenticity: ensure that the supposed sender is the real sender
Confidentiality: ensure that the data is only readable by the proposed destination
Integrity: ensure that the information contained in the original message is kept intact
Device to Device (Symmetric Encryption) [Encryption Level 1 – E1]
The end nodes implement a first encryption level at the link layer. All the nodes belonging to the same network share a common pre-shared key. This avoid external devices joining the sensor network (ensuring privacy) or watching the information contained in the packets being sent as it is encrypted (ensuring confidentiality). This encryption process is driven in Waspmote and Plug & Sense! by special electronic hardware included in the radio modules. AES 128b is the most used algorithm in this first layer.
Device to Gateway (Symmetric Encryption) [Encryption Level 2 – E2]
In a Smart City there are many different sensor networks working at the same time, for example we may find the Smart Parking nodes sending data in parallel to the Smart Environment or the Smart Water sensor devices. As all them may share the same E1 key used in the link layer, a new security mechanism is added, this time by using symmetric encryption in the Networking / Application layer – E2.
Now every single node in the network has its own private key (ensuring authenticity) and the Gateway (Meshlium) contains every single key of the devices to be able to decrypt the packets sent. The information goes encrypted from each node to the Gateway so the intermediate nodes can not access to it (ensuring privacy and confidentiality). Adding a sequence number + random internal seed we can perform the checksum to ensure that the data contained has not been altered (ensuring integrity).
The encryption process in Waspmote and Plug & Sense! is driven by software libraries included in the API and run by the MCU. AES 256b is the most used algorithm. Normally it is used in combination with E1 security layer so we get a E1 + E2 security scheme.
Device to Cloud (Symmetric Encryption) [Encryption Level 3 – E3]
This is similar to E2 but instead of having the keys located in the Gateway they are stored in the Cloud. This allows to use different Gateways (trusted or not trusted) as the information goes encrypted through them.
The encryption process is normally driven by software libraries run by the MCU. AES 256b is the most used algorithm. Normally it is used in combination with E1 so we get a E1 + E3 security scheme. The information goes encrypted from each node to the Gateway so the intermediate nodes or the Gateways can not access to it.
Gateway to Cloud (Secure Web Server – SSL-HTTPS-SSH) [Encryption Level 4 – E4]
The Gateway (Meshlium) use SSL certificates to send the information to the different Cloud Servers. It is the same security scheme as we use with our browsers when we connect to our bank website.
Most common combination scenarios:
E1 + E2 + E4
E1 + E3 + E4
The most secure scenario would be the one using combination of all of them: E1 + E2 + E3 + E4 although it would reduce the payload (we would be sending less bytes of information per packet).
Prior to start with the software encryption with AES 256 we need to share a key between each node (origin) and the Gateway or the Cloud Server (destination). To do so we can encrypt the new key using RSA 1024 using both Public/Private keys. This way, we ensure authentication, confidentiality and message integrity (as we add also a seed along with the key to generate randomness in the packet transmission). Once we get the shared key we will use it to start encrypting the sensor information as seen in the previous diagram as AES it ensures the maximum performance and and minimum message overload.
The same process is done when we want to renew the AES key.
Common security issues solved with these 5 Encryption Levels:
Access Control (Privacy)
By using AES 128 in the link layer we ensure that only nodes with the shared key can access to the routing capabilities of the sensor network. If a strange node sends a message to the network the message will be discharged in the first hop so no extra communication resources will be used. The AES 128 algorithm is implemented in the same radio using specific hardware, for this reason the information will be automatically discarded and not even send to the microcontroller. This provides an extra layer of security as the main control unit of the node will not be interrupted from performing basic tasks or event not awaken from the sleep mode (what ensures optimum energy usage).
Authentication
By using its own private keys (AES / RSA) each node ensures the authenticity of the of origin. The Gateway or the Cloud may store all the public and shared keys of the devices so that they can check the packet has been sent by the supposed origin.
Data Confidentiality
By doubling encryption of the messages we ensure that first that only the nodes which form part of the network can see the general routing packets (AES 128 in the link layer) and after that we establish an encryption tunnel by direct P2P encryption between origin and destination (using AES 256).
Data Integrity
The new library uses hash algorithms such as MD5 and SHA to create the checksum of the message and to ensure that the final information received correspond with the original sent.
Data Freshness (avoiding packet injection)
Each packet has an exclusive seed which protects the gateway from receiving several identical packets which could be injected from a third party.
Non-repudation
By signing the messages with RSA keys we have also the legal proof that the information sent really was sent by an specific sensor node and not by other. Important in the future when all the sensitive sensor information has to be legally approved.
Why Libelium sensor nodes are immune to IoT Gateways attacks
The security of its IoT devices is the greatest commitment of Libelium. As IBM X-Force announced last week that there were some vulnerabilities in the Meshlium IoT Gateway, new actions were taken immediately by our R&D team offering a new software version released on August 1st.
The Libelium sensor platform was initially created as an open source developing platform ready to be used by researchers and developers to have total control on the sensor nodes and the IoT Gateways. That is how six years ago the Libelium sensor platform became a worldwide IoT market solution.
From the outset, we focused on giving to the developers the right tools (API + SDK) so that they could have total control in any respect of the configuration and performance. Regarding the security of the data gathered and transmitted our devices offer the possibility to create up to 5 levels of encryption as it is published in the article titled IoT Security Infographic – Privacy, Authenticity, Confidentiality and Integrity of the Sensor Data. “The Invisible Asset”. These levels are composed by symmetric encryption techniques using the encryption technique AES 256 on the link, network and application layers, and the RSA 1024 on the application layer.
When these encryption techniques are properly set by developers they may achieve the four main security features for its IoT projects: Privacy to ensure that only the desired sensor devices and gateways are part of the network; Authenticity to warrant that the supposed sender is the real sender; Confidentiality to guarantee that the data is only readable by the proposed destination; and Integrity to make sure that the information contained in the original message remains intact.
To ensure all these features nodes must be properly configured, however it seems IBM did not applied the right configuration for their demo at the Black Hat 2018 Conference. In these tests the researchers did not apply the symmetric encryption between the node and the Cloud platform using the AES 256 technique. This encryption, along with a signed and seeded packet (RSA 1024), ensures that the information could not be corrupted or changed as the attackers cannot open the packet and access to the info, because the keys are stored on each node and the Cloud server, not in the Meshlium IoT Gateway. In this sense, potential hackers could not even perform a “man in the middle” attack as the packets are signed and have several internal counters to ensure no retransmissions from invalid sources that were performed.
Using in that demo a basic sensor node configuration scheme instead of applying the complete encryption layers, provided by Libelium, shows a not trustworthy environment, far away from real case developments. This situation may lead to think that this simple configuration scheme was created to easily make some assumptions about security leaks on the information of the sensor nodes when they simply do not exist when the right configuration is performed.
In conclusion, when the security options are properly set, even if the network transmission or the IoT Gateway are compromised, the data will still be secured and it will not be possible to corrupt it or change it. The most important thing is not only to have the right tools, but also know how to configure and use them properly.