IoT and Security: an impossible union?
One of the most crucial questions to ask about the Internet of Things today is: does the IoT have a future despite its inherent lack of security?
Studies show that despite the obvious acknowledgment that this ecosystem is full of security breaches that can endanger its functioning, companies' interest in IoT does not go away. Indeed, in a pragmatic dynamic, organizations opt for the undeniable contribution that these technologies bring on their business and their methods of work compared to the dangers generally accepted as a fatality. A study by the institute 451 Research shows that 71% of organizations use data with the Internet of the Things and wish to increase their investments in this area for the next 12 months. However, cyber security remains the main obstacle to the emergence of new uses and a total adoption of these technologies.
This raises a question: can we really consider the security breaches found to be a fatality? Spoiler Alert: The answer is no! We will try to demonstrate that in this article.
The wrong example
The events described below are based on real facts. Any resemblance to cases and people you have already met is totally normal.
What Bobby has just done is actually much more dangerous than leaving the sublime house unattended. It has just created a huge gap on his local network by allowing anyone to connect to it. Today, there are robots capable of scanning all the IPv4 addresses of the world in less than 24 hours and trying to connect to them with widely used login / password ("root", "admin", "password", "12345 "," Qwerty "...). Bobby only followed an incomplete documentation that did not strongly suggested (or even encouraged) to change his login details. In addition to providing access to the video stream, Bobby’s connected objects will be potentially used by the robots to carry out attacks of which he will be recognized as responsible. Furthermore, all the connected elements in Bobby’s local network are now in danger. The strength of a chain depends on the strength of its weakest element and here, a very sensitive element has just been added.
But Bobby’s story is not over. He has just bought a gorgeous German car with a 4-ring logo. To open his car, he has nothing to do. It is enough to be near its vehicle with his electronic key in his pocket in order to open the car automatically (or just a button to press). This constructor had chosen not to encrypt the data of the key which allowed the opening. An interception of this RFID signal is sufficient to obtain the opening code which is found to be identical on millions of vehicles. A malicious person can thus recover this digital key and thus open and start more than 100 million vehicles in the world. On top of it, a vehicle theft without breaking traces is not covered by insurance.
The German manufacturer then chose to implement a HiTag2 encryption algorithm specifically designed for NXP
microcontrollers which were present in those vehicles. This algorithm, which dates from the late 1990s, takes today only 10 minutes to be bypassed with equipment costing less than 30 euros. Especially for all vehicles produced until 2016, the manufacturer's recommendation is to disable the hands-free mode of these keys ...
Want to know if your vehicle has been hacked?
If the vehicle refuses to open (except in case of battery problem) when the key button is pressed, the signal has already been intercepted and used. Indeed, in order to couple the new algorithms with a simple technique, the manufacturers have added a requests counter for opening controls in the vehicles microcontrollers. If this counter is not synchronized with the number of presses stored on the key, the opening command will not work.
Security in the IoT
The lack of security in the IoT is only a consequence of the business impact on the projects. The ever-shorter Time To Market and the willingness to "do IoT" by unscrupulous actors causes precipitation and mistakes that are easy to avoid.
There are special characteristics to this field that can make the security point of view a little less affordable than simple prototyping. With the multiplication of DIY (Do It Yourself) tutorials, lower prices on hardware (microcontrollers, sensors, telecommunication modules, cloud offer...) and their simplified programming interfaces it has become much more easier to create your own small communicating object. However, from a more industrial perspective, it is necessary to master more complex concepts to counter the specific faults of the connected objects.
There are 3 types of vulnerabilities:
- Hardware vulnerabilities
- Software vulnerabilities
- Communication flaws
Let us go beyond these generalities to glimpse the light at the end of the tunnel.
Hardware vulnerabilities
One of the hardware flaws that may seem trivial but which is actually the cause of many troubles is access to the debug interface. It is often necessary for a developer to retrieve information through these interfaces to track the progress of a program over time. The problem lies in the possibility of transferring sensitive information such as identifiers or frames of unencrypted data. The most sensitive objects are those that may need to be connected to a PC via USB. Some interfaces such as the Android Debug Bridge (ADB) even allow you to run commands on the object itself. It would be enough to disable this interface during the production of the objects so that it is impossible to access them.
A tool well known by electronic technicians can be the source of a total loss of control over connected objects. The JTAG (Joint Test Action Group) is a hardware interface allowing initially to test continuity on the circuit board roads (absence of short circuits). This tool is used to give access to all the input pins of the integrated electronic components. The objective is to perform black box tests on logic components, ensuring that the output signals comply with selected inputs. However, the strength of this tool is not limited to testing. It can also be used as a BDM (Background Debug Module) to emulate an embedded system and retrieve its internal signals. The use of these signals can allow to reconstitute sensitive data. It is even possible to reprogram the flash memory of objects with this tool and to implement its own code with a completely different behavior. This technique requires a particular connection that is not to be made available in the production version of the object in question.
In both cases, exploitation of the faults requires direct access to the hardware. A good practice consists in realizing a good packaging making it as difficult as possible to access the hardware, especially if the object does not need to be charged up. This must be combined with good management of the electromagnetic environment. It is important to know the environment in which the object will evolve to take countermeasures.
An increasingly popular concept in the latest generation of microcontrollers makes it possible to isolate the OS from the object and the application part. The concept of Safezone or Trustzone makes it possible to isolate physically the sensitive code which exploits the material in its whole and the application code. These codes will run on different parts of the hardware and the alteration of the application code will have very little impact on the overall object’s security.
Software vulnerabilities
In the embedded electronics world, the memory size is often reduced (a few KB) and this will cause quite a lot of worries.
For example, the programmer must often manipulate the memory to the order of magnitude of the register. Particular attention must be paid to memory overflow. As in programming on traditional architectures, these implementation errors can cause behaviors that are difficult to predict and it is one of the first software flaws that hackers are trying to exploit.
We have already mentioned the importance of changing the default login details that are often not encrypted on the device or in the telecommunications frames. It is a classic error that would be solved by asking the user to change his login details or he will no longer be able to use his material.
Another hardware constraint will have an impact on the software implementation. The microcontrollers are generally provided with a low computing power which is often adjusted according to the target application. This low computing power limits the possible cryptographic operations. The libraries required to use proven encryption algorithms are often too large for objects, which implies the emergence of new standards. Hash operations, symmetric or asymmetric encryption, are however possible using libraries of reasonable sizes but very difficult to interoperate. There are also a large number of open source projects in this direction whose reliability is difficult to assess.
The solution in vogue is to integrate cryptographic functions into the silicon of the microcontrollers or thanks to dedicate components. This allows not to reduce the available size with bulky libraries (especially if one device uses several libraries) but the drawback is that it definitively fixes the algorithms used. It is hard to imagine a technician unsoldering all the cryptographic components and replacing them with others in case of faults discovered on an algorithm.
The solution that seems best is the cryptography on the elliptic curves (implemented in the libuecc for example). These operations on discrete logarithms are simpler to perform than on integer similarities (RSA), but the resulting encryption is much more complex to break. It is estimated that a 200-bit key based on elliptic encryption is safer than a 1024 bit RSA key.
The last software fault that happens to be very dangerous is the ability or not to update the software of a connected object. If a default is found, you need to be able to patch the fault found and not to leave an isolated infected device. To do this, you must implement the update’s signature and ensure that you have enough memory space. Signing helps to prevent a malicious person from using the update mechanism to take control of the object.
Communication flaws
This is the last step with concrete risks. Authentication is the first problem encountered regarding the huge quantity of devices. Methods like OAuth 2.0 or OpenID Connect 1.0 can be used to solve this problem, but for now they can only be used in HTTP. However, HTTP is not ideal for all use cases (such as device-to-device communications) and we often prefer CoAP or MQTT. The next challenge will be to implement effective authentication methods for these protocols.
The (very) great diversity of communication protocols makes interoperability very complex and requires a fairly long process of appropriation. Data integrity must also be considered when performing checksum or redundancy operations that are not necessarily native to certain protocols. The checksum consists of performing an operation on the data whose result is sent with the original data. On reception, the same function is applied to the data and it is checked that the results are the same.
The great success of LPWANs (Sigfox, LoRa, NB-IOT, Qowisio, etc.) also poses some problems. These low consumption, low-flow but very large-scale networks are experiencing an impressive growth (nearly 300 million euros of funds raised for Sigfox). These protocols are practical for certain use cases (Telemetry, heartbeat, ...) but we always need to think about the counterparts. The trend is to position oneself on one of these technologies without really knowing the limits. Sigfox is, for example, a network for transmitting a maximum of 140 messages per day of 12 bytes of payload. Sigfox does not provide any method for encrypting messages on the network layer. It is up to the developer to implement encryption steps during the telecommunication. Download messages to objects are very limited (only 4 8-byte messages). We must therefore forget the updates via this network. It will also be complex to transmit encryption keys by this means. LoRa is bi-directional but not simultaneous. The payload is about 242 bytes so this is also difficult to use for updates. However, the data are natively encrypted. These networks are designed to transmit messages over long distances (up to 40 km) and have a very good indoor penetration. They therefore have their advantages but complicate certain security measures.
Conclusion
The last element in the IoT ecosystem, Cloud platforms, has not been addressed because they represent the nodes of the system on which special attention has been given to security. If they are not managed by the organizations themselves, they are managed by web giants (Amazon, IBM, Microsoft, ...) which impose fairly strict security standards.
Safety in IoT is only a matter of good practices and the flaws noticed do not sound the death knell of the domain. It is enough not to rush to a young market just to say that "We are in!". Some issues are still being resolved but this is not so different from the classic internet. Some initiatives such as the Allseen Alliance or the Open Connectivity Foundation are even attempting to unify IoT communications protocols to define a single standard that can be understood by all elements of the ecosystem.
The consequences of bad security are of course more dramatic than the fate of our dear Bobby. The privacy of your data is no longer guaranteed. These may be used for commercial purposes without your knowledge. Your local network, though well protected, finds itself exposed to all attacks. These attacks can exploit your hardware for malicious purposes. For example, you can read what Dyn has recently experienced. In addition, you are responsible for the items you own, whether you are an organization or an individual. So take into account the danger and trust the actors who take care of the good practices.