Авторизация устройств

Всем привет,

Есть у меня своя поделка устройств, которые обмениваются с центральным ХАБом командами и данными по радиоканалу. Заморочился я зашифровать протокол обмена, чтоб данные не светились в эфире. Прикрутил алгоритм AES (либа от ST), все хорошо, теперь хочу еще усилить, дело в том, что у меня есть исполнительные устройства, например выключатель, которому посылается команда, так вот одинаковые данные зашифрованные AES тоже будут одинаковые что не составляет труда перехватить радио посылку и отправлять ту же самую команду но зашифрованную и устройство её примет и обработает. Какие мне видятся способы защиты:
<ul>- самое простое - посылать дополнительный случайный байт (два, три), который будет являться "шумом", тогда кодированные данные всегда будут разные, но все равно повторив одну такую посылку устройство её примет.
- посылать счетчик команд и не принимать команды, если этот счетчик не увеличивается или меньше чем ожидается, уже лучше, но нужно помнить последнюю команду и как-то синхронизироваться с хабом.
- использовать токен и сеансы (сессии) - при включении устройства оно посылает на ХАБ запрос, хаб генерит токен и отсылает его устройству, далее идет обмен данными, "подписаными" этим токеном (например CRC32). Токен протухает на ХАБе раз в N времени и нужно его заново генерить. Все это естественно еще шифруется AES. Вроде не сильно сложно. Но опять же - в пределах одного токена посылка для одной команды будет одинаковая.
- ваш вариант?</ul>

0

счетчик нужен, причем, достаточного размера и не с нуля (можно счетчик+nonce).
нужно рассмотреть атаку с рандомными посылками. если у вас там байт команды и байт счетчика, то одна из 64к случайных посылок сработает, и т.п..

0

Вот и я к этому больше склоняюсь, но со счетчиком нужен какой-то алгоритм его сброса и обновления. Т.е.е ситуация когда команда не дошла (а без подтверждения команды мы не можем знать дошла она или нет) и когда устройство было отключено, п потом его подключили.
И еще когда команда дошла, но не дошло подтверждение.

0

Еще один вариант, устойчивый к перехвату, но бессильный против утечки - тогда теряется всё и сразу.
В пакете говорится: "От Иоанна гл.15 ст.27 стр.4 сл.7". Библия содержится на борту и сервера, и клиента, но цедится в эфир тонкой струйкой и никогда не будет накоплена целиком у перехватчика.

0

Передатчик в открытом виде передаёт текущее время в миллисекундах (открытый ключ) и закодированное этой меткой слово управления из нескольких байт по своему алгоритму (AES + XOR +сдвиг и их комбинации).

0

otixsom, два варианта защиты от replay attack из самых тупых (оба исходят из того, что ключи шифрования не скомпрометированы и что пакет проверяется на подлинность):
1. Использовать текущее время (требует синхронизации часов)
2. Three-way connection: мастер шлёт запрос, слэйв отвечает (добавляя в пакет случайное число), мастер шлёт запрос на действие уже с этим числом. Запрос на действие, естественно, принимается только в течение короткого промежутка времени после генерации "токена" (по сути, та же схема, что у вас для токена, но токен одноразовый и протухает очень быстро)

Собственно, что синхронизацию часов, что "регенерацию" счётчика можно проводить, если слейв принял пакет с неверным временем/счётчиком. Т.е. при получении такого пакета он не выполняет команду, а шлёт серверу запрос на синхронизацию и какое-то время ждёт ответа на него.

0

Совместить 2 и 3 варианты.

При включении исполнительное устройство шлёт пакет, содержащий идентификатор устройства и случайный ключ доступа, по 32 бита каждый.
Шлёт пока хаб не ответит пустой командой, содержащей этот ключ доступа. Каждая команда от хаба устройству содержит
индивидуальный для устройства 32-битный счётчик, который увеличивается на 1 при каждой отправке.
Если исполнительное устройство получает значение счётчика, которое увеличилось более, чем на 2^31 от последнего - команда игнорируется.
Если от хаба не было корректной команды N секунд, то устройство опять запускает процесс отправки ключа.

CRC32 не нужно, достаточно включать в 128-битный пакет значения счётчика и ключа.
Подразумевается, что шифрование AES используется в обе стороны.

Такая система позволяет исключить возможность управления исполнительным устройством, но не защищена от DoS-атаки на хаб.

0

Использование времени отпадает в любом случае - не хочу ставить внешние часовые кварцы - много места занимают и часть устройств уже работает "в полях".
С таблицей тоже не вариант, 16КБ флеша из них занять 1КБ данными тоже не хочу.
Пока рассматриваю варианты со счетчиком и одноразовым токеном.
YvomSh - ваш вариант - это вообщем-то счетчик.

0

Сообщение от otixsom YvomSh - ваш вариант - это вообщем-то счетчик.

Ну так я и пишу, что это ваши же варианты 2 и 3 - счётчик+токен.
Если использовать только лишь счётчик - потребуется синхронизации этого счётчика, и устройство не защищёно от атаки сразу после сброса питания.

0

16КБ флеша из них занять 1КБ данными тоже не хочу.

ты напиши на какой тиньке AES делаешь... а мы посмеёмся :)

