S for Security: Internet Security of Things and reports on InoThings ++ 2019
- Chef, we have a security hole!
- Well, at least something is safe here ...
Hi, Habr!
In the comments to the previous post about InoThings ++, it was suggested that there is a more important area for discussion on the Internet of Things than state intervention - this is the area of ​​ensuring the safety of devices. From all points of view.
')
I can argue here with only one thing - that the discussion of security issues should be held in a round table format; for this reason, we will leave the round table as it is, on the need (or uselessness) of national standards and government intervention in general in the affairs of the industry, and let's talk about security separately.
Why is security generally considered in IoT as something separate and specific, unlike security in classic IT systems?
Yes, in general, because IoT-systems are similar to classic ones only from the side of the user who sees beautiful pictures on the monitor screen or controlling a light bulb from a smartphone - but inside, at a low level, they are completely, completely different.
And, unfortunately, we still repeatedly grieve with product authors who do not understand the difference in approach and problems.
“The Internet of Things” is, first of all, a story about affordable, cheap, compact, economical, and therefore extremely mass devices with connection to local or global data networks.
What does this mean in practice?
• Typically wireless connection . In wire we trust, of course, only the wire is expensive; those who have made themselves a wired smart home understand that this means an overhaul with laying a weak corner in all corners. And if the wire can not 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. Compounds that allowed saturate a certain space with sensors, do not bother with their power and connection.
However, radio is not only a convenience, but also a curse. If, in order to connect to the wire, the neighbors need to open the locks on your door, then they will not only “hear” your wireless home almost always, but can effectively jam it, or even fake it.
• As a rule, extremely economical modes of operation of the radio channel - a device without a constant power supply should be protected. The savings on the radio channel translate into the fact that updating the device firmware over the air is either not possible at all or meaningless due to the fact that one update episode relives tens of percent of the existing battery.
Accordingly, the initial quality of the code and protocols acquires an extremely high value - if a fatal hole is found in them, the manufacturer, of course, will be able to upload a new file to his site, but there will be no sense from it.
• As a rule, low-power low-power processors . Typical IoT'shny sensor in our time is built on processors from STM32L0 class to younger STM32L4, and simply due to limitations in memory and computational power (as well as radio channel, see above) can not pull complex authorization schemes, authentication and other protection . Moreover, low power can mean the absence of “extra” memory necessary for updating the firmware over the air - the unreliability of the radio channel means that it is impossible to roll the firmware right into the “live” flash, and it may not be possible to save it into a separate area followed by overwriting the working firmware .
And above all this, the wings spread mass and omnipresence - which in practice means that the owner does not have 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 serious, because none of them are related to being thrown in passing.
When you have three or four dozen smart light bulbs, switches, thermal sensors, and the devil knows what else - you most likely will send the next burnt or just an old light bulb into the garbage, without even thinking that it continues to safely store it in your flash from your wifi network.
Moreover, if we are talking about the scale not of the apartment, but of the cottage plot, hotel or factory - you do not even control access to IoT-devices. Anyone can unscrew your light bulb, merge the access keys out of it and twist it back in half an hour - and you won't even notice.
Devices can be cloned. Keys and certificates can be read from devices. Modified firmware can be poured into devices.
The question here is not that all this could not be done with a Wi-Fi router - you can, of course. The question is in the transition of quantity to quality: with the promised exponential growth in the number of IoT devices, such attacks become meaningful and realizable. In fact, the story with IP-cameras is repeated - as long as there were few of them, nobody even thought that there would be enough cameras with the same hole in the firmware to make it worthwhile to write a script that collects them into a giant botnet that can take GitHub for a couple of Twitter.
How it ended - you all know .
In the classical information security, it is believed that if an attacker received 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” is not the result of someone’s malicious deeds, but a permanent and initial state of the system.
On InoThings ++, we, among other things, no doubt want to talk about it - and how to let the developer know that IoT brings with it completely new threat models, and talk about what to do with it.
I will present some reports.
Introductory report on the issues of protection of IoT-devices and new threats specific to IoT, with an analysis of both Russian legislation and recommendations that have already emerged — not yet 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 that you read them if you have any relation to the development of IoT devices).
This report is just a must have for integrators and developers who have recently entered the market for IoT devices and have not yet fully realized the possible consequences of this. There is no choice here - these are things you don’t know about the existence of, and if you don’t understand it today, tomorrow it may end in disaster for you and your business, for which you simply won’t have time to prepare.
Absolutely not technical, but also an important report - that now we live in a blissful time, when each manufacturer can navigate in his devices what his heart desires, and he will have nothing for it.
More precisely, about the fact that this time will soon end - the need for changes in legislation related to IoT and smart devices in general, has matured, and the industry will get its GDPR here.
The first (necessary, but not sufficient) step towards the security of IoT systems is to write a reliable code. One way to increase its reliability is to comply with the standards developed in industries that are older than IoT by decades - for example, the “automotive” quality standard of the MISRA C code.
Observance of MISRA C and the use of static code analyzers in itself, of course, does not guarantee you absolute reliability - however, it can save you from a rather large number of errors, starting with banal inattention, copy-paste and typos. Unfortunately, among the programmers of embedded systems, so far the practice of writing reliable code is extremely poorly distributed - and I hope that Philip will inspire at least some of the conference visitors to try to implement these practices in their work.
Another way to increase the reliability of the code is instead of encouraging shooting at your own feet and other natural selection of type C languages ​​to switch to languages ​​that were originally conceived as more reliable and not allowing you to make a lot of mistakes (I am writing with all the responsibility as a person yesterday at two one o'clock in the morning catching the stack overflow event that occurred at random moments, sometimes after tens of minutes of active firmware operation).
However, how bright are the prospects, just as vague and the present of such languages ​​- so, Rust, the main candidate for the role of the future standard in the field of embedded software, for most practicing programmers falls into the category of “heard, cool, but what the hell is it for me now?”. Especially this contributes to the traditional curve of HYIP, on which Rust travels - it climbed to its top, being frankly unprepared for serious practical use, after which many developers simply stopped following its further 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 workable 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 costs to ensure confidence in your devices, if you have already installed quite a few hundreds of them, and at the same time absolutely sure that at any moment at least a few dozen of them are in the cabinets, who forgot to lock and into which anyone can climb at any time, merge the firmware and fill it with seemingly the same device, just not yours, but its.
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 trivial task.
So, all these reports - as well as many others - can be heard at the InoThings ++ conference, and that is especially valuable - not only to hear, but at the end of the speech, to take their authors by the elbow and take them to the lobby to continue the conversation. Actually, it is precisely this and valuable live attendance of technology conferences - looking half a year later with one eye a recording of a speech or an album on a slider, you will not be able to get up and ask for clarification of that moment, take the speaker to a cup of coffee to talk more 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 here ...
Hi, Habr!
In the comments to the previous post about InoThings ++, it was suggested that there is a more important area for discussion on the Internet of Things than state intervention - this is the area of ​​ensuring the safety of devices. From all points of view.
')
I can argue here with only one thing - that the discussion of security issues should be held in a round table format; for this reason, we will leave the round table as it is, on the need (or uselessness) of national standards and government intervention in general in the affairs of the industry, and let's talk about security separately.
Why is security generally considered in IoT as something separate and specific, unlike security in classic IT systems?
Yes, in general, because IoT-systems are similar to classic ones only from the side of the user who sees beautiful pictures on the monitor screen or controlling a light bulb from a smartphone - but inside, at a low level, they are completely, completely different.
And, unfortunately, we still repeatedly grieve with product authors who do not understand the difference in approach and problems.
“The Internet of Things” is, first of all, a story about affordable, cheap, compact, economical, and therefore extremely mass devices with connection to local or global data networks.
What does this mean in practice?
• Typically wireless connection . In wire we trust, of course, only the wire is expensive; those who have made themselves a wired smart home understand that this means an overhaul with laying a weak corner in all corners. And if the wire can not 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. Compounds that allowed saturate a certain space with sensors, do not bother with their power and connection.
However, radio is not only a convenience, but also a curse. If, in order to connect to the wire, the neighbors need to open the locks on your door, then they will not only “hear” your wireless home almost always, but can effectively jam it, or even fake it.
• As a rule, extremely economical modes of operation of the radio channel - a device without a constant power supply should be protected. The savings on the radio channel translate into the fact that updating the device firmware over the air is either not possible at all or meaningless due to the fact that one update episode relives tens of percent of the existing battery.
Accordingly, the initial quality of the code and protocols acquires an extremely high value - if a fatal hole is found in them, the manufacturer, of course, will be able to upload a new file to his site, but there will be no sense from it.
• As a rule, low-power low-power processors . Typical IoT'shny sensor in our time is built on processors from STM32L0 class to younger STM32L4, and simply due to limitations in memory and computational power (as well as radio channel, see above) can not pull complex authorization schemes, authentication and other protection . Moreover, low power can mean the absence of “extra” memory necessary for updating the firmware over the air - the unreliability of the radio channel means that it is impossible to roll the firmware right into the “live” flash, and it may not be possible to save it into a separate area followed by overwriting the working firmware .
And above all this, the wings spread mass and omnipresence - which in practice means that the owner does not have 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 serious, because none of them are related to being thrown in passing.
When you have three or four dozen smart light bulbs, switches, thermal sensors, and the devil knows what else - you most likely will send the next burnt or just an old light bulb into the garbage, without even thinking that it continues to safely store it in your flash from your wifi network.
Moreover, if we are talking about the scale not of the apartment, but of the cottage plot, hotel or factory - you do not even control access to IoT-devices. Anyone can unscrew your light bulb, merge the access keys out of it and twist it back in half an hour - and you won't even notice.
Devices can be cloned. Keys and certificates can be read from devices. Modified firmware can be poured into devices.
The question here is not that all this could not be done with a Wi-Fi router - you can, of course. The question is in the transition of quantity to quality: with the promised exponential growth in the number of IoT devices, such attacks become meaningful and realizable. In fact, the story with IP-cameras is repeated - as long as there were few of them, nobody even thought that there would be enough cameras with the same hole in the firmware to make it worthwhile to write a script that collects them into a giant botnet that can take GitHub for a couple of Twitter.
How it ended - you all know .
In the classical information security, it is believed that if an attacker received 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” is not the result of someone’s malicious deeds, but a permanent and initial state of the system.
The security issue in IoT is not the problem of tomorrow. This is the problem of today. If it is not solved, tomorrow it will become not a problem, but a disaster.
On InoThings ++, we, among other things, no doubt want to talk about it - and how to let the developer know that IoT brings with it completely new threat models, and talk about what to do with it.
I will present some reports.
 | Sergey Pariev Rostelecom-Solar "The need to implement embedded information security mechanisms in IIoT devices " |
Introductory report on the issues of protection of IoT-devices and new threats specific to IoT, with an analysis of both Russian legislation and recommendations that have already emerged — not yet 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 that you read them if you have any relation to the development of IoT devices).
This report is just a must have for integrators and developers who have recently entered the market for IoT devices and have not yet fully realized the possible consequences of this. There is no choice here - these are things you don’t know about the existence of, and if you don’t understand it today, tomorrow it may end in disaster for you and your business, for which you simply won’t 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? " |
Absolutely not technical, but also an important report - that now we live in a blissful time, when each manufacturer can navigate in his devices what his heart desires, and he will have nothing for it.
More precisely, about the fact that this time will soon end - the need for changes in legislation related to IoT and smart devices in general, has matured, and the industry will get its GDPR here.
 | Philip Handelyants PVS Studio “ Static analysis and writing of high-quality C / C ++ code for embedded systems ” |
