Дистанционно управляемый центральный замок на Arduino и NRF24L01 (Часть 2: алгоритмы защиты канала)

Не знаю. Тестирую на расстоянии 3 метра; работает отлично. В инете видел, что при хорошей антенне можно обеспечить рассотяние до нескольких километров. Я планирую засунуть антенну в стойку, так чтобы между машиной и ключом было лишь стекло и накладка стойки. В ключ — тоже антенну, кусок провода или "пружинку".

Все зависит не от ардуино иде а от рук ;) У меня все ок, памяти хватает код вполне так себе. Вотч дог да нужен тут я согласен, а на сях я и так пишу уже лет 15 ))))
Кстати это не ардуина "любит виснуть на сложных алгоритмах", это надо следить за утечками памяти, и тогда и виснуть ничего не будет.

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

хз будет виснуть, перепишу сразу машинными кодами )

Не очень понял, а разве это не почти тоже самое, что Rolling Code? Суть то та же, реализация просто другая, и уязвимости те же.

Это не роллинг — принятый уже 1 раз хеш в применике больше никогда непрокатит.

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

Для меня роллинг — это битовая ротация :) Cчетчика в данном случае в хеше нет = простое последовательное хеширование

Да нет, вот его описание: en.wikipedia.org/wiki/Rolling_code несмотря на то что счетчика нет в хэше по сути сам хэш и последовательное применение хэш функции на предыдущий результат и является этим счетчиком.

Алгоритм предложенный — состоит из 2х используемых разными концернами. Использовались немцами и японцами. Записанная посылка закрытия машины в данном случае ничего не даст — 1) машина закрылась валидным хешем 2) код команды в посылке вместе с передаваемым хешем криптован таблично ксором.

Так как каждый раз будет менятся и хеш и команда, и вся посылка еще будет ксорится на таблицу которая каждое нажатие на кнопку будет меняться — то сканирование тут не поможет. Если интересно как запихать в 128 байт еепрома всю таблицу в 200т хешей в брелке — могу подсказать. Но — это уже для финишной отладки, — для начала реализуйте так как есть хотябы.

Для начала ответьте мне на пару вопросов:

1. Связь односторонняя?
2. Каков принцип защиты от перехвата и проигрывания ранее сохраненного кода?

128 байт еепрома это не предел, можно внешнюю подключить, другое дело я не пойму зачем там эти хэши вообще нужно хранить если достаточно применять одну и ту же хэш функцию на предыдущее значение — это даст следующий хэш… просто то что вы описываете до боли напоминает мне вот это: en.wikipedia.org/wiki/Sec…-based_one-time_passwords а в частности вот это: en.wikipedia.org/wiki/Hash_chain

Так написал же — но разжую. Cвязь односторнняя.
Посылка имеет открытую часть PP PP PP XX XX и далее закрытая YY YY YY YY YY YY YY YY ZZ ZZ СС СС.
PPPPPP — преамбула для выделения того что это вообще наша посылка.
XXXX — указатель на таблицу ксора посылки
YYYYYYYYYYYYYYYY — 8ми байтный хеш
ZZZZ — команда.
СССС — контрольная сумма.
Перехват этой посылки ничего не даст — 1) Это постановка машины на охрану 2) Если машина встала на охрану — хеш становится использованным.
Если машина не увидела ваш брелок :) и злоумышленник перехватил ваш пакетто перехваченная посылка в лучшем случае закроет машину. От подмены кода операции нас защищает таблица ксора посылки и контрольная сумма с алгоритмом на ваш выбор. Все.
Перехват ранее полученной команды открытия — уже не валиден, так как хеш уже использован. Мыж сохраняем ранее использованный хеш. Хеш основа лежит в брелке — как и вся цепочка хешей. То есть 0 хеш — это выбранные некоторым образом :) 8ми байт, 1 хеш — 8 байт хешированные вашей уникальной функцией от 0 хеша, 2 хеш — тоже от 1го хеша, … 200000хеш = 8 байт хешированные 199999 хеша.
Каждую посылку — брелок выдает минус 1 из таблицы заранее просчитанных хешей.Указатель на валидный хеш в брелке так же вычитает из значения единицу. В оконечном устройстве сохраняется использованный крайний. После получения пакета по радиоканалу, его расшифровки и проверки контрольной суммы выделяется посланный хеш, делается операция его хеширования (в случае неудачи несколько раз — но число ограничено о чем писал выше) = при совпадении хеша сохранненого в оконечном устройстве, сохраняется уже полученный хеш взамен хранимому и далее — рассматривается код команды. Все.

