Какие технологии помогут сделать безопасный канал передачи данных?

Question

[Олег Правдин]

Добрый день. Хочу собрать два устройства на микроконтроллерах и организовать безопасный канал связи между ними. Скорость мало важна т.к. объемы данных малы: что-то вроде охранной сигнализации на машине и пульта к ней. Критерии такие:

• Данные внутри канала должны быть зашифрованы (логично)
  
• Соединение поддерживается лишь на время передачи данных
  
• Устройства должны иметь возможность проверить, что общаются между собой, а не с другим устройством (что-то вроде SSL Pinning)
  
• Система должна быть защищена от повторной отправки пакетов (если 3 сторона решит переслать один из пакетов устройств, то он не должен привести к повторному выполнению команды).
  
• Выполняемые операции должны более-менее укладываться в ресурсы микроконтроллеров
  

Представляю себе это как некий обмен пакетами, содержащими помимо полезной нагрузки еще "отпечаток" уникального ключа устройства и счетчик пакетов в данном сеансе общения и номер сеанса (чтобы пакеты с одинаковой нагрузкой отличались всегда), однако скорее всего это уже изобрели до меня, а я не знаю что именно мне надо искать. Вопрос: в каком направлении мне надо копать, чтобы изучить имеющиеся технологии в этой сфере (то, что наиболее близко к моей теме)

Comments

[hint000]

скорее всего это уже изобрели до меня, а я не знаю что именно мне надо искать

Рассмотрите https и рассмотрите ssh. Если вдруг решите, что оба варианта не совсем то, что нужно, тогда следует сформулировать, что конкретно не устраивает в этих протоколах.

что-то вроде охранной сигнализации на машине и пульта к ней

А с физическим уровнем вы определились? Например, Wi-Fi для подобного применения выглядит странно (мягко говоря). А если ваш вопрос включает в себя и физический уровень, то это, во-первых, сложный вопрос, а во-вторых, потребуется техзадание.

[sim3x]

Зачем оно тако может понадобиться?

[Олег Правдин]

sim3x, на примере сигнализации:
Шифрование нужно, чтобы содержимое пакетов с данными оставалось скрытым от глаз и чтобы нельзя было установить, какое именно взаимодействие произошло между устройствами.
Привязка к устройствам (3 пункт) нужна, чтобы нельзя было открыть сигнализацию ключом, который полностью воспроизводит протокол передачи данных. Это, своего рода, ключ от замка.
Защита от повторной отправки нужна, чтобы нельзя было записать пакеты данных, которыми открывали замок в прошлый раз и отправить их повторно.

[sim3x]

Олег Правдин,
Возьмем например сигнализацию
Я ставлю глушилку на весь диапазон...

Защита от повторной отправки нужна, чтобы нельзя было записать пакеты данных, которыми открывали замок в прошлый раз и отправить их повторно.

если у вас будет кешироваться ключ автентификации, то остальное получат простым перебором

А ведь еще будут ошибки при кодинге, такого же плана

Если у вас реальные планы создать что-то - наймите консультанта по крипте

[Олег Правдин]

sim3x, планы есть, но исключительно спортивный интерес, для которого было бы непозволительной роскошью нанимать консультанта по крипте :) Может быть есть какая-то литература, которую можно почитать на эту тему?

[Олег Правдин]

hint000, https и ssh это слишком тяжелые штуки для микроконтроллеров семейства Arduino, к сожалению. Если бы речь шла о чем-то ARM'ном, то еще можно было бы думать об этом. С другой стороны можно рассмотреть переход на STM32, но это уже другая история :)
С физическим уровнем вопрос отдельный, начну с недорогих модулей на 433 мГц или модулей на микросхемах nRF. Они весьма бюджетные - можно будет обкатать наработки, а проблемы решить либо допиливанием софта, либо заменой модулей на что-то более подходящее.

[sim3x]

Олег Правдин, тогда отправляйте открытым текстом, плохая крипта хуже чем буз крипты