The first (necessary, but not sufficient) step towards the security of IoT systems is to write a reliable code. One way to increase its reliability is to comply with the standards developed in industries that are older than IoT by decades - for example, the “automotive” quality standard of the MISRA C code.
Observance of MISRA C and the use of static code analyzers in itself, of course, does not guarantee you absolute reliability - however, it can save you from a rather large number of errors, starting with banal inattention, copy-paste and typos. Unfortunately, among the programmers of embedded systems, so far the practice of writing reliable code is extremely poorly distributed - and I hope that Philip will inspire at least some of the conference visitors to try to implement these practices in their work.
| Evgeny Ponomarev “ Rust instead of C for programming ARM Cortex-M ” |
Another way to increase the reliability of the code is instead of encouraging shooting at your own feet and other natural selection of type C languages ​​to switch to languages ​​that were originally conceived as more reliable and not allowing you to make a lot of mistakes (I am writing with all the responsibility as a person yesterday at two one o'clock in the morning catching the stack overflow event that occurred at random moments, sometimes after tens of minutes of active firmware operation).
However, how bright are the prospects, just as vague and the present of such languages ​​- so, Rust, the main candidate for the role of the future standard in the field of embedded software, for most practicing programmers falls into the category of “heard, cool, but what the hell is it for me now?”. Especially this contributes to the traditional curve of HYIP, on which Rust travels - it climbed to its top, being frankly unprepared for serious practical use, after which many developers simply stopped following its further 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 workable 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 the upper level systems " |
And, finally, a purely practical report about what it costs to ensure confidence in your devices, if you have already installed quite a few hundreds of them, and at the same time absolutely sure that at any moment at least a few dozen of them are in the cabinets, who forgot to lock and into which anyone can climb at any time, merge the firmware and fill it with seemingly the same device, just not yours, but its.
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 trivial task.
InoThings ++ 2019
So, all these reports - as well as many others - can be heard at the InoThings ++ conference, and that is especially valuable - not only to hear, but at the end of the speech, to take their authors by the elbow and take them to the lobby to continue the conversation. Actually, it is precisely this and valuable live attendance of technology conferences - looking half a year later with one eye a recording of a speech or an album on a slider, you will not be able to get up and ask for clarification of that moment, take the speaker to a cup of coffee to talk more 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.
Source: https://habr.com/ru/post/442696/
All Articles