з.ы. Можете попробовать :) построить цепочку последовательных операций хеширования от одного числа (мы же за хеширование говорим — фунция нереверсивная (пример интеграл от площади некой поверхности например — далеко канеш — но смысл тот-же)
Диалоговые системы это хорошо, но проще и комфортнее писать математику, чем городить дуплексный канал.

А, кажется понял, здесь безопасность строится на том, что после открытия — следует закрытие, которое делает команду открытия (даже сохраненную) не валидной? Кстати формат пакета очень похож на KeeLoq: en.wikipedia.org/wiki/KeeLoq

1) перехватываем команду снятия с охраны и записываем ее себе (предварительно блокировав приемник)
2) повторную посылку сохраняем себе а приемнику — кидаем сохраненную в п. 1 команду; машина успешно открылась, а в памяти граббера лежит следующий валидный код снятия с охраны
… едем за челом, дожидаемся пока он припаркуется, и попытается закрыть машину…
3) перехватываем команду закрытия, блокируем приемник, а затем кидаем в приемник ранее сохраненную команду открытия. Моргают поворотники, чел веселый идет по своим делам, а машина остается открытой. Как вариант?

Или так:

1) перехватываем команду снятия с охраны и записываем ее себе (предварительно блокировав приемник)
2) повторную посылку сохраняем себе а приемнику — кидаем сохраненную в п. 1 команду; машина успешно открылась, а в памяти граббера лежит следующий валидный код снятия с охраны
… едем за челом, дожидаемся пока он припаркуется, и попытается закрыть машину…
3) наглухо блокируем приемник (или передатчик) не особо важно, так что челу после долгих попыток приходится закрыть машину — ключами.
4) разблокируем все что заблокировали, проигрываем код и открываем двери

Я не взломщик, но тут вариаций много, кроме того все описанное вами справедливо для Rolling кода, там все тоже самое: любая команда делает невалидным любой предыдущий сохраненный счетчик / хэш как его не назови суть не менятся. Или я не улавливаю сути?

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

Да я понимаю что неугоняемых машин не бывает, просто тут уж чем богаты, было два NRf'а на них и делаю, было бы что — то другое делал бы на другом. RTC это тема, я уже писал где то в каментах, но их уведет в любом случае если только они не атомные или не синхронизированы через GPS к примеру. Еще в двусторонней связи меня привлекает то, что позднее можно будет приделать еще какие нибудь плюшки, типа кнопки которая бы опрашивала приемник на предмет закрыты замки или нет или еще чего нибудь. Короче двусторонний канал лучше чем односторонний )

Мне реально понравилось это "От подмены кода операции нас защищает таблица ксора посылки и контрольная сумма с алгоритмом на ваш выбор", Вы единственный во всем топике, кто упомянул о подмене кода операции в теле посылки )

Синхронизацию времени можно ввести через туже команду, время ж может быть относительным. В брелке даллас считает, в базовом блоке тоже даллас считает, но есть возможность через команду с брелка синхронизировать время БРЕЛОК->БАЗОВЫЙ БЛОК. Разбег у современных часов очень незначитаельный — да и ввести синхронизацию по например двум нажатым кнопкам :) или еще какому незатейливому алгоритму — не составит большого труда. Ну и в том же алгоритме в текущем относительном времени можно иметь "рабочее окно". Пожалуй закончим :)

Слишком много букаф? Скролл задымился?

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

А, понял…

полностью согласен, пусть будет не 73000, а 100000 чисел, скорее девайс поломается, чем будет использованы все числа, тем более в ардуине random прекрасно работает

Где защита от "replay" атаки? Проигрывание ранее записанного кода?

вычеркивать использованные и сохранять вычеркнутые

Как? Не забывайте что это не IBM PC с гигом памяти, а МК где либа для использования хэш таблиц займет уже неплохо откушает, не говоря уже о том чтобы писать алгоритмы на чтение и выборку этих вещей из EEPROM. Плюс немаловажную часть проблемы составит отключение питания (что если питание вырубиться в момент записи в EEPROM?) и т. н. wear leveling (ячейки EEPROM имеют вполне определенное конечное число циклов перезаписи)

ну такое чувство, что Вы старлайну хотите сделать конкуренцию, защита Вашего девайса, в том, что оно уникально, шифрование нужно там, где происходит массовое производство, так как есть одинаковые девайсы

Не не, ни в коем случае не претендую, просто не знаю другого способа хоть как то защитить канал

Злоумышленник перехватывает три числа, и проигрывает их позже.

и? эти числа уже не используются ни ключом ни замком.
я же не даром указал конечное кол-во чисел, а не просто тупо генератор СЧ.

Тогда не понял, а каким образом эти числа будут исключаться из массива "свободных"? Где эта инфа будет храниться, и что еще более интересно как она будет оттуда выбираться? То есть как решить проблему условно говоря поиска нужно инфы в массиве EEPROM?

Я не спорю, что если бы у меня была база данных, то я бы не парился с этим вообще, а тупо выбирал бы это все из массива сгенерированных значений.