Там слишком много ньюансов

https://ru.wikipedia.org/wiki/Криптографическая_ст...
Потом ассиметричная/симметричная крипта
Потом искать материалы по прикладному примнению на уровне сети

Answer 1

[athacker]

Для этого используется TLS. Это спец-протокол, который решает все вопросы, которые вы хотите решить. Там есть возможность шифрования, взаимной аутентификации как клиента, так и сервера и всё такое. Минусы -- вычислительно сложно. Т. е. на слабых микроконтроллерах процесс установления TLS-сессии может занимать время, плюс расход батарей. Плюсы -- уже есть готовые либы под множество платформ/архитектур, которые можно использовать, чтобы не изобретать велосипеды и не писать своё.

Гарантия от replay attack достигается тем, что для передачи команды сторонам нужно аутентифицироваться, т. е. это всегда двусторонний обмен. Технически сначала стороны обмениваются сертификатами, проверяют их, затем на основании алгоритма Диффи-Хэллмана формируют симметричный ключ шифрования, который будет использоваться для шифрования потока данных. В общем случае, в каждой сессии этот ключ будет разным. Есть механизмы кэширования и сохранения стейта, для ускорения установления TLS-сессии (допустим, на случай если клиент недавно уже подключался) -- это нужно, чтобы увеличить скорость согласования TLS-соединения), но это всё опционально и отключабельно.

Внутрь TLS можно засунуть что угодно -- кастомный бинарный протокол на базе TCP/IP или REST API на базе HTTP -- без разницы.

Answer 2

[CityCat4]

Соединение поддерживается лишь на время передачи данных

Неоптимально. Если стороны проходят жесткую аутентификацию, то она отнимает время и ресурсы. Проще сделать постоянное соединение, поддерживаемое пакетами типа пинга. А для периодического удостоверения, что стороны - все еще те, за кого себя выдают - периодически соединение рвать.

Система должна быть защищена от повторной отправки пакетов

Это работа прикладного уровня

А что касается остального - Вы говорите про IPSec, совершенно однозначно :) Не знаю, правда, как насчет ресурса микроконтроллера.

Comments

[tutuborg]

Неоптимально. Если стороны проходят жесткую аутентификацию, то она отнимает время и ресурсы.

Зато рваная передача экономит батарею.
Аутентификацию вполне можно проводить заранее.

[CityCat4]

tutuborg, А как Вы убедитесь, что стороны все еще те, за которые себя выдают? Ну или скажем так - насколько критично будет подмена стороны? Если это допустим канал передачи данных от пульта сигнализации автомобиля на контроллер - подмена пульта - очень распространенный прием :D

[tutuborg]

CityCat4,

А как Вы убедитесь, что стороны все еще те, за которые себя выдают?

Ровно так же как и при непрерывной связи.
Ключами.

[CityCat4]

tutuborg, Замечательно :) То есть на один пинг батарейки жалко, а на полный цикл аутентификации и авторизации (а в IPSec еслиф че две фазы - то есть ключ вычисляется дважды) - не жалко. Ну, дело Ваше...

[tutuborg]

CityCat4,

То есть на один пинг батарейки жалко, а на полный цикл аутентификации и авторизации (а в IPSec еслиф че две фазы - то есть ключ вычисляется дважды) - не жалко.

Очередной пинг может пойти уже через MiTM и вы этого не заметите - постоянная связь от этого не гарантирует.

[CityCat4]

tutuborg, Дело Ваше... :) Мне поуху, честно говоря :)

Answer 3

[xmoonlight]

Банально:
Добавляйте подпись к запросу с временем и случайным набором символов.
На стороне устройства - запрещайте повторные запросы лет на 10.
Итог: даже зная что Вы отправили, нельзя это никак использовать.

Хотите зашифровать само "тело" запроса (чтобы не читали) - шифруйте любым способом (главное при этом - не используйте TOKEN сеанса для шифрования!).
Здесь подробно.