Спасибо, что прочитали статью и поделились своим мнением) Я думал поэкспериментировать с прошивкой. Может все таки по дополнительному функционалу еще подумаю. Если надумаю, будет ещё одна статья)
Про аутентификацию я с вами полностью согласен. Как раз в устройстве SmartPulse я реализовывал тот механизм, на который вы ссылаетесь, с генерацией шестизначного рандомного пин-кода и последующим выводом на экран устройства. Доступ к нему предоставляется после введения пин-кода в приложении Smart Connect. То есть, характеристики закрыты до тех пор, пока не произойдет проверка введенного в приложении пин-кода на уровне прошивки устройства.
Про кнопку ничего сказать не могу, я в стандарте этого не видел. По сути, сама проблема безопасности Интернета вещей как концепции и устройств IoT в частности заключается даже не в использовании уязвимостей технологий беспроводной передачи данных и прочего, а просто в нежелании «разработчика» хотя бы мало-мальски постараться над механизмами безопасности своего продукта. С точки зрения человека я могу это понять, потому что мало кто идет проверяться у стоматолога, пока зуб не заболит. Но на мой взгляд это все таки проблема, потому что важно осознавать последствия, которые могут возникать из-за такой халатности.
Спасибо за идею с более элегантным способом. Я как-то сам до этого не дошел, хотя по сути, способ много где используется.
Ну про фичу согласен. Только на мой взгляд это не должно никоим образом мешать безопасности устройства в целом. С тем же SmartPulse я же не запретил доступ в принципе. Можно спокойно подключиться к нему, можно посмотреть все сервисы и характеристики. То есть, при желании написать кастомный клиент, я предусмотрел эту возможность. Но прочитать что-либо из характеристик или записать в них без первоначального введения временного пин-кода - невозможно (или трудно выполнимо, чтобы не кидаться громкими словами). По сути, смысл всей статьи был в этом.
Поэтому я привел в пример историю с коммерческим устройством. То есть, смысл в том, что не обязательно знать коды управления (при наличии времени и желания их можно подобрать), чтобы получить доступ к устройству и как минимум попробовать им управлять. Ну и про открытые характеристики туда же. Хотя звучит, может, и не особо убедительно
Про колонки и прочее - тут просто самой цели именно в этом не было, поэтому работал с тем, что подвернулось под руку. Я дальше планирую на Flipper Zero попробовать поиграться с моими устройствами и с разными коммерческими, если время будет
С последним тезисом про безопасность, как фичу, не совсем согласен. Из-за такого подхода мы и говорим про интернет вещей, как про что-то совершенно лишенное защиты. А потом появляются статьи про взломы умных лампочек и компрометацию ПДн пользователя, через получение доступа к умному устройству, как к посреднику для более направленного вектора атаки на мобильное устройство или любое другое, которое уже точно стоит защищать. Чем меньше уязвимых звеньев мы в этой цепочке оставляем, тем сложнее и замороченнее провести атаку.
По поводу комфорта пользователя - наиболее комфортный и удобный вариант со стороны пользователя, это обычно когда вообще не требуется ни пароль свой вспоминать, ни код двухфакторки вводить, ни париться с восстановление доступа к аккаунту в основном мобильном приложении для устройств Интернета вещей. Тут понятно, что генерировать пин-код для ввода каждый раз это не удобно для пользователя. Ок, я согласен. Поэтому придумываются различные автозаполнения и прочее, чтобы пользователь не так сильно напрягался по работе с приложением или устройством. В случае пульсометра - не хочется вбивать пин-код? Пускай аутентификация происходит по QR-коду на его дисплее через мобильное приложение. Камеру телефона навел и подключился. Красота же.
По модели угроз и прочего я согласен полностью, про это я уже говорил. Но то, что у меня продемонстрировано в дипломе, в принципе, не нужно воспринимать как реальную ситуацию. Да, в данном конкретном случае защищать пульсометр в целом не имеет смысла, потому что даже в мобильном приложении нет никаких пользовательских данных. Ок. А что, если бы они были? А что, если мы говорим о потенциальной платформе IoT для множества устройств в одной единой экосистеме? Там будут пользовательские данные и устройства будут явно не уровня пульсометра. Да, нужна модель угроз, я согласен, и я согласен с тем, что невозможно ее сформировать на «идею», а не на четко разрабатываемую ИС, где в явном виде будет понятна и классификация ПДн, и потенциал нарушителя, и определенна ценность информации, и способ взаимодействия с ней. Но ведь задача моего диплома изначально заключалась в ином. Подход от мат модели показать, как наиболее оптимальный метод в рамках ограниченности ресурсов.
На мой взгляд, тему надо допилить вместе с зависимостью от МУиН напрямую для определения наиболее эффективных сценариев защиты. Диплом ведь про это, а не про то, что я определил механизмы защиты, защитил ими устройство, и рекомендую всем так делать.
За вашу оценку моего диплома и настолько подробные комментарии в любом случае спасибо. Для меня важно любое аргументированное мнение и позиция
Да я в целом в статье не рекомендую подобные вещи в явном виде сравнивать. Строки - не самая большая беда, учитывая то, что я не использую никакого хэширования.
За то, что заметили косяк с использованием строк в C - респект. Приятно, что на мою статью обратил внимание опытный и грамотный специалист. Я не могу сказать, что не знал про этот недостаток, но на этапе написания работы времени минимизировать такие допущения у меня не оставалось, а для статьи я решил исходники не переписывать, чтобы оставаться до конца честным (иначе это была бы уже не моя ВКР, а что-то совершенно отдельное).
По самой работе, практикам ИБ и прочему - если бы это касалось реальной разработки устройства в рамках организации или стартапа, подход в принципе сильно бы отличался. Не только по качеству кода, но и к проектированию устройства и определению механизмов защиты в принципе. Про модель угроз я уже выше написал, почему пришлось от нее отказаться.
Я никогда не утверждал, что это самый эффективный и работоспособный вариант. Но правда я верю, что он не бесперспективен как минимум. Отсюда вопрос: если вы ознакомились со всеми опубликованными частями цикла или посмотрели оригинал ВКР, как вы думаете, в каком направлении углублять это исследование, чтобы получилось что-то реально рабочее? Есть у вас какие-то предложения? Может завязать определение механизмов защиты на сложности реализации атак по потенциалу злоумышленника или в мат модели показатели приоритета расширить в соответствии с МУиН?
По поводу модели угроз я с вами согласен. У меня были мысли хотя бы минимально определить нарушителя в рамках дипломной работы, но она в итоге и без того вышла достаточно объемной, поэтому решил опустить часть с МУиН.
Относительно защиты - я в самой статье упоминал, что цель заключалась не в демонстрации наиболее правильного процесса обеспечения безопасности устройства и концепции безопасной разработки, а в том, как в теории можно использовать методику на математической модели, которая мной в первой части описывалась.
Если бы я полноценно подготовил МУиН на ИС из пользователя, устройства и мобильного приложения, дипломная работа стала бы толще ещё на несколько десятков страниц, но в рамках реальной разработки она безусловно нужна.
Спасибо за то, что прочитали статью и написали комментарий
Огромное спасибо, что прочитали статью. Отдельное спасибо за то, что считаете мою статью крутой. Не забрасывайте тему безопасности IoT. Она затрагивает много важных и актуальных вещей
Пробовал запитать преобразователь от платы контроллера, но мне совершенно не понравился писк, который начинал исходить от него. Скорее всего проблема в самом преобразователе, но другого не было. Поэтому решил дополнительно его питать, чтобы не переживать за его работоспособность на защите (если бы он перегорел прям перед дипломной комиссией, спецэффект получился бы крутой, но мне все таки хотелось показать работающее устройство)
По марке вообще не уверен. Я сам пытался найти, но безуспешно. Просто когда-то давно отковырял откуда-то. На мультиметре проверил, все было ок, а большего для этого проекта мне было и ненужно
Гальваническую развязку я вообще делать не хотел. Питание пришлось увести как раз из-за моей неуверенности в преобразователе.
Если честно, пришлось гуглить, чтобы понять, о чем вы говорите. Хотя про Алекса я прекрасно знаю, но как-то упустил шумиху вокруг его проекта. Не совсем понимаю, о чем конкретно вы хотите сказать: вы имеете ввиду, что я взял идею Алекса и выдаю за что-то свое? Тут есть несколько моментов:
Я не думаю, что взять светодиодную матрицу и подключить ее к микроконтроллеру - это что-то из ряда вон выходящее. Таких проектов тьма. Они были, есть и будут вне зависимости от того, кто и что делал ранее в этом направлении
Сколько не смотрел, не увидел у Алекса ни намека на электрохромную пленку в его проекте
В GyverLamp использовался ESP8266 и управление по Wi-Fi. Я использую ESP32 и управление по BLE. Потому что мне нужно было устройство с BLE для дипломной работы
Форм-фактор. Не видел ни одной интерпретации GyverLamp в том корпусе и виде, что есть у меня
Я просто собрал устройство с BLE без механизмов защиты, чтобы продемонстрировать его на защите и в последствии получить к нему несанкционированный доступ. Вообще не преследовал никаких целей что-то продать, или представить какую-то мегакрутую идею.
Проект Алекса крутой - у него там и эффектов куча, и режимы поинтереснее. У меня не было стремления сделать что-то подобное. Для диплома нужно было устройство - я его сделал. Все просто
Как и приличное количество людей в комментариях к товару
Спасибо, что прочитали статью и поделились своим мнением) Я думал поэкспериментировать с прошивкой. Может все таки по дополнительному функционалу еще подумаю. Если надумаю, будет ещё одна статья)
Сейчас заметил в схеме. Ничего сверхъестественного, это просто мой косяк. Спасибо, что сказали. Исправил
Яндекс пишет, что инерционный. Я решил с ними в этом не спорить. С точки зрения механизма я с вами согласен, это заводной 100%
Я очень рад, что Вы продолжаете следить за моими статьями) Большое спасибо за комментарий
Спасибо за совет) В следующих проектах попробую ее
Про аутентификацию я с вами полностью согласен. Как раз в устройстве SmartPulse я реализовывал тот механизм, на который вы ссылаетесь, с генерацией шестизначного рандомного пин-кода и последующим выводом на экран устройства. Доступ к нему предоставляется после введения пин-кода в приложении Smart Connect. То есть, характеристики закрыты до тех пор, пока не произойдет проверка введенного в приложении пин-кода на уровне прошивки устройства.
Про кнопку ничего сказать не могу, я в стандарте этого не видел. По сути, сама проблема безопасности Интернета вещей как концепции и устройств IoT в частности заключается даже не в использовании уязвимостей технологий беспроводной передачи данных и прочего, а просто в нежелании «разработчика» хотя бы мало-мальски постараться над механизмами безопасности своего продукта. С точки зрения человека я могу это понять, потому что мало кто идет проверяться у стоматолога, пока зуб не заболит. Но на мой взгляд это все таки проблема, потому что важно осознавать последствия, которые могут возникать из-за такой халатности.
Спасибо за комментарий!
Спасибо за идею с более элегантным способом. Я как-то сам до этого не дошел, хотя по сути, способ много где используется.
Ну про фичу согласен. Только на мой взгляд это не должно никоим образом мешать безопасности устройства в целом. С тем же SmartPulse я же не запретил доступ в принципе. Можно спокойно подключиться к нему, можно посмотреть все сервисы и характеристики. То есть, при желании написать кастомный клиент, я предусмотрел эту возможность. Но прочитать что-либо из характеристик или записать в них без первоначального введения временного пин-кода - невозможно (или трудно выполнимо, чтобы не кидаться громкими словами). По сути, смысл всей статьи был в этом.
Огромное спасибо за комментарий!
Поэтому я привел в пример историю с коммерческим устройством. То есть, смысл в том, что не обязательно знать коды управления (при наличии времени и желания их можно подобрать), чтобы получить доступ к устройству и как минимум попробовать им управлять. Ну и про открытые характеристики туда же. Хотя звучит, может, и не особо убедительно
Большое спасибо) Это очень приятно читать
Про колонки и прочее - тут просто самой цели именно в этом не было, поэтому работал с тем, что подвернулось под руку. Я дальше планирую на Flipper Zero попробовать поиграться с моими устройствами и с разными коммерческими, если время будет
С последним тезисом про безопасность, как фичу, не совсем согласен. Из-за такого подхода мы и говорим про интернет вещей, как про что-то совершенно лишенное защиты. А потом появляются статьи про взломы умных лампочек и компрометацию ПДн пользователя, через получение доступа к умному устройству, как к посреднику для более направленного вектора атаки на мобильное устройство или любое другое, которое уже точно стоит защищать. Чем меньше уязвимых звеньев мы в этой цепочке оставляем, тем сложнее и замороченнее провести атаку.
По поводу комфорта пользователя - наиболее комфортный и удобный вариант со стороны пользователя, это обычно когда вообще не требуется ни пароль свой вспоминать, ни код двухфакторки вводить, ни париться с восстановление доступа к аккаунту в основном мобильном приложении для устройств Интернета вещей. Тут понятно, что генерировать пин-код для ввода каждый раз это не удобно для пользователя. Ок, я согласен. Поэтому придумываются различные автозаполнения и прочее, чтобы пользователь не так сильно напрягался по работе с приложением или устройством. В случае пульсометра - не хочется вбивать пин-код? Пускай аутентификация происходит по QR-коду на его дисплее через мобильное приложение. Камеру телефона навел и подключился. Красота же.
По модели угроз и прочего я согласен полностью, про это я уже говорил. Но то, что у меня продемонстрировано в дипломе, в принципе, не нужно воспринимать как реальную ситуацию. Да, в данном конкретном случае защищать пульсометр в целом не имеет смысла, потому что даже в мобильном приложении нет никаких пользовательских данных. Ок. А что, если бы они были? А что, если мы говорим о потенциальной платформе IoT для множества устройств в одной единой экосистеме? Там будут пользовательские данные и устройства будут явно не уровня пульсометра. Да, нужна модель угроз, я согласен, и я согласен с тем, что невозможно ее сформировать на «идею», а не на четко разрабатываемую ИС, где в явном виде будет понятна и классификация ПДн, и потенциал нарушителя, и определенна ценность информации, и способ взаимодействия с ней. Но ведь задача моего диплома изначально заключалась в ином. Подход от мат модели показать, как наиболее оптимальный метод в рамках ограниченности ресурсов.
На мой взгляд, тему надо допилить вместе с зависимостью от МУиН напрямую для определения наиболее эффективных сценариев защиты. Диплом ведь про это, а не про то, что я определил механизмы защиты, защитил ими устройство, и рекомендую всем так делать.
За вашу оценку моего диплома и настолько подробные комментарии в любом случае спасибо. Для меня важно любое аргументированное мнение и позиция
Да я в целом в статье не рекомендую подобные вещи в явном виде сравнивать. Строки - не самая большая беда, учитывая то, что я не использую никакого хэширования.
За то, что заметили косяк с использованием строк в C - респект. Приятно, что на мою статью обратил внимание опытный и грамотный специалист. Я не могу сказать, что не знал про этот недостаток, но на этапе написания работы времени минимизировать такие допущения у меня не оставалось, а для статьи я решил исходники не переписывать, чтобы оставаться до конца честным (иначе это была бы уже не моя ВКР, а что-то совершенно отдельное).
По самой работе, практикам ИБ и прочему - если бы это касалось реальной разработки устройства в рамках организации или стартапа, подход в принципе сильно бы отличался. Не только по качеству кода, но и к проектированию устройства и определению механизмов защиты в принципе. Про модель угроз я уже выше написал, почему пришлось от нее отказаться.
Я никогда не утверждал, что это самый эффективный и работоспособный вариант. Но правда я верю, что он не бесперспективен как минимум. Отсюда вопрос: если вы ознакомились со всеми опубликованными частями цикла или посмотрели оригинал ВКР, как вы думаете, в каком направлении углублять это исследование, чтобы получилось что-то реально рабочее? Есть у вас какие-то предложения? Может завязать определение механизмов защиты на сложности реализации атак по потенциалу злоумышленника или в мат модели показатели приоритета расширить в соответствии с МУиН?
Спасибо, что поделились своим мнением
По поводу модели угроз я с вами согласен. У меня были мысли хотя бы минимально определить нарушителя в рамках дипломной работы, но она в итоге и без того вышла достаточно объемной, поэтому решил опустить часть с МУиН.
Относительно защиты - я в самой статье упоминал, что цель заключалась не в демонстрации наиболее правильного процесса обеспечения безопасности устройства и концепции безопасной разработки, а в том, как в теории можно использовать методику на математической модели, которая мной в первой части описывалась.
Если бы я полноценно подготовил МУиН на ИС из пользователя, устройства и мобильного приложения, дипломная работа стала бы толще ещё на несколько десятков страниц, но в рамках реальной разработки она безусловно нужна.
Спасибо за то, что прочитали статью и написали комментарий
Огромное спасибо, что прочитали статью. Отдельное спасибо за то, что считаете мою статью крутой. Не забрасывайте тему безопасности IoT. Она затрагивает много важных и актуальных вещей
С трансформатором вариант хороший. Тоже возьму на вооружение
Ну оно как-то так вышло, что прошло стороной мимо меня. После вашего комментария поинтересовался
Спасибо, что прочитали статью и написали комментарий
Огромное спасибо, на будущее учту
Да, питаю от USB.
Пробовал запитать преобразователь от платы контроллера, но мне совершенно не понравился писк, который начинал исходить от него. Скорее всего проблема в самом преобразователе, но другого не было. Поэтому решил дополнительно его питать, чтобы не переживать за его работоспособность на защите (если бы он перегорел прям перед дипломной комиссией, спецэффект получился бы крутой, но мне все таки хотелось показать работающее устройство)
По марке вообще не уверен. Я сам пытался найти, но безуспешно. Просто когда-то давно отковырял откуда-то. На мультиметре проверил, все было ок, а большего для этого проекта мне было и ненужно
Гальваническую развязку я вообще делать не хотел. Питание пришлось увести как раз из-за моей неуверенности в преобразователе.
Если честно, пришлось гуглить, чтобы понять, о чем вы говорите. Хотя про Алекса я прекрасно знаю, но как-то упустил шумиху вокруг его проекта. Не совсем понимаю, о чем конкретно вы хотите сказать: вы имеете ввиду, что я взял идею Алекса и выдаю за что-то свое? Тут есть несколько моментов:
Я не думаю, что взять светодиодную матрицу и подключить ее к микроконтроллеру - это что-то из ряда вон выходящее. Таких проектов тьма. Они были, есть и будут вне зависимости от того, кто и что делал ранее в этом направлении
Сколько не смотрел, не увидел у Алекса ни намека на электрохромную пленку в его проекте
В GyverLamp использовался ESP8266 и управление по Wi-Fi. Я использую ESP32 и управление по BLE. Потому что мне нужно было устройство с BLE для дипломной работы
Форм-фактор. Не видел ни одной интерпретации GyverLamp в том корпусе и виде, что есть у меня
Я просто собрал устройство с BLE без механизмов защиты, чтобы продемонстрировать его на защите и в последствии получить к нему несанкционированный доступ. Вообще не преследовал никаких целей что-то продать, или представить какую-то мегакрутую идею.
Проект Алекса крутой - у него там и эффектов куча, и режимы поинтереснее. У меня не было стремления сделать что-то подобное. Для диплома нужно было устройство - я его сделал. Все просто
Я бы очень хотел. Если появится возможность провести более глубокое исследование, обязательно займусь.