0

Сообщение от friiom ты напиши на какой тиньке AES делаешь... а мы посмеёмся :)

я уже посмеялся:

Сообщение от friiom по своему алгоритму (AES + XOR +сдвиг и их комбинации)

0

[QUOTE="friiom"][QUOTE="Цитата:[/QUOTE]

16КБ флеша из них занять 1КБ данными тоже не хочу.

ты напиши на какой тиньке AES делаешь... а мы посмеёмся :)
Пока-что я посмеялся с твоей невнимательности.

0

Использование времени отпадает в любом случае - не хочу ставить внешние часовые кварцы - много места занимают и часть устройств уже работает "в полях".

такие тоже много места занимают?

https://www.cyberforum.ru/savedimages/2016/12/22/xrsfnqxd2ygdsewysy.jpg

А если много, то сколько будет немного? В реальных цифрах.

Еще момент: устройства "в поле" на внутреннем RC-генераторе? Даже с их точностью уход по времени за сутки будет не смертельный, можно загрубить время для смены ключей по времени (набор ключей забить и менять). Тем более раз обмен уже реализован, подстроить время проблем не составит.

0

Да тут даже дело не в свободном месте, а в доп. компонентах.
А само время убегает очень сильно. Устройство находится большую часть времени в STOP Mode (STM32F030F4) и при этом RTC внутренние убегают так, что WakeUp настроенный на каждую минуту по факту плавает +/-8 сек. Мне это сейчас не критично вообще, но на него надеяться точно нельзя.

0

...жаль, что дополнительных компонентов низзя: RTC в SMD выше отпали, GPS по понятным причинам вообще несерьезно из-за размеров, возможного отсутствия видимости на спутники и существенном удорожании устройства в поле. Но, когда не было GPS уже были сигналы точного времени и сейчас по радиоэфиру (60, 66 кГц и т.д.), например от длинноволнового DCF77. Технология стара как само радио, а впихнуть функцию синхронизации от тиков в радиоэфире смогли даже в наручные часы, в те же часы Casio с функцией радиоконтроля (GW-7900-RD-4ER). Вкратце. Места хватило людям.

--- вариации на тему

Кстати, есть аналоговый радиоприемничек все в одном в TO-92 корпусе:

https://www.cyberforum.ru/savedimages/2016/12/23/tavadkzqbm3uybanm.png

контур ему и готовая часть для синхронизации с радиоэфира. MK484 около одного абамы.

0

Сообщение от Ymk Сообщение от friiom ты напиши на какой тиньке AES делаешь... а мы посмеёмся :)

я уже посмеялся:

Сообщение от friiom по своему алгоритму (AES + XOR +сдвиг и их комбинации)

Хорошо что смеющихся много :)
Вот реальный пример подобной комбинации методов одной программы 10-ти летней давности - тут и микрософт крипт и ксоры и роры и ролы...
в качестве источника генерации ключа используется имя файла...

https://www.cyberforum.ru/savedimages/2016/12/23/tkhrr5yshrwtsdrqqsnpyejr.jpg
аналогично для передачи данных можно использовать любое меняющееся число, в том числе и текущий отсчёт времени, в том числе несинхронизированного с мировым и жыпээсным абстрактного локального в процессоре времени... каждую микросекунду у вас будет новая база для создания ключа открытого пароля.

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

0

Сообщение от otixsom С таблицей тоже не вариант, 16КБ флеша из них занять 1КБ данными тоже не хочу.

Уже писали много раз, 32Кб там флеша, плюс 32 бит таймер. Аналогично у многих других ходовых STM32(103С8, 407VE...) флеша больше в 2 раза, а у некоторых больше еще и ROM.

0

Сообщение от Riftistor Сообщение от otixsom С таблицей тоже не вариант, 16КБ флеша из них занять 1КБ данными тоже не хочу.

Уже писали много раз, 32Кб там флеша, плюс 32 бит таймер. Аналогично у многих других ходовых STM32(103С8, 407VE...) флеша больше в 2 раза, а у некоторых больше еще и ROM.
Если уж на то пошло, то там почти Гиг свободной памяти!... Но использовать её в продакшене нельзя ибо не гарантируют. Хотя я на всех чипах, которые у меня были тестировал её и ни разу не натыкался на сбойные страницы...

0

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

Так можно просто зажать владельцу яйца плоскогубцами и без всякого там IT и высоких технологий ))

Сообщение от pytrpts если иметь полный исходник или исполняемый код, то расшифровать подобные перехваченные передачи не составит труда... но не зная алгоритма шифрования при переменном по времени ключе передаваемые защищаемые данные "Команда Включить утюг" будут не совпадать и нельзя будет набить статистику....

Исходник будет открыт.

0

Сообщение от pytrpts если иметь полный исходник или исполняемый код, то расшифровать подобные перехваченные передачи не составит труда... но не зная алгоритма шифрования при переменном по времени ключе передаваемые защищаемые данные "Команда Включить утюг" будут не совпадать и нельзя будет набить статистику.... Исходник будет открыт.

Зато любой сможет помочь соседу со своего смартофона, послав команду "Вырубить перфоратор у долбодебила в кв. 666".

0