March 5, 2019 at 17:36S for Security: Internet Security of Things and reports at InoThings ++ 2019
“Chef, we have a security hole!”
- Well, at least something is safe with us ...
Hello, Habr!
In the comments to the previous post about InoThings ++, they expressed the opinion that on the Internet of Things there is a more important area for discussion than government intervention - this is the area of ensuring device security. From all points of view.
I can argue here with only one thing - that a discussion of security issues should be held in a round table format; for this reason, we will leave the round table as is, on the need (or unnecessity) of national standards and, in general, government interference in industry, but we will talk about security separately.
Why is security generally considered in IoT as something separate and specific, unlike security in classical IT systems?
Yes, in general, because IoT systems are similar to classic ones only on the part of the user who sees beautiful pictures on the monitor screen or controls a light bulb from a smartphone - but inside, at a low level, they are completely, completely different.
And, unfortunately, we still gulp many times over with authors of products who do not understand the differences in approach and problems.
The “Internet of things” is, first and foremost, a story about affordable, cheap, compact, economical, and therefore extremely massive devices connected to local or global data networks.
What does this mean in practice?
• Usually,wireless connection . In wire we trust, of course, only wire is expensive; those who made a wired smart home understand that this means a major overhaul with the laying of low voltage in all corners. And if the wire cannot be laid at all?
Actually, the rapid development of IoT began with the advent of cheap, economical and long-range wireless connections - from home Wi-Fi and BLE to LoRaWAN, Sigfox, NB-IoT and so on. Connections that allowed saturating a certain space with sensors without bothering with their power and connection.
However, radio is not only convenience, but also a curse. If in order to connect to the wire, neighbors need to open the locks on your door, then they not only “hear” your wireless home almost always, but can also jam it, or even fake it.
• As a rule, extremely economical operating modes of the radio channel - a device without a constant power supply must be protected by a battery. Saving on the radio channel results in the fact that updating the device’s firmware by air is either impossible at all, or meaningless due to the fact that one episode of the update consumes tens of percent of the available battery.
Accordingly, the initial quality of the code and protocols acquires extremely high significance - if a fatal hole is discovered in them, the manufacturer, of course, will be able to upload a new file to his website, but there will be no sense in it.
• Typically low-power , low-power processors. A typical IoT sensor nowadays is built on processors of the class from STM32L0 to the younger STM32L4, and simply due to limitations in memory and processing power (as well as the radio channel, see above) may not pull complicated authorization, authentication and other protection schemes . Moreover, low power can also mean the lack of “extra” memory necessary for updating firmware over the air - the unreliable radio channel means the inability to roll the firmware directly into a “live” flash, and there may not be any memory to save it in a separate area with subsequent rewriting of the working firmware .
And over all this, mass and ubiquity spreads its wings - which in practice means the owner has no effective control over access to devices.
When you had four Wi-Fi devices in your house — a router, a laptop, and two smartphones — the problem of losing them was not very acute, because none of them was a throwable incident.
When you have three or four dozen smart bulbs, switches, temperature sensors and the devil in your house what else - you will most likely send another burnt out or just an old light bulb to the trash without even thinking that it continues to reliably store the key in your flash from your wifi network.
Moreover, if we are not talking about the scale of the apartment, but the cottage site, hotel or factory - you do not even control access to IoT devices. Anyone can unscrew your light bulb, drain the access keys from it and screw it back in half an hour - and you won’t even notice it.
Devices can be cloned. You can read keys and certificates from devices. Modified firmware can be uploaded to devices.
The question here is not that all this could not be done with a Wi-Fi router - it is possible, of course. The issue is the transition from quantity to quality: with the promised exponential increase in the number of IoT devices, such attacks become meaningful and realizable. In fact, the story with IP cameras is repeated - while there were few of them, no one even thought that cameras with the same hole in the firmware would be enough to make sense to write a script that collects them into a giant botnet that could flood GitHub with Twitter
How it ended - you all know .
In classical information security, it is believed that if an attacker got full physical access to the protected device - well, in general, this is not the end, but everything is bad. In IoT in this context, “everything is bad” - this is not the result of someone’s malicious deeds, but the permanent and initial state of the system.
At InoThings ++, we, among other things, no doubt want to talk about this too - and how to make it clear to the developer that IoT brings completely new threat models, and talk about what to do about it.
I will present some reports.
An introductory report on the problems of protecting IoT devices and new threats specific to IoT, with an analysis of both Russian legislation and recommendations that have already been issued - as yet not requirements - of foreign organizations, including NIST , ENISA , IIC and others (links under the names not just links, but to the relevant documents - I really, really recommend reading them if you have anything to do with the development of IoT devices).
This report is simply a must have for integrators and developers who have recently entered the IoT market and have not yet fully realized the possible consequences of this. There is no choice here - these are things that you simply cannot not know about the existence of, and if you do not understand it today, tomorrow it may end in disaster for you and your business, for which you simply will not have time to prepare.
It’s not at all a technical, but also an important report - that we are now living in a blissful time, when every manufacturer can whisper in his devices what his heart desires, and there will be nothing for him.
More precisely, about the fact that this time will soon end - the need for legislative changes related to IoT and smart devices in general has matured, and the industry will still receive its GDPR here.
The first (necessary, but not sufficient) step to the security of IoT systems is writing reliable code. One way to increase its reliability is to comply with standards developed in industries that are decades older than IoT — for example, the “automotive” MISRA C code quality standard. MISRA C
compliance with itself and the use of static code analyzers, of course, do not guarantee you absolute reliability. - however, it can save you from a rather large number of errors, starting with banal carelessness, copy-paste and typos. Unfortunately, the practice of writing reliable code is very poorly spread among embedded programmers - and I hope that Philip will inspire at least some of the conference attendees to try to implement these practices in their work.
Another way to increase the reliability of the code is instead of encouraging shooting on your own legs and other natural selection of type C languages, switch to languages that were originally conceived as more reliable and do not allow you to make a lot of mistakes (I now write with all responsibility, as a person, yesterday at two at night, catching a stack overflow event that occurred at random moments, sometimes after tens of minutes of active firmware operation).
However, how bright the prospects are, the foggy and present of such languages - for example, Rust, the main candidate for the role of the future standard in the field of embedded software, for most practicing programmers belongs to the category “I heard, it's cool, but what for do I have now?”. This is especially facilitated by the traditional hype curve, along which Rust travels - it climbed to its top, being openly unprepared for serious practical use, after which many developers simply stopped monitoring its future fate.
So, in fact, in the report, Eugene will tell you what the current fate of Rust is, why it can already be considered as a working language and how many kilometers of nerve endings it will cost you to use it here and now.
And finally, a purely practical report - about what it takes to ensure trust in your devices, if you have installed them already quite a few hundred pieces, and at the same time know for sure that at any time at least several dozen of them are in the cabinets, that you forgot to lock and in which at any moment anyone can get in, merge the firmware and fill it with something like the same device, but not yours, but it.
Moreover, it is not enough to control these devices - they must first be deployed, which from the point of view of authentication can also be a rather nontrivial task.
So, all these reports - as well as many others - can be heard at the InoThings ++ conference, and what is especially valuable is not just to hear, but to end their speeches at the end of the speech and take them on the sidelines to continue the conversation. Actually, this is what makes a lively visit to technology conferences valuable - looking at a recording of a performance or an album on a slideshow half a year later, you can’t get up and ask for more details at that moment, take the speaker to a cup of coffee to talk in more detail about his projects, and so on and so forth.
Therefore, come. Tickets currently cost 15 thousand rubles , and believe me, for a conference of this level and with such speakers - this is very modest.
- Well, at least something is safe with us ...
Hello, Habr!
In the comments to the previous post about InoThings ++, they expressed the opinion that on the Internet of Things there is a more important area for discussion than government intervention - this is the area of ensuring device security. From all points of view.
I can argue here with only one thing - that a discussion of security issues should be held in a round table format; for this reason, we will leave the round table as is, on the need (or unnecessity) of national standards and, in general, government interference in industry, but we will talk about security separately.
Why is security generally considered in IoT as something separate and specific, unlike security in classical IT systems?
Yes, in general, because IoT systems are similar to classic ones only on the part of the user who sees beautiful pictures on the monitor screen or controls a light bulb from a smartphone - but inside, at a low level, they are completely, completely different.
And, unfortunately, we still gulp many times over with authors of products who do not understand the differences in approach and problems.
The “Internet of things” is, first and foremost, a story about affordable, cheap, compact, economical, and therefore extremely massive devices connected to local or global data networks.
What does this mean in practice?
• Usually,wireless connection . In wire we trust, of course, only wire is expensive; those who made a wired smart home understand that this means a major overhaul with the laying of low voltage in all corners. And if the wire cannot be laid at all?
Actually, the rapid development of IoT began with the advent of cheap, economical and long-range wireless connections - from home Wi-Fi and BLE to LoRaWAN, Sigfox, NB-IoT and so on. Connections that allowed saturating a certain space with sensors without bothering with their power and connection.
However, radio is not only convenience, but also a curse. If in order to connect to the wire, neighbors need to open the locks on your door, then they not only “hear” your wireless home almost always, but can also jam it, or even fake it.
• As a rule, extremely economical operating modes of the radio channel - a device without a constant power supply must be protected by a battery. Saving on the radio channel results in the fact that updating the device’s firmware by air is either impossible at all, or meaningless due to the fact that one episode of the update consumes tens of percent of the available battery.
Accordingly, the initial quality of the code and protocols acquires extremely high significance - if a fatal hole is discovered in them, the manufacturer, of course, will be able to upload a new file to his website, but there will be no sense in it.
• Typically low-power , low-power processors. A typical IoT sensor nowadays is built on processors of the class from STM32L0 to the younger STM32L4, and simply due to limitations in memory and processing power (as well as the radio channel, see above) may not pull complicated authorization, authentication and other protection schemes . Moreover, low power can also mean the lack of “extra” memory necessary for updating firmware over the air - the unreliable radio channel means the inability to roll the firmware directly into a “live” flash, and there may not be any memory to save it in a separate area with subsequent rewriting of the working firmware .
And over all this, mass and ubiquity spreads its wings - which in practice means the owner has no effective control over access to devices.
When you had four Wi-Fi devices in your house — a router, a laptop, and two smartphones — the problem of losing them was not very acute, because none of them was a throwable incident.
When you have three or four dozen smart bulbs, switches, temperature sensors and the devil in your house what else - you will most likely send another burnt out or just an old light bulb to the trash without even thinking that it continues to reliably store the key in your flash from your wifi network.
Moreover, if we are not talking about the scale of the apartment, but the cottage site, hotel or factory - you do not even control access to IoT devices. Anyone can unscrew your light bulb, drain the access keys from it and screw it back in half an hour - and you won’t even notice it.
Devices can be cloned. You can read keys and certificates from devices. Modified firmware can be uploaded to devices.
The question here is not that all this could not be done with a Wi-Fi router - it is possible, of course. The issue is the transition from quantity to quality: with the promised exponential increase in the number of IoT devices, such attacks become meaningful and realizable. In fact, the story with IP cameras is repeated - while there were few of them, no one even thought that cameras with the same hole in the firmware would be enough to make sense to write a script that collects them into a giant botnet that could flood GitHub with Twitter
How it ended - you all know .
In classical information security, it is believed that if an attacker got full physical access to the protected device - well, in general, this is not the end, but everything is bad. In IoT in this context, “everything is bad” - this is not the result of someone’s malicious deeds, but the permanent and initial state of the system.
The security issue in IoT is not tomorrow's issue. This is a problem today. If you do not solve it, tomorrow it will become not a problem, but a disaster.
At InoThings ++, we, among other things, no doubt want to talk about this too - and how to make it clear to the developer that IoT brings completely new threat models, and talk about what to do about it.
I will present some reports.
 | Sergey Paryev Rostelecom-Solar “The need to implement built-in information protection mechanisms in IIoT devices ” |
