— Шеф, у нас дыра в безопасности!
— Ну хоть что-то у нас в безопасности...
Привет, Хабр!
В комментариях к предыдущему посту про InoThings++ высказали мнение, что в Интернете Вещей есть более важная для обсуждения область, нежели вмешательство государства — это область обеспечения безопасности устройств. Со всех точек зрения.
Поспорить я могу здесь лишь с одним — что обсуждение вопросов безопасности стоит проводить в формате круглого стола; по этой причине круглый стол оставим как есть, на тему нужности (или ненужности) национальных стандартов и вообще вмешательства государства в дела индустрии, а про безопасность поговорим отдельно.
Почему вообще обеспечение безопасности в IoT рассматривают как что-то отдельное и специфическое, непохожее на обеспечение безопасности в классических ИТ-системах?
Да в общем потому, что IoT-системы на классические похожи лишь со стороны пользователя, видящего на экране монитора красивые картинки или управляющего лампочкой со смартфона — а вот внутри, на низком уровне, они совсем, совсем другие.
И, к сожалению, мы ещё многократно хлебнём горя с авторами продуктов, не понимающими разницы в подходе и проблемах.
«Интернет вещей» — это, в первую очередь, история про доступные, дешёвые, компактные, экономичные, и потому крайне массовые устройства с подключением к локальным или глобальным сетям передачи данных.
Что это означает на практике?
• Как правило, беспроводное подключение. In wire we trust, конечно, вот только провод — это дорого; делавшие себе проводной умный дом понимают, что это означает капитальный ремонт с прокладкой слаботочки по всем углам. А если провод проложить вообще нельзя?
Собственно, бурное развитие IoT и началось с появлением дешёвых, экономичных и дальнобойных беспроводных соединений — начиная с домашних Wi-Fi и BLE и заканчивая LoRaWAN, Sigfox, NB-IoT и так далее. Соединений, которые позволили насытить некое пространство датчиками, не заморачиваясь с их питанием и подключением.
Однако радио — это не только удобство, но и проклятие. Если для того, чтобы подключиться к проводу, соседям надо вскрыть замки на вашей двери, то ваш беспроводной дом они не просто «слышат» примерно всегда, но и могут его эффективно глушить, а то и подделывать.
• Как правило, предельно экономичные режимы работы радиоканала — устройству без постоянного питания надо беречь батарейку. Экономия на радиоканале выливается в то, что обновление прошивок устройство по воздуху либо невозможно вообще, либо бессмысленно в силу того, что один эпизод обновления выжирает десятки процентов имеющейся батарейки.
Соответственно, крайне высокое значение приобретает изначальное качество кода и протоколов — в случае обнаружения в них фатальной дыры производитель, конечно, сможет выложить на свой сайт новый файл, но толку от этого не будет никакого.
• Как правило, маломощные низкопотребляющие процессоры. Типовой IoT'шный датчик в наше время строится на процессорах класса от STM32L0 до младших STM32L4, и просто в силу ограничений по объёмам памяти и вычислительной мощности (а также и радиоканала, см. выше) может не потянуть сложные схемы авторизации, аутентификации и прочей защиты. Более того, маломощность может означать и отсутствие «лишней» памяти, необходимой для обновления прошивок по воздуху — ненадёжность радиоканала означает невозможность накатить прошивку сразу в «живой» флэш, а под сохранение её в отдельную область с последующей перезаписью рабочей прошивки памяти может и не быть.
И над всем этим расправляет крылья массовость и вездесущность — которая на практике означает отсутствие у владельца эффективного контроля над доступом к устройствам.
Когда у вас в доме было четыре Wi-Fi-устройства — роутер, ноутбук и два смартфона — проблема их утраты стояла не очень остро, потому что ни одно из них не относится к выкидываемым мимоходом.
Когда у вас в доме три-четыре десятка умных лампочек, выключателей, термодатчиков и чёрт знает чего ещё — очередную сгоревшую или просто старую лампочку вы, скорее всего, отправите в мусор, даже не задумываясь, что она продолжает надёжно хранить у себя во флэше ключ от вашей сети Wi-Fi.
Более того, если мы говорим о масштабе не квартиры, а коттеджного участка, гостиницы или завода — вы даже не контролируете доступ к IoT-устройствам. Любой желающий может выкрутить вашу лампочку, слить из неё ключи доступа и через полчаса вкрутить обратно — а вы этого даже не заметите.
Устройства можно клонировать. Из устройств можно считывать ключи и сертификаты. В устройства можно заливать модифицированные прошивки.
Вопрос здесь не в том, что всё это нельзя было проделать с Wi-Fi роутером — можно, конечно. Вопрос в переходе количества в качество: с обещаемым нам экспоненциальным ростом числа IoT-устройств подобные атаки становятся осмысленными и реализуемыми. Фактически, повторяется история с IP-камерами — пока их было мало, никто даже не задумывался, что камер с одной и той же дыркой в прошивке будет достаточно, чтобы имело смысл написать скрипт, собирающий их в гигантский ботнет, способный завалить GitHub на пару с Twitter.
Чем это кончилось — вы все знаете.
В классической ИБ считается, что если злоумышленник получил полный физический доступ к защищаемому устройству — ну, в общем, это ещё не конец, но всё плохо. В IoT в таком контексте «всё плохо» — это не результат чьих-то злонамеренных дел, а перманентное и изначальное состояние системы.
На InoThings++ мы, помимо прочих вещей, вне всякого сомнения, хотим поговорить и об этом — причём как дать понять разработчиком, что IoT несёт с собой совершенно новые модели угроз, так и поговорить о том, что же с этим делать.
Представлю некоторые доклады.
Вводный доклад о проблематике защиты IoT-устройств и новых угрозах, характерных именно для IoT, с анализом как российского законодательства, так и уже успевших выйти рекомендациях — пока ещё не требованиях — зарубежных организаций, включая NIST, ENISA, IIC и другие (ссылки под названиями не просто так ссылки, а на соответствующие документы — очень, очень рекомендую ознакомиться с ними, если вы имеете какое-либо отношение к разработке IoT-устройств).
Этот доклад — просто must have для интеграторов и разработчиков, недавно пришедших на рынок IoT-устройств и ещё не осознавших в полной мере возможных последствий этого. Выбора здесь нет — это вещи, не знать о существовании которых просто нельзя, и если вы не понимаете этого сегодня, завтра это может кончиться для вас и вашего бизнеса катастрофой, к которой у вас просто не будет времени подготовиться.
Совершенно не технический, но тоже важный доклад — о том, что сейчас мы живём в блаженное время, когда каждый производитель может навертеть в своих девайсах что его душе угодно, и ему за это ничего не будет.
Точнее, про то, что это время скоро кончится — необходимость в изменениях в законодательстве, связанных с IoT и умными устройствами вообще, назрела, и свой GDPR индустрия здесь ещё получит.
Первый (необходимый, но не достаточный) шаг к безопасности IoT-систем — это написание надёжного кода. Одним из способов повысить его надёжность является соблюдение стандартов, разработанных в отраслях, которые старше IoT на десятилетия — например, «автомобильного» стандарта качества кода MISRA C.
Само по себе соблюдение MISRA C и использование статических анализаторов кода, разумеется, не гарантирует вам абсолютную надёжность — однако может уберечь от довольно большого числа ошибок, начиная с банальной невнимательности, «копипаста» и опечаток. К сожалению, среди программистов встраиваемых систем пока что практики написания надёжного кода распространены крайне слабо — и я надеюсь, что Филипп вдохновит хотя бы часть посетителей конференции на то, чтобы попробовать эти практики в своей работе внедрить.
Другой способ повысить надёжность кода — это вместо поощряющих стрельбу по собственным ногам и прочий естественный отбор языков типа C переходить на языки, изначально задуманные как более надёжные и не дающие совершить массу ошибок (это я сейчас пишу со всей ответственностью, как человек, вчера в два часа ночи ловивший событие переполнения стека, возникавшее в случайные моменты, иногда через десятки минут активной работы прошивки).
Однако сколь светлы перспективы, столь же туманно и настоящее подобных языков — так, Rust, главный кандидат на роль будущего стандарта в области встраиваемого ПО, для большинства практикующих программистов относится к категории «слышал, прикольно, но нафига оно мне сейчас?». Особенно этому способствует традиционная кривая хайпа, по которой Rust путешествует — на её вершину он взобрался, будучи откровенно неготовым к серьёзному практическому применению, после чего многие разработчики попросту перестали следить за его дальнейшей судьбой.
Так вот, собственно, в докладе Евгений и расскажет, какова текущая судьба Rust, почему его уже можно рассматривать в качестве пригодного для работы языка и скольких километров нервных окончаний вам будет стоить его использование здесь и сейчас.
И, наконец, чисто практический доклад — о том, чего стоит обеспечение доверия к вашим устройствам, если вы установили их уже довольно много сотен штук, и при этом совершенно точно знаете, что в любой момент как минимум несколько десятков из них находятся в шкафах, которые забыли запереть и в которые в любой момент может влезть любой желающий, слить прошивку и залить её на вроде бы такое же устройство, только уже не ваше, а его.
Более того, мало эти устройства контролировать — их сначала надо ещё развернуть, что тоже с точки зрения аутентификации может являться задачей довольно нетривиальной.
Итак, все эти доклады — а также множество других — можно будет услышать на конференции InoThings++, и что особенно ценно — не просто услышать, а по окончании выступления взять под локоток их авторов и увести в кулуары для продолжения беседы. Собственно, именно этим и ценно живое посещение технологических конференций — просматривая спустя полгода одним глазом запись выступления или альбом на слайдшере, вы уже не сможете встать и попросить пояснить подробнее воооон тот момент, отвести докладчика на чашку кофе, чтобы поговорить поподробнее про его проекты, и так далее, и тому подобное.
Поэтому — приходите. Билеты на данный момент стоят 15 тысяч рублей, и поверьте мне, за конференцию такого уровня и с такими докладчиками — это весьма скромно.
— Ну хоть что-то у нас в безопасности...
Привет, Хабр!
В комментариях к предыдущему посту про InoThings++ высказали мнение, что в Интернете Вещей есть более важная для обсуждения область, нежели вмешательство государства — это область обеспечения безопасности устройств. Со всех точек зрения.
Поспорить я могу здесь лишь с одним — что обсуждение вопросов безопасности стоит проводить в формате круглого стола; по этой причине круглый стол оставим как есть, на тему нужности (или ненужности) национальных стандартов и вообще вмешательства государства в дела индустрии, а про безопасность поговорим отдельно.
Почему вообще обеспечение безопасности в IoT рассматривают как что-то отдельное и специфическое, непохожее на обеспечение безопасности в классических ИТ-системах?
Да в общем потому, что IoT-системы на классические похожи лишь со стороны пользователя, видящего на экране монитора красивые картинки или управляющего лампочкой со смартфона — а вот внутри, на низком уровне, они совсем, совсем другие.
И, к сожалению, мы ещё многократно хлебнём горя с авторами продуктов, не понимающими разницы в подходе и проблемах.
«Интернет вещей» — это, в первую очередь, история про доступные, дешёвые, компактные, экономичные, и потому крайне массовые устройства с подключением к локальным или глобальным сетям передачи данных.
Что это означает на практике?
• Как правило, беспроводное подключение. In wire we trust, конечно, вот только провод — это дорого; делавшие себе проводной умный дом понимают, что это означает капитальный ремонт с прокладкой слаботочки по всем углам. А если провод проложить вообще нельзя?
Собственно, бурное развитие IoT и началось с появлением дешёвых, экономичных и дальнобойных беспроводных соединений — начиная с домашних Wi-Fi и BLE и заканчивая LoRaWAN, Sigfox, NB-IoT и так далее. Соединений, которые позволили насытить некое пространство датчиками, не заморачиваясь с их питанием и подключением.
Однако радио — это не только удобство, но и проклятие. Если для того, чтобы подключиться к проводу, соседям надо вскрыть замки на вашей двери, то ваш беспроводной дом они не просто «слышат» примерно всегда, но и могут его эффективно глушить, а то и подделывать.
• Как правило, предельно экономичные режимы работы радиоканала — устройству без постоянного питания надо беречь батарейку. Экономия на радиоканале выливается в то, что обновление прошивок устройство по воздуху либо невозможно вообще, либо бессмысленно в силу того, что один эпизод обновления выжирает десятки процентов имеющейся батарейки.
Соответственно, крайне высокое значение приобретает изначальное качество кода и протоколов — в случае обнаружения в них фатальной дыры производитель, конечно, сможет выложить на свой сайт новый файл, но толку от этого не будет никакого.
• Как правило, маломощные низкопотребляющие процессоры. Типовой IoT'шный датчик в наше время строится на процессорах класса от STM32L0 до младших STM32L4, и просто в силу ограничений по объёмам памяти и вычислительной мощности (а также и радиоканала, см. выше) может не потянуть сложные схемы авторизации, аутентификации и прочей защиты. Более того, маломощность может означать и отсутствие «лишней» памяти, необходимой для обновления прошивок по воздуху — ненадёжность радиоканала означает невозможность накатить прошивку сразу в «живой» флэш, а под сохранение её в отдельную область с последующей перезаписью рабочей прошивки памяти может и не быть.
И над всем этим расправляет крылья массовость и вездесущность — которая на практике означает отсутствие у владельца эффективного контроля над доступом к устройствам.
Когда у вас в доме было четыре Wi-Fi-устройства — роутер, ноутбук и два смартфона — проблема их утраты стояла не очень остро, потому что ни одно из них не относится к выкидываемым мимоходом.
Когда у вас в доме три-четыре десятка умных лампочек, выключателей, термодатчиков и чёрт знает чего ещё — очередную сгоревшую или просто старую лампочку вы, скорее всего, отправите в мусор, даже не задумываясь, что она продолжает надёжно хранить у себя во флэше ключ от вашей сети Wi-Fi.
Более того, если мы говорим о масштабе не квартиры, а коттеджного участка, гостиницы или завода — вы даже не контролируете доступ к IoT-устройствам. Любой желающий может выкрутить вашу лампочку, слить из неё ключи доступа и через полчаса вкрутить обратно — а вы этого даже не заметите.
Устройства можно клонировать. Из устройств можно считывать ключи и сертификаты. В устройства можно заливать модифицированные прошивки.
Вопрос здесь не в том, что всё это нельзя было проделать с Wi-Fi роутером — можно, конечно. Вопрос в переходе количества в качество: с обещаемым нам экспоненциальным ростом числа IoT-устройств подобные атаки становятся осмысленными и реализуемыми. Фактически, повторяется история с IP-камерами — пока их было мало, никто даже не задумывался, что камер с одной и той же дыркой в прошивке будет достаточно, чтобы имело смысл написать скрипт, собирающий их в гигантский ботнет, способный завалить GitHub на пару с Twitter.
Чем это кончилось — вы все знаете.
В классической ИБ считается, что если злоумышленник получил полный физический доступ к защищаемому устройству — ну, в общем, это ещё не конец, но всё плохо. В IoT в таком контексте «всё плохо» — это не результат чьих-то злонамеренных дел, а перманентное и изначальное состояние системы.
Проблема безопасности в IoT — это не проблема завтрашнего дня. Это проблема сегодняшнего дня. Если её не решать — завтра она станет не проблемой, а катастрофой.
На InoThings++ мы, помимо прочих вещей, вне всякого сомнения, хотим поговорить и об этом — причём как дать понять разработчиком, что IoT несёт с собой совершенно новые модели угроз, так и поговорить о том, что же с этим делать.
Представлю некоторые доклады.
 |