например просто отправлять последовательно 3 числа. И стирать их в памяти ключа и в памяти замка. Ни к памяти ключа ни к памяти замка у "злоумышленника" доступа нет. Чисел хватит.
Даже предположим, что злоумышленник заглушил приемник замка, и перехватил данные с ключа, что бы ПОТОМ ими воспользоваться. Пользователь тупо жмет кнопку снова. Замок открылся. Но в замке и в ключе уже НЕТ ни первой, ни второй комбинации, т к. замок стер ВСЕ до 2й комбинации. Злоумышленник ночью подкрадывается к машине… передает перехваченную комбинацию… УПС. Нифига не получилось (( Она УЖЕ не действует.
Способ угнать только один — пользователь нажал кнопку, комбинация перехвачена, замок "оглушен" на это время. Пользователя "блокируют", что бы не нажал еще раз, воспроизводят перехват… Вуаля! получилось. Пользователя топят в нужнике и уезжают на машине.

Ну ок будем стирать, а как искать не стертое? :D Старым добрым проходом пока не наткнемся на что то что отличается от 0?

а почему нет? жалко 73000 циклов? в любом случае, реализация в разы проще любых, даже целочисленных, вычислений.
всему есть цена вопроса. Если это сигналка на бентли — то делать ее на ардуине и так пижонство. Если это чисто академическая задача — то ради бога, можно и поизвращаться от души с изобретением собственного алгоритма.
В любом случае — ЦЗ без обратной связи на ардуино — это игрушка, которая нужна только ее создателю и двум-трем таким же экспериментаторам )
ИМХО

Да жалко )

приблизительно представляете себе количество циклов в контроллере без аппаратного 32х битного умножителя для перемножения 2х 64х битных чисел? ;)
а теперь прикинем, длину программы и кол-во циклов для выборки 3х последовательных не нулевых значений из одномерного массива.

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

каждому своё

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

это уже обратная связь. Я предложил с односторонней )

Опять "проверяет входит ли этот ключ в массив", память это не массив, поэтому проверка эта в данном случае — будет весьма нетривиальной.

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

часы уплывут

при заведенной машине, ключ и модуль могут включаться, что синхронизироваться.
и просто добавить погрешность в 1-2 минуты, так как если верить производителю DS3231SN вроде максимум 2 минуты в год погрешность.

Ну тут получается опять двусторонняя связь, иначе как обе стороны узнают о том что машина заведена и можно синхронизироваться? Если связь односторонняя то получится что замок будет знать, но не сможет сказать, а ключ не сможет услышать потому что он только передатчик. Про погрешность 2 минуты в год, что то слабо верится. Может быть в случае если температура одинаковая будет… Но сама по себе идея отличная!

Тут можно вообще брать время и использовать его (после округлений) как индекс в таблице предГенерированных паролей (шифроблокнот активно продвигаемый в этой ветке).

После нажатия на кнопку пульт не сразу уходит в сон, а допустим через 5 минут или ожидает ответа от блока, что двери не открывали и машина закрылась. (но это диалог, хоть и кратковременный)
Как вариант экономии питания уходить в сон, и каждые n минут просыпаться, что бы проверить:
1. Емкость ключа, но тут минус руками коснулся он меняется,
2. Сила уровня радио сигнала, если 100% уровень то скорее всего ключ в машине;
3. Что то аналогичное RFID метке (штатные иммо в ладе так и работают) + прерывание.

Вы первую часть читали? У меня там принцип другой, сна нет.

Не правильно выразил свои мысли:
Я к тому, что перед отключением МК по питанию, выжидать 5-10 минут, что бы определить ключ в машине или нет.
Алгоритм такой:
1. Нажата кнопка
2. включили питание
3. подали сигнал.
4. Ожидаем (уровень сигнала 100%, RFID или другое событие в машине) — синхронизируем время, и выключаемся
— 4.1. Нет события, уходим в сон на 2 минуты
— 4.2. Просыпаемся выполняем пункт 4, потом 4.1.
— 4.3. Если после 5 попыток ничего не произошло, выключаемся.
+Знаю, что сильно городить не хотите, но из плюшек можно добавить:
5. Если оставить диалог на эти 5-10 минут, то проснулся спросить у блока машина закрылась (двери не трогали)?
5.1 Да, тогда уведомить водителя и выключить питание на ключе,
5.2 Нет уходим в сон.

Еще по поводу терабайт, размер пакета в NRF модуле ограничен 32 байтами если я не ошибаюсь, поэтому там далеко не терабайты )

ну flash накопители никто не отменял, а в eeprom можно сохранять не сами числа, а их индексы в массиве, меньше занимть будут, хотя на сколько помню, ограничение eeproma не в размере, а в количестве перезаписи