An introductory report on the problems of protecting IoT devices and new threats specific to IoT, with an analysis of both Russian legislation and recommendations that have already been issued - as yet not requirements - of foreign organizations, including NIST , ENISA , IIC and others (links under the names not just links, but to the relevant documents - I really, really recommend reading them if you have anything to do with the development of IoT devices).
This report is simply a must have for integrators and developers who have recently entered the IoT market and have not yet fully realized the possible consequences of this. There is no choice here - these are things that you simply cannot not know about the existence of, and if you do not understand it today, tomorrow it may end in disaster for you and your business, for which you simply will not have time to prepare.
 | Kirill Mityagin Newsky IP Law “ The legal vacuum of the Internet of things - what changes in laws are needed for IoT? " |
It’s not at all a technical, but also an important report - that we are now living in a blissful time, when every manufacturer can whisper in his devices what his heart desires, and there will be nothing for him.
More precisely, about the fact that this time will soon end - the need for legislative changes related to IoT and smart devices in general has matured, and the industry will still receive its GDPR here.
 | Philip Handelyants PVS Studio “ Static analysis and writing quality code for C / C ++ for embedded systems ” |
The first (necessary, but not sufficient) step to the security of IoT systems is writing reliable code. One way to increase its reliability is to comply with standards developed in industries that are decades older than IoT — for example, the “automotive” MISRA C code quality standard. MISRA C
compliance with itself and the use of static code analyzers, of course, do not guarantee you absolute reliability. - however, it can save you from a rather large number of errors, starting with banal carelessness, copy-paste and typos. Unfortunately, the practice of writing reliable code is very poorly spread among embedded programmers - and I hope that Philip will inspire at least some of the conference attendees to try to implement these practices in their work.
| Eugene Ponomarev " Rust instead of C for programming ARM Cortex-M " |
Another way to increase the reliability of the code is instead of encouraging shooting on your own legs and other natural selection of type C languages, switch to languages that were originally conceived as more reliable and do not allow you to make a lot of mistakes (I now write with all responsibility, as a person, yesterday at two at night, catching a stack overflow event that occurred at random moments, sometimes after tens of minutes of active firmware operation).
However, how bright the prospects are, the foggy and present of such languages - for example, Rust, the main candidate for the role of the future standard in the field of embedded software, for most practicing programmers belongs to the category “I heard, it's cool, but what for do I have now?”. This is especially facilitated by the traditional hype curve, along which Rust travels - it climbed to its top, being openly unprepared for serious practical use, after which many developers simply stopped monitoring its future fate.
So, in fact, in the report, Eugene will tell you what the current fate of Rust is, why it can already be considered as a working language and how many kilometers of nerve endings it will cost you to use it here and now.
 | Evgeny Boger Wiren Board " Authentication of devices on Linux by hardware key in top-level systems " |
And finally, a purely practical report - about what it takes to ensure trust in your devices, if you have installed them already quite a few hundred pieces, and at the same time know for sure that at any time at least several dozen of them are in the cabinets, that you forgot to lock and in which at any moment anyone can get in, merge the firmware and fill it with something like the same device, but not yours, but it.
Moreover, it is not enough to control these devices - they must first be deployed, which from the point of view of authentication can also be a rather nontrivial task.
InoThings ++ 2019
So, all these reports - as well as many others - can be heard at the InoThings ++ conference, and what is especially valuable is not just to hear, but to end their speeches at the end of the speech and take them on the sidelines to continue the conversation. Actually, this is what makes a lively visit to technology conferences valuable - looking at a recording of a performance or an album on a slideshow half a year later, you can’t get up and ask for more details at that moment, take the speaker to a cup of coffee to talk in more detail about his projects, and so on and so forth.
Therefore, come. Tickets currently cost 15 thousand rubles , and believe me, for a conference of this level and with such speakers - this is very modest.