Сергей Парьев Ростелеком-Солар «Необходимость реализации встроенных механизмов защиты информации в IIoT устройствах» |
Вводный доклад о проблематике защиты IoT-устройств и новых угрозах, характерных именно для IoT, с анализом как российского законодательства, так и уже успевших выйти рекомендациях — пока ещё не требованиях — зарубежных организаций, включая NIST, ENISA, IIC и другие (ссылки под названиями не просто так ссылки, а на соответствующие документы — очень, очень рекомендую ознакомиться с ними, если вы имеете какое-либо отношение к разработке IoT-устройств).
Этот доклад — просто must have для интеграторов и разработчиков, недавно пришедших на рынок IoT-устройств и ещё не осознавших в полной мере возможных последствий этого. Выбора здесь нет — это вещи, не знать о существовании которых просто нельзя, и если вы не понимаете этого сегодня, завтра это может кончиться для вас и вашего бизнеса катастрофой, к которой у вас просто не будет времени подготовиться.
 |
Кирилл Митягин Newsky IP Law «Правовой вакуум интернета вещей — какие изменения в законы нужны для IoT?» |
Совершенно не технический, но тоже важный доклад — о том, что сейчас мы живём в блаженное время, когда каждый производитель может навертеть в своих девайсах что его душе угодно, и ему за это ничего не будет.
Точнее, про то, что это время скоро кончится — необходимость в изменениях в законодательстве, связанных с IoT и умными устройствами вообще, назрела, и свой GDPR индустрия здесь ещё получит.
 |