Как их искать? EEPROM / FLASH это не хэш таблица а блоб, для того чтобы прочитать нужен адрес, а в случае предложенной вами реализации алгоритм по работе со всем этим добром выйдет похлеще чем использование AES256.

хорошо, пусть не рандом, пусть по порядку использует, а в eeprom записывает последний использованный ключ

Что если при записи возникнет сбой? Что если посылка от брелока не дойдет до базы? Что будет если ячейка куда вы пишете последний код — выдаст отказ?

а что если тупо аккум сел? и с каких это пор в eeprom не надежно записывались данные?

А что будет если он сядет в заводском варианте?

опять же заводское решение — массовое производство, поэтому там другие решения

Ну какие другие решения? Ну что там аккумулятор от танка прячется в стойке с левой стороны? Спецово чтобы запитать ЦЗ в случае отказа основного аккумулятора?

Я все это проходил и думал над этим не раз, поверьте мне. Если вы можете накидать алгоритм хотя бы в формате блок схемы, то я буду только рад выкинуть все это шифрование и заменить его на блокнот с паролями.

ну я пытался упростить Вам жизнь, решение в любом случае за Вами, это же Ваш проект, а следить я в любом случае буду, проект интересный

Да я понимаю, просто яж сразу сказал что не выйдет ничего с этим. Другой интересный вариант можно было бы рассмотреть — это генерация паролей на основе времени. Но для этого нужно чтобы у каждого блока был RTC, да еще и расходиться это будет нехило. Как бы вариантов масса, но во всех из них нужно чтобы обе стороны были каким то образом синхронизированы.

я бы например, если бы делал, то на gsm модуле, с функцией автозапуска, думаю летом к этому вопросу приду, может Вы и правы, единственное, алгоритмы шифрования в инете пруд пруди, я бы не изобретал велосипед

Думал над этим, но GSM может перестать работать на подземной парковке. Как быть с этим? Стоп а я и не писал своих алгоритмов шифрования, я же вроде бы упомянул что используется AES256?

всегда есть штатная сигналка, и в таких случая, используем ее, а что если рядом с вашей парковкой стоит не хилая глушилка всех сетей. тогда и Ваш девайс заглючит? универсальный механизм — это зло, а еще лучшее — враг хорошего))))

У меня нет дистанционного замка. Я почему и начал все это делать. Просто ЦЗ есть, а брелока и юнита в машине который мог бы с ним работать — нет.

не, ну тго, тупа с ключа открывается, но в такие моменты, цз проверяет, что нет сети, и не противится)))

Ну короче как есть так есть, GSM не хочу, вайфай тоже не хочу, хочу просто и безопасно, по мне так описанное попадает под эти критерии. Если у вас есть идеи как улучшить то выслушаю с удовольствием!

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

А Bluetooth? :) и телефон

Bluetooth тоже думал, но меня будет ломать доставать каждый раз телефон и включать bluetooth. Это уже на любителя.

у него дальность не большая

Можно еще за стекло спрятать www.ironlogic.ru/il.nsf/htm/ru_MatrixIIK и открывать картой :)

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

Перепутал чуть чуть, там сигнал шлет машина как только кто нибудь дергает ручку. Короче один чел дергает ручку и принимает сигнал от машины, ну а дальше я уже написал )

Круто :) На каждого умного найдется другой умный. Также можно поступить и с двухсторонней сигнализацией… только как-то заставить владельца нажать кнопку :)

Дать ему по голове и попросить вежливо нажать на кнопку )
Меня это вообще поразило, поскольку защиты от этого не может быть вообще никакой.

От удара по голове ? Мередесовский брелок можно спрятать в экранирующий футляр. А так пауки и эвакуаторы решают все проблемы угонщиков :))))

Ну если его спрятать в футляр то теряется весь шарм использования такой люксовой системой. Этож надо его доставать )

может, каска строительная)))

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

может просто под кожу вшить RFID метку?

Я рассматривал этот вариант, но неудобно будет с пакетами открывать двери.

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

Число сгенерированное замком в пункте б, не совпадет с тем что будет им принято в пункте г.

Когда изобретали велосипед википедию не читали)))

Спасибо, но я не изобретаю велосипед и не вчера этим заниматься начал ;)
только вот ассиметричного шифрования ардуина не потянет.

так а зачем это ? есть же модули с брелками.

Можно поподробней, какие модули с брелками?

да конечно. я про такие —
ru.aliexpress.com/item/Fr…CASE-FOR/32378391867.html

ru.aliexpress.com/item/sm…Receiver/32393890770.html

ru.aliexpress.com/item/Hi…mpatible/32267206143.html

Это неизвестный китайский Rolling Code (если он вообще там есть), я описал как он ломается. Подходит для управления розеткой, но не для данного случая ИМХО