Филипп Хандельянц PVS Studio «Статический анализ и написание качественного кода на C/C++ для встраиваемых систем» |
Первый (необходимый, но не достаточный) шаг к безопасности IoT-систем — это написание надёжного кода. Одним из способов повысить его надёжность является соблюдение стандартов, разработанных в отраслях, которые старше IoT на десятилетия — например, «автомобильного» стандарта качества кода MISRA C.
Само по себе соблюдение MISRA C и использование статических анализаторов кода, разумеется, не гарантирует вам абсолютную надёжность — однако может уберечь от довольно большого числа ошибок, начиная с банальной невнимательности, «копипаста» и опечаток. К сожалению, среди программистов встраиваемых систем пока что практики написания надёжного кода распространены крайне слабо — и я надеюсь, что Филипп вдохновит хотя бы часть посетителей конференции на то, чтобы попробовать эти практики в своей работе внедрить.
| Евгений Пономарёв «Rust вместо Си для программирования ARM Cortex-M» |
Другой способ повысить надёжность кода — это вместо поощряющих стрельбу по собственным ногам и прочий естественный отбор языков типа C переходить на языки, изначально задуманные как более надёжные и не дающие совершить массу ошибок (это я сейчас пишу со всей ответственностью, как человек, вчера в два часа ночи ловивший событие переполнения стека, возникавшее в случайные моменты, иногда через десятки минут активной работы прошивки).
Однако сколь светлы перспективы, столь же туманно и настоящее подобных языков — так, Rust, главный кандидат на роль будущего стандарта в области встраиваемого ПО, для большинства практикующих программистов относится к категории «слышал, прикольно, но нафига оно мне сейчас?». Особенно этому способствует традиционная кривая хайпа, по которой Rust путешествует — на её вершину он взобрался, будучи откровенно неготовым к серьёзному практическому применению, после чего многие разработчики попросту перестали следить за его дальнейшей судьбой.
Так вот, собственно, в докладе Евгений и расскажет, какова текущая судьба Rust, почему его уже можно рассматривать в качестве пригодного для работы языка и скольких километров нервных окончаний вам будет стоить его использование здесь и сейчас.
 |
Евгений Богер Wiren Board «Аутентификация устройств на Linux по аппаратному ключу в системах верхнего уровня» |
И, наконец, чисто практический доклад — о том, чего стоит обеспечение доверия к вашим устройствам, если вы установили их уже довольно много сотен штук, и при этом совершенно точно знаете, что в любой момент как минимум несколько десятков из них находятся в шкафах, которые забыли запереть и в которые в любой момент может влезть любой желающий, слить прошивку и залить её на вроде бы такое же устройство, только уже не ваше, а его.
Более того, мало эти устройства контролировать — их сначала надо ещё развернуть, что тоже с точки зрения аутентификации может являться задачей довольно нетривиальной.
InoThings++ 2019
Итак, все эти доклады — а также множество других — можно будет услышать на конференции InoThings++, и что особенно ценно — не просто услышать, а по окончании выступления взять под локоток их авторов и увести в кулуары для продолжения беседы. Собственно, именно этим и ценно живое посещение технологических конференций — просматривая спустя полгода одним глазом запись выступления или альбом на слайдшере, вы уже не сможете встать и попросить пояснить подробнее воооон тот момент, отвести докладчика на чашку кофе, чтобы поговорить поподробнее про его проекты, и так далее, и тому подобное.
Поэтому — приходите. Билеты на данный момент стоят 15 тысяч рублей, и поверьте мне, за конференцию такого уровня и с такими докладчиками — это весьма скромно.
Комментарии (38)
pyrk2142
05.03.2019 19:19Довольно интересной сейчас является ситуация с GSM-управляемыми устройствами. Огромное количество устройств ломаются удаленно практически незаметно для пользователя, при этом «стоимость» взлома составляет что-то на уровне 50 рублей за устройство. При этом отдельный прикол части устройств (куча сигнализаций, контроллеров и других штук с Алиэкспресса и от местных умельцев) в том, что их невозможно эксплуатировать безопасно: их можно купить, поставить в изолированной среде, настроить по инструкциям, но это не поможет, так как они изначально сделаны небезопасно, а проблемы никто не исправляет.
Mogwaika
05.03.2019 19:21А если хочется безопасно сделать самому для себя?
pyrk2142
06.03.2019 11:17Кажется, что можно, но это будет далеко не самое дешёвое решение, плюс никто не гарантирует, что систему, которые не можете сломать вы, не может сломать кто-то другой.
Mogwaika
06.03.2019 11:38Я думаю вопрос о абсолютной безопасности не стоит, скорее можно ли сделать немного лучше, чем покупное изделие. Плюс хоть в абсолютном виде security through obscurity это плохо, но на случайные попытки взлома стандартными методами и девайсами без цели сломать конкретное устройство должно повлиять.
augorelov
06.03.2019 12:46Это древняя борьба между взломщика и разработчиками изделий. Поэтому достичь абсолютной безопасности не возможно. Всегда будут появляться новые средства и методы защиты, и как следствие новые средства и способы взлома. ИБ — это всегда компромисс между стоимость заложенных защит в устройство и получаемой выгоды в результате взлома.
Mogwaika
06.03.2019 13:47Стоимость защит и убытка или стоимость атак и выгоды тогда уж.
А так может я просто спать спокойнее буду, тоже дорогого стоит)
SamaRazor
06.03.2019 12:51Насколько неподьемным является реализация SSL-хендшейка (условно, я про любую ассиметричную криптографию), с лайфтаймом ключа в бесконечность/до потери питания? Например на STM32 103? Я когда-то баловался своими велосипедами на подобных чипах, секьюрити у меня конечно не было. Есть результаты профилирования там по питанию/времени? Ясное дело что есть чипы совсем слабые, которые это точно не потянут, но какие-то там условные 50% покрыть?
olartamonov Автор
06.03.2019 14:27Асимметричная криптография очень тяжёлая — 20-30 КБ флэша, 10-20 КБ ОЗУ у типичной библиотеки.
romanetz_omsk
06.03.2019 15:56-1Наверное, надо в сторону чипов с аппаратным шифрованием глядеть. Те же ESP32, хотя и у стмок есть. Дело даже не в флеше и озу — дело в затратах батареи.
j_wayne
06.03.2019 14:48+1А есть у кого-нибудь саксесс стори с www.microchip.com/wwwproducts/en/ATECC608A и подобными?
build_your_web
По-хорошему, шифрование должно вестись от устройства, которое производит данные, до устройства, которое данные потребляет (т.е. без доверия к промежуточным узлам).
В связи с этим, в своих хоббийных проектах использую WiFi MCU TI CC3200.
Причины: бесплатная удобная IDE (CCS), очень удобное SDK, внятная документация, аппаратная поддержка шифрования и возможность закупить модули с готовой обвязкой на китайский площадках (по вменяемой цене).
augorelov
Данный SoC поддерживает только симметричное шифрование, следовательно ключ хранится во внутренней памяти. При физическом доступе к устройству ключ, может быть скомпрометирован. Также возможен взлом ключа при передаче неизменных данных в радиоканале. Таким образом применение только SoC со встроенным шифрованием не дает полной защиты. Нужны еще программные методы.
Подводя резюме:
Задача разработчика сделать не абсолютно неприступную защиту, а такую, чтобы «стоимость взлома» (время, затраченное на процесс взлома) превышало стоимость получаемой выгоды от взлома.
olartamonov Автор
А потом получается вот так.
Забудьте про классическую ИБ, в которой канал зашифровали — и всё хорошо. Считайте, что у вас одно из конечных устройств находится в полном распоряжении злоумышленника, причём вы не знаете, какое и когда.
dernuss
А с stm32 или cc1310 сейчас можно слить прошивку? Ну если флеш защищена?
olartamonov Автор
Защищено что именно и от чего именно?
Пишем свою прошивку, которая сдампит нужные данные из флэша или EEPROM, заливаем через штатный апдейтер под видом обновления, запускаем, voila.
Надёжная защита в таких системах бывает только многоуровневая — подписанные (а то и зашированные, но это, понятно, до утекания заводского ключа) обновления прошивок, secure bootloader с проверкой подписи в обновлениях, шифрование данных индивидуальным для данного контроллера ключом…
dernuss
Ну если защищена внутренняя флеш от копирования, как её сдампить то?
У стм32 сдампить насколько я знаю нельзя, ну по крайней мере штатным апдейтером. Он сначала сотрет всю флеш, потом запишет новую прошивку.
Про secure bootloader конечно понятно. Не очень понятно только как сделать ключ шифрования индивидуальный. Ну точнее понятно как, но что, держать на серваке несколько сот тысяч прошивок для всех девайсов?
olartamonov Автор
Что значит «от копирования»? Если внутренняя флэш защищена от чтения внутренним же софтом, вы не можете хранить в ней ключ от Wi-Fi, потому что ваша же легальная прошивка его оттуда не прочитает.
А если не защищена, то его может прочитать не только ваша прошивка, но и любая другая прошивка, которую удастся загрузить на устройство.
Обновления прошивок, конечно, подписываются общим ключом — поэтому работает это всё до утекания данного ключа и под вой сообщества о том, что вы мешаете честным людям залить в ваши устройства любую нравящуются им прошивку. Настройки внутри устройства шифруются индивидуальным ключом, хранящимся на этом же устройстве — и он, конечно, тоже извлекаем, но по крайней мере предотвращает банальные атаки «сдампим EEPROM и зальём в другую железку».
А если вы хотите секьюрити по-настоящему, то тут уже начинаются разные интересные пляски с secure element — аппаратными хранилищами.
dernuss
То и значит, что защищена. Что нельзя штатными апдейтерами слить прошивку из микроконтроллера.
Например для stm32 эта защита устанавливается через Option byte под именем Read Out Protection.
Так уж вышло, что сообщество пишет бывает неплохие прошивки.
Например у sonoff схемы открытые.
olartamonov Автор
Штатный апдейтер — это который по UART общается? Не хочу вас расстраивать, но в контексте OTA он абсолютно бессмысленен, вам придётся писать свой.
До первого червя, добавленного к штатной прошивке.
dernuss
Как бы я в курсе, писал уже.
Я к тому, что в руках злоумышленников, когда закрыта от считывания флешка, слить прошивку крайне сложно.
А написанный свой загрузчик не возможно записать без стирания всей влешки. По крайней мере у STM32 так.
При открытой схеме штатная прошивка не очень то и нужна.
olartamonov Автор
Злоумышленнику вообще не нужен исполняемый код вашей прошивки, он его с вашего же сайта из раздела «Обновления» загрузит.
Ему нужны настройки устройства, позволяющие либо сделать клон, либо влезть в вашу сеть. Для того, чтобы их слить, загрузчика, не проверяющего подпись прошивки, более чем достаточно.
Если вы планируете ограничиться продажами в десяток тысяч штук для энтузиастов, которые что-то там будут ковырять руками, то, конечно, да.
dernuss
Загрузит то загрузит, только зашифрованную прошивку, от которой толка около нуля.
А вот для того чтобы сделать клон, нужна расшифрованная прошивка. И как вы её сольёте, если флеш закрыта от чтения, я не понимаю…
olartamonov Автор
Между зашифрованной прошивкой и расшифрованной ровно один шаг, требующий знания ключа. Который у вас во флэше и который без малейших проблем можно слить, если ваш бутлоадер позволяет загрузить неподписанный код.
Зато наверняка знаете, что продаёт он устройства со штатной прошивкой.
dernuss
Ну что вы, нет конечно. Не позволяет.
Хотя на самом деле надо будет подумать, можно ли сделать так, чтобы у каждого девайса был свой уникальный ключ…
Меня тоже напрягает один ключ шифрования.
augorelov
Микропрограммное обеспечение не сольют. А ключи вы хранить где и как планируете?
dernuss
ну вместе с прошивкой, вестимо…
augorelov
Таким образом получается, что конечный пользователь не сможет интегрировать Ваш датчик или актуатор в инфраструктуру своей беспроводной сети? Тогда за чем ему покупать Ваше устройство?
dernuss
действительно. Зачем тогда продают и покупают всякие устройства? У которых всё устроено так как я и написал.
Кстати, в IoT вообще пока нет ни каких общих стандартов, кто в лес кто по дрова. Какая интеграция…
augorelov
Вы как и большинство не совсем понимаете, что такое IoT и ИБ. Судя по Вашим комментариям.
Вы точно уверены, что в них так реализовано?
Почему тогда получается, как выше уже указывали?
И тогда какой IoT без интеграции?
dernuss
Мои устройства ещё не взламывали, ну пока…
Потому что не везде так реализовано, как я описал))
Часто устройства IoT интегрируются только с устройствами того же производителя. К сожалению…
augorelov
Интереса к взлому Ваших устройств не у кого не было, так как взлом Вашего устройства не принесет коммерческой выгоды.
Много ли Ваших устройств работает на критически важных объектах?
Какой смысл взламывать Ваши часы, например? Взломать часы, чтобы пораньше будить, часа в два ночи?
dernuss
часы и другие выложенные в общий доступ проекты, это проекты выходного дня. Они полностью лишены безопастности. С другой стороны, лампочку же взломали))
На моих серийный девайсах, закрыта флеш от чтения, свой загрузчик, и обновления зашифрованы.
Попробуйте взломайте)
Не знаю
augorelov
Это не дает 100% защиты. Изучите на досуге, методы взлома микроконтроллеров и систем построенных на микроконтроллерах. Есть методы извлечения микропрограммного обеспечения микроконтроллера не только с помощью отладчика.
И потом, чтобы добыть ключи шифрования не обязательно извлекать микропрограммное обеспечение.
Вы точно хотите продолжать дискуссию?
dernuss
100% защиты вообще нет.
Про другие методы я тоже знаю.
нет, не хочу. Смысла то нет