Продолжение, первая часть здесь: www.drive2.ru/c/2708892/
На сегодняшний день существует два решения:
1. Rolling Code / Hopping Code, ведет начало с самых первых пультов для открывания гаражных дверей, тем не менее на сегодняшний день это процентов 80 из существующих на рынке решений. Очень упрощенно — работает так: в ключе — стоит передатчик, в авто — приемник, процесс кодирования у них такой: в ключе и в авто есть счетчик, каждый раз при нажатии кнопки на ключе — счетчик в ключе увеличивается на единицу. Имея значение этого счетчика и секретный код (т. н. соль) — производится необратимое шифрование (хэширование) и полученный код отправляется на блок приемника (в авто). Приемник в свою очередь увеличивает значение своего счетчика и производит аналогичное преобразование (хэширование) — значения своего счетчика и секретного кода, а затем сравнивает полученный от ключа результат — с вычисленным, совпадает — открываем / закрываем, не совпадает — не делаем ничего.

В этом алгоритме есть одна серьезная проблема, а именно что произойдет если нажатие кнопки на брелоке произойдет вне зоны действия приемника? Если делать все именно так как я описал выше, то счетчик в брелоке увеличится, а счетчик в машине — нет (брелок то не знает и не может знать дошел — ли его сигнал до машины), а потому, в следующий раз когда кнопка будет нажата в зоне действия приемника — двери не откроются, потому — что счетчики рассинхронизируются. Условно в ключе счетчик будет равен 1 а в машине все еще 0, поэтому сравнение даст отрицательный результат и блок приемника должен будет отвергнуть такую команду. Как же это в таком случае работает? В такой ситуации блок приемника поступает следующим образом: окей, значение моего счетчика не совпадает со значением счетчика ключа, а давай — ка попробуем увеличить свой внутренний счетчик на единицу и вновь сравним счетчик ключа со счетчиком приемника + 1? Вновь не совпадает? Давай сделаем это еще раз, и еще раз пока не совпадет. В итоге приемник будет увеличивать значение своего счетчика до тех пор пока его значение не совпадет со значением счетчика ключа (принятым посредством радиоканала), но это ведь не может длиться бесконечно? Ведь в таком случае приемник может надолго уйти в астрал пытаясь подобрать этот код. Поэтому в реальной ситуации количество кодов которые будут испробованы — ограничена неким разумным числом (к примеру 50). В таком случае если принятое от ключа значение лежит в пределах от 0 до 50 — команду можно принимать и синхронизировать ключ и замок (установить значение счетчика в приемнике — равное подобранному), в ином случае не делаем ничего.

К сожалению, благодаря вышеописанной схеме синхронизации — такого рода системы могут быть взломаны, для этого нам понадобится устройство, которое сможет принимать сигнал с брелока и глушить приемник. Работает это так: чувачок идет к своей машине насвистывая последние хиты группы руки вверх и нажимает на кнопку открывания центрального замка. В этот момент — злоумышленник спрятавшийся в кустах неподалеку, при помощи хитрого девайса — перехватывает отправленный брелоком сигнал, сохраняет его куда нибудь и одновременно — глушит приемник таким образом чтобы сигнал брелока не дошел до него. С точки зрения ключа это выглядит так: окей, кнопку нажали, счетчик увеличиваем, посылаем команду приемнику. С точки зрения приемника это не выглядит никак, поскольку он ничего не получил. С точки зрения чувачка это выглядит так: ах блин гребаные китайцы, машина не открылась поэтому я нажму на кнопку еще раз! В этот момент — злоумышленник вновь принимает сигнал брелока, вновь сохраняет его и вновь глушит приемник, а затем выключает глушилку и посылает в приемник первый сохраненный код. Для ключа все выглядит так: окей, кнопку нажали, счетчик увеличили, команду послали. Для приемника это выглядит так: принял команду, сравнил счетчики, все окей счетчики совпадают — открываем двери. Чувачок же в этот момент садится в машину и уезжает. А ведь в этот момент у злоумышленника на руках оказывается последняя рабочая посылка — еще не принятая и не обработанная блоком приемника. Позднее этот сохраненный сигнал будучи посланным в приемник — может быть использован для того, чтобы открыть автомобиль. Конечно это все очень упрощено и в реальности там много нюансов и попыток защититься от подобного рода атак, но принцип именно такой. Проблема здесь кроется в том, что приемник — никак не может удостоверить подлинность передатчика, он вынужден доверять всему, что ему послано и у него нет возможности отличить свой ключ от ключа злоумышленника.
2. Диалоговые коды / диалоговые сигналки, постепенно приходят на смену односторонним (ключ -> замок) системам. Кардинальное отличие данного метода от Rolling Code заключается в том, что на обеих сторонах (и в ключе и в машине) установлены приемопередатчики, благодаря этому не только брелок может послать что — нибудь приемнику, но и приемник в ответ на запрос брелока, может опросить его текущий статус и тут у нас открывается огромный простор для фантазии на тему того как сделать безопасный протокол их взаимодействия. В обобщенном виде алгоритм может быть таким: ключ посылает в машину команду: "открой мне", приемник в авто, берет случайное число, шифрует его по определенному алгоритму и отсылает обратно ключу. Ключ должен расшифровать это число, зашифровать его своим алгоритмом и отослать обратно в авто. Приемник в авто расшифровывает посылку от ключа и сравнивает изначально сгенерированное случайное число с расшифрованным из ключа. Дальше понятно.

Попробуем мысленно взломать такую систему. Допустим мы приняли запрос от ключа и заглушили приемник, как это было описано в предыдущем случае, сохранили его, дали чуваку нажать на кнопку брелока еще раз и в этот момент послали первую (сохраненную) команду вместо той что была отправлена ключом. Приемник успешно примет этот запрос и начнет процедуру идентификации ключа, т. е. отправит в ключ — случайное число зашифрованное по определенному алгоритму с секретным ключом. Ключ успешно расшифрует эту посылку, зашифрует — отправит обратно и замок откроется. На руках у злоумышленника, как и в предыдущем случае — есть последняя посылка ключа, не дошедшая до приемника. Что он будет с ней делать? Ну пошлет он ее в приемник, приемник как ни в чем не бывало сгенерирует случайное число и отправит его… куда? Ключ то с владельцем — дома лежит. Ок, предположим что у злоумышленника есть устройство — которое может прикинуться ключом и в ответ на запрос приемника — отослать что нибудь ему обратно, но что это будет? Не зная ключа с которым было зашифровано число злоумышленник не сможет его раскодировать, а следовательно и закодировать правильный ответ также не представляется возможным.
Получается, что в этом варианте граббер или иное техническое устройство (кроме молотка) здесь применить не получится никак, поскольку для взлома алгоритма нужно знать алгоритм шифрования и секретный ключ, для того чтобы отослать приемнику корректное значение, а это уже выходит за рамки темы автомобильных сигнализаций и начинается криптография, в которой как известно невзламываемых алгоритмов не бывает, бывают лишь те, для взлома которых потребуется несоизмеримое задаче количество времени и врядли кто — нибудь будет этим заниматься; проще будет высадить стекло или найти другую жертву. В терминах информационной безопасности весь этот алгоритм называется "двухфакторная авторизация", каждый раз когда вы логинитесь в интернет банк и он в ответ на ввод вами логина и пароля отсылает вам смс'ку код из который вам нужно ввести в ответ — происходит примерно все то же самое что и было описано выше. Единственным сравнительно малозатратным способом взломать такую систему — является постоянное слежение за радиоканалом по которому производится обмен информацией между ключом и замком с целью составления словаря. Действительно случайные числа на то и случайные, что теоретически они могут повторяться и при определенном везении и навыках можно составить таблицу состоящую из посылок сгенерированных ключом и соответствующих им ответов замка. Через н-ное количество времени может случиться так, что злоумышленнику удастся найти в этой таблице совпадающие пары и польуясь ими все таки взломать такой алгоритм защиты, но опять же проще молоток, ибо никто не будет бегать за вами несколько лет, не спорю идиоты бывают разные но все же проще молотком :)
3. Моя реализация упрощенно работает так (алгоритм AES256, все упомянутые ниже ключи известны и ключу и замку):
а) При нажатии кнопки брелок генерирует случайное число, шифрует его с ключом K1 и посылает его замку.
б) Замок получив запрос от ключа, расшифровывает его, генерирует свое случайное число и зашифровав образовавшуюся пару с ключом K2, отсылает ее ключу.
в) Ключ расшифровывает ответ замка, сравнивает первое число с тем что было сгенерировано на шаге 1, второе число и команда (открыть / закрыть) шифруется ключом K3 и отсылается обратно в замок.
г) Замок расшифровывает ответ ключа, сравнивает первое число с тем, что было сгенерировано им на шаге 2 и в зависимости от команды — производит соответствующее действие.

Таким образом ключ идентифицирует замок, а замок в свою очередь идентифицирует ключ и только в случае если подлинность обеих сторон диалога не вызывает ни у одной из них никаких сомнений — исполняется действие.
Вот ссылка на архив с прошивкой: www.dropbox.com/s/152fr6i…qfbrkgr/key-lock.zip?dl=0
Из кода можно только понять общий принцип функционирования, но то что написано там не сходится с алгоритмом описанным мной в п. 3, поскольку это всего лишь прототип, а не финальная версия. Те кому оно действительно нужно я думаю разберутся.


Комментарии 96
На данный момент, на AliExpress можно купить dev-kit nRF24LE1. Это то же самое, что и L01, но с микроконтроллером 8051 на борту (1k RAM, 16k ROM, вполне себе контроллер, + куча gpio, даже АЦП есть). Говорят, что во сне ток 20мкА. Так же есть продвинутый SDK, компилятор и.т.п.
Вот среда для разработки yadi.sk/d/rrqpmIXf3QT7YJ
Шьётся он перепрограммированным USBasp.
Много инфы о нем тут homes-smart.ru/index.php/…ie-nrf24le1-cherez-usbasp
Могли бы Вы глянуть?
Поднятая Вами тема очень уж полезная сообществу. Тут не только брелок для авто, тут брелки для сигнализаций разного типа, открывалок ворот и т.п. А если ещё и довести до ума, типа: подшивка новых пультов к ардуино, без потребности перекомпиляции прошивки каждый раз для смены паролей, то вообще было бы круто.
Там на сайте есть конструктор прошивок под датчики. Вот такой бы для приемо-передатчика, но с поддержкой динамического кода, было бы круто. Я бы даже по пару баксов за пульт платил бы. Думаю, что другие тоже.
Я как-то эту тему (шифрование связи между nRF) начал активно искать в интернете. Забугорники тоже ищут. А это источник денег. Подумайте над этим.
Кстати, как вариант, машина может постоянно долбить в эфир текущий код, пульт принимает, считает внутри сложную функцию, (тот же интеграл из площади) хеширует, и этот хеш отправляет приёмнику машины, если хеши совпали, — ок, открываем.
Вот тут devzone.nordicsemi.com/qu…-nrf24le1-aes-decryption/ что-то даже про aes. И тут blog.diyembedded.com/2010…rf24le1-sdk-for-sdcc.html тоже.
Может доведете проект до законченного устройства.
В идеале, я вижу несколько брелков, работающих с "мастер" на том же чипе. "Мастер" отдает наружу, по UART, только код нажатой кнопки и прерывание (может пригодится для моментальной реакции). Занимать масенькие мозги ардуины, и мозги чела пишущего скетч тоже, протоколом обмена, смысла не вижу. Ардуина, возможно, только при старте, может задать канал связи и\или, может пассворд загнать в "мастер" + какие-то команды подшивки пульта.
Предусмотреть, возможно, процедуру подшивки пультов. Или сделайте ВЕБ-конструктор, как на том сайте выше, и просто деньги берите за генерацию прошивки "мастер" и брелков под потребности конкретного человека.
Какое расстояние работы между нрф?
Не знаю. Тестирую на расстоянии 3 метра; работает отлично. В инете видел, что при хорошей антенне можно обеспечить рассотяние до нескольких километров. Я планирую засунуть антенну в стойку, так чтобы между машиной и ключом было лишь стекло и накладка стойки. В ключ — тоже антенну, кусок провода или "пружинку".
А вот еще никто не написал, кто что думает по поводу выдуманного мной алгоритма? Почему не нравится?
Если ты программируешь только в ардуино иде, то можешь забыть про свои идеи ^_^ код будет громоздким и неоптимальным. Может случиться так, что только твое хеширование займет много места и на полезные функции уже памяти не хватит. Не забывай еще и про оперативку.
А еще ардуина любит виснуть на сложных алгоритмах и нужен воч-дог ;)))
Изучай Си и пиши напрямую на нем, хотя бы.
Все зависит не от ардуино иде а от рук ;) У меня все ок, памяти хватает код вполне так себе. Вотч дог да нужен тут я согласен, а на сях я и так пишу уже лет 15 ))))
Кстати это не ардуина "любит виснуть на сложных алгоритмах", это надо следить за утечками памяти, и тогда и виснуть ничего не будет.
Если посмотришь библиотеки функций то увидишь, что в них код под все возможные дуины. При компиляции прошивки получается много лишнего. Помимо кода под все контроллеры, там еще и много раз защита от дурака. Вот скорее всего эта защита и усложняет код и приводит местами к зависаниям ;)))
хз будет виснуть, перепишу сразу машинными кодами )
Ну раз затронули хеши :) = сделайте с некторой аналогией с системами авторизации запуска двигателя у некторых автомобильных брендов :) — но упрощенно. В ключе передатчике содержится хеш основа 8мибайтная, и прохешенные поочередно из младшего к старшему ~200т хешей. Каждую посылку высылается хеш на 1 младше. В приемнике делается операция хеширования принятого. Если из полученной посылки путем тогоже хеширования — получается число сохранненное в предидущей сессии — все валидно. Для избегания рассинхронизации — можно хешировать посылку несколько раз в приемнике и сравнивать с сохраненном в предидущей сессии числом — например 128 :) — ну если случайно понажимали кнопку вне пределов работы радиоканала.
Алгоритм для последовательного хеширования любой — хоть MD, хоть тот же AES. Ну и + можно добавить табличное шифрование посылок через XOR. То биш вместе с посылкой передавать номер таблицы для ксора, которая будет соответсвовать длинне посылки. Таким образом в открытом виде будет передаваться только преамбула и номер таблицы.
Не очень понял, а разве это не почти тоже самое, что 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 к примеру. Еще в двусторонней связи меня привлекает то, что позднее можно будет приделать еще какие нибудь плюшки, типа кнопки которая бы опрашивала приемник на предмет закрыты замки или нет или еще чего нибудь. Короче двусторонний канал лучше чем односторонний )
Breakneck
Так написал же — но разжую. 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 из таблицы заранее просчитанных хешей.Указатель на валидный хеш в брелке так же вычитает из значения единицу. В оконечном устройстве сохраняется использованный крайний. После получения пакета по радиоканалу, его расшифровки и проверки контрольной суммы выделяется посланный хеш, делается операция его хеширования (в случае неудачи несколько раз — но число ограничено о чем писал выше) = при совпадении хеша сохранненого в оконечном устройстве, сохраняется уже полученный хеш взамен хранимому и далее — рассматривается код команды. Все.
з.ы. Можете попробовать :) построить цепочку последовательных операций хеширования от одного числа (мы же за хеширование говорим — фунция нереверсивная (пример интеграл от площади некой поверхности например — далеко канеш — но смысл тот-же)
Диалоговые системы это хорошо, но проще и комфортнее писать математику, чем городить дуплексный канал.
Мне реально понравилось это "От подмены кода операции нас защищает таблица ксора посылки и контрольная сумма с алгоритмом на ваш выбор", Вы единственный во всем топике, кто упомянул о подмене кода операции в теле посылки )
Синхронизацию времени можно ввести через туже команду, время ж может быть относительным. В брелке даллас считает, в базовом блоке тоже даллас считает, но есть возможность через команду с брелка синхронизировать время БРЕЛОК->БАЗОВЫЙ БЛОК. Разбег у современных часов очень незначитаельный — да и ввести синхронизацию по например двум нажатым кнопкам :) или еще какому незатейливому алгоритму — не составит большого труда. Ну и в том же алгоритме в текущем относительном времени можно иметь "рабочее окно". Пожалуй закончим :)
Я один, похоже, недочитал до конца…
Слишком много букаф? Скролл задымился?
У Вас в первой части брелок подает питание на МК только во время нажатия кнопки, т.о. нужно держать кнопку нажатой до тех пор пока не произойдет диалоговый процесс?
Нет, там не зря указано на наличие оптопары которая используется ардуиной для того чтобы управлять своим собственным питанием. Нажатие кнопки, старт ардуины а дальше только она решает когда ей вырубиться.
А, понял…
зачем это все? для передачи терабайт шифрованной информации? или это будет массовое производство, что угонщикам станет интересно "взламывать" конкретно данный тип сигнализации?
сколько раз за время пользования автомобилем вы собираетесь открывать дверь? ну предположим 20 раз в день в течение 10 лет ежедневно.
20*365*10=73000 (черт с ними, с високосными ;)
Предположим, что передаваемый код представляет собой посылку из 512 бит. Это 2^512. Заносим в массив ключа и массив замка 73000 чисел длиной 512 бит, случайно выбранных из подмножества 2^512. Отправляем в замок последовательно 3 выбранных определенным (жестко заданным) алгоритмом числа из массива. Замок проверяет — есть ли в его массиве на тех же позициях такие же числа. Если да — открывается. Если нет — ничего не делает.
На остаток жизни хватит. Если кому то придет в голову угнать машину, проще будет ее увезти на эвакуаторе.
Памяти замку и ключу потребуется 73000*64=4672000 байт. Быстродействия — можно вообще тупо дискретными элементами на счетчиках сделать.
В общем, нужно стараться искать решение, соразмерное сложности задачи. ИМХО.
полностью согласен, пусть будет не 73000, а 100000 чисел, скорее девайс поломается, чем будет использованы все числа, тем более в ардуине random прекрасно работает
Где защита от "replay" атаки? Проигрывание ранее записанного кода?
вычеркивать использованные и сохранять вычеркнутые
Как? Не забывайте что это не IBM PC с гигом памяти, а МК где либа для использования хэш таблиц займет уже неплохо откушает, не говоря уже о том чтобы писать алгоритмы на чтение и выборку этих вещей из EEPROM. Плюс немаловажную часть проблемы составит отключение питания (что если питание вырубиться в момент записи в EEPROM?) и т. н. wear leveling (ячейки EEPROM имеют вполне определенное конечное число циклов перезаписи)
ну такое чувство, что Вы старлайну хотите сделать конкуренцию, защита Вашего девайса, в том, что оно уникально, шифрование нужно там, где происходит массовое производство, так как есть одинаковые девайсы
Не не, ни в коем случае не претендую, просто не знаю другого способа хоть как то защитить канал
Alex6280
зачем это все? для передачи терабайт шифрованной информации? или это будет массовое производство, что угонщикам станет интересно "взламывать" конкретно данный тип сигнализации?
сколько раз за время пользования автомобилем вы собираетесь открывать дверь? ну предположим 20 раз в день в течение 10 лет ежедневно.
20*365*10=73000 (черт с ними, с високосными ;)
Предположим, что передаваемый код представляет собой посылку из 512 бит. Это 2^512. Заносим в массив ключа и массив замка 73000 чисел длиной 512 бит, случайно выбранных из подмножества 2^512. Отправляем в замок последовательно 3 выбранных определенным (жестко заданным) алгоритмом числа из массива. Замок проверяет — есть ли в его массиве на тех же позициях такие же числа. Если да — открывается. Если нет — ничего не делает.
На остаток жизни хватит. Если кому то придет в голову угнать машину, проще будет ее увезти на эвакуаторе.
Памяти замку и ключу потребуется 73000*64=4672000 байт. Быстродействия — можно вообще тупо дискретными элементами на счетчиках сделать.
В общем, нужно стараться искать решение, соразмерное сложности задачи. ИМХО.
Злоумышленник перехватывает три числа, и проигрывает их позже.
и? эти числа уже не используются ни ключом ни замком.
я же не даром указал конечное кол-во чисел, а не просто тупо генератор СЧ.
Тогда не понял, а каким образом эти числа будут исключаться из массива "свободных"? Где эта инфа будет храниться, и что еще более интересно как она будет оттуда выбираться? То есть как решить проблему условно говоря поиска нужно инфы в массиве EEPROM?
Я не спорю, что если бы у меня была база данных, то я бы не парился с этим вообще, а тупо выбирал бы это все из массива сгенерированных значений.
например просто отправлять последовательно 3 числа. И стирать их в памяти ключа и в памяти замка. Ни к памяти ключа ни к памяти замка у "злоумышленника" доступа нет. Чисел хватит.
Даже предположим, что злоумышленник заглушил приемник замка, и перехватил данные с ключа, что бы ПОТОМ ими воспользоваться. Пользователь тупо жмет кнопку снова. Замок открылся. Но в замке и в ключе уже НЕТ ни первой, ни второй комбинации, т к. замок стер ВСЕ до 2й комбинации. Злоумышленник ночью подкрадывается к машине… передает перехваченную комбинацию… УПС. Нифига не получилось (( Она УЖЕ не действует.
Способ угнать только один — пользователь нажал кнопку, комбинация перехвачена, замок "оглушен" на это время. Пользователя "блокируют", что бы не нажал еще раз, воспроизводят перехват… Вуаля! получилось. Пользователя топят в нужнике и уезжают на машине.
Ну ок будем стирать, а как искать не стертое? :D Старым добрым проходом пока не наткнемся на что то что отличается от 0?
а почему нет? жалко 73000 циклов? в любом случае, реализация в разы проще любых, даже целочисленных, вычислений.
всему есть цена вопроса. Если это сигналка на бентли — то делать ее на ардуине и так пижонство. Если это чисто академическая задача — то ради бога, можно и поизвращаться от души с изобретением собственного алгоритма.
В любом случае — ЦЗ без обратной связи на ардуино — это игрушка, которая нужна только ее создателю и двум-трем таким же экспериментаторам )
ИМХО
Да жалко )
приблизительно представляете себе количество циклов в контроллере без аппаратного 32х битного умножителя для перемножения 2х 64х битных чисел? ;)
а теперь прикинем, длину программы и кол-во циклов для выборки 3х последовательных не нулевых значений из одномерного массива.
Не, не представляю и не хочу представлять. Алгоритм есть он работает и ладно, а писать ботву с последовательным проходом по памяти мне что то не хочется. Можно конечно было бы написать связные списки с балансировкой но нафига? :)
каждому своё
Alex6280
например просто отправлять последовательно 3 числа. И стирать их в памяти ключа и в памяти замка. Ни к памяти ключа ни к памяти замка у "злоумышленника" доступа нет. Чисел хватит.
Даже предположим, что злоумышленник заглушил приемник замка, и перехватил данные с ключа, что бы ПОТОМ ими воспользоваться. Пользователь тупо жмет кнопку снова. Замок открылся. Но в замке и в ключе уже НЕТ ни первой, ни второй комбинации, т к. замок стер ВСЕ до 2й комбинации. Злоумышленник ночью подкрадывается к машине… передает перехваченную комбинацию… УПС. Нифига не получилось (( Она УЖЕ не действует.
Способ угнать только один — пользователь нажал кнопку, комбинация перехвачена, замок "оглушен" на это время. Пользователя "блокируют", что бы не нажал еще раз, воспроизводят перехват… Вуаля! получилось. Пользователя топят в нужнике и уезжают на машине.
можно в памяти ключа ничего не стирать, а просто использовать схему: ключ отправляет запрос на "ключ-число", замок проверяет какие были использованы, выдает новое, и отправляет его на брелок, брелок проверяет входит ли этот ключ в массив, кроме того этот алгоритм исключает, если сигнал не дошел, а брелок стер у себя "ключ-номер"
это уже обратная связь. Я предложил с односторонней )
ut2k5
можно в памяти ключа ничего не стирать, а просто использовать схему: ключ отправляет запрос на "ключ-число", замок проверяет какие были использованы, выдает новое, и отправляет его на брелок, брелок проверяет входит ли этот ключ в массив, кроме того этот алгоритм исключает, если сигнал не дошел, а брелок стер у себя "ключ-номер"
Опять "проверяет входит ли этот ключ в массив", память это не массив, поэтому проверка эта в данном случае — будет весьма нетривиальной.
angrycoding
Тогда не понял, а каким образом эти числа будут исключаться из массива "свободных"? Где эта инфа будет храниться, и что еще более интересно как она будет оттуда выбираться? То есть как решить проблему условно говоря поиска нужно инфы в массиве EEPROM?
Я не спорю, что если бы у меня была база данных, то я бы не парился с этим вообще, а тупо выбирал бы это все из массива сгенерированных значений.
А если за основу взять микросхему времени? и переводить время в какую то последовательность чисел (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 Нет уходим в сон.
Alex6280
зачем это все? для передачи терабайт шифрованной информации? или это будет массовое производство, что угонщикам станет интересно "взламывать" конкретно данный тип сигнализации?
сколько раз за время пользования автомобилем вы собираетесь открывать дверь? ну предположим 20 раз в день в течение 10 лет ежедневно.
20*365*10=73000 (черт с ними, с високосными ;)
Предположим, что передаваемый код представляет собой посылку из 512 бит. Это 2^512. Заносим в массив ключа и массив замка 73000 чисел длиной 512 бит, случайно выбранных из подмножества 2^512. Отправляем в замок последовательно 3 выбранных определенным (жестко заданным) алгоритмом числа из массива. Замок проверяет — есть ли в его массиве на тех же позициях такие же числа. Если да — открывается. Если нет — ничего не делает.
На остаток жизни хватит. Если кому то придет в голову угнать машину, проще будет ее увезти на эвакуаторе.
Памяти замку и ключу потребуется 73000*64=4672000 байт. Быстродействия — можно вообще тупо дискретными элементами на счетчиках сделать.
В общем, нужно стараться искать решение, соразмерное сложности задачи. ИМХО.
Еще по поводу терабайт, размер пакета в NRF модуле ограничен 32 байтами если я не ошибаюсь, поэтому там далеко не терабайты )
ну flash накопители никто не отменял, а в eeprom можно сохранять не сами числа, а их индексы в массиве, меньше занимть будут, хотя на сколько помню, ограничение eeproma не в размере, а в количестве перезаписи
Как их искать? EEPROM / FLASH это не хэш таблица а блоб, для того чтобы прочитать нужен адрес, а в случае предложенной вами реализации алгоритм по работе со всем этим добром выйдет похлеще чем использование AES256.
хорошо, пусть не рандом, пусть по порядку использует, а в eeprom записывает последний использованный ключ
Что если при записи возникнет сбой? Что если посылка от брелока не дойдет до базы? Что будет если ячейка куда вы пишете последний код — выдаст отказ?
а что если тупо аккум сел? и с каких это пор в eeprom не надежно записывались данные?
А что будет если он сядет в заводском варианте?
опять же заводское решение — массовое производство, поэтому там другие решения
Ну какие другие решения? Ну что там аккумулятор от танка прячется в стойке с левой стороны? Спецово чтобы запитать ЦЗ в случае отказа основного аккумулятора?
ut2k5
хорошо, пусть не рандом, пусть по порядку использует, а в eeprom записывает последний использованный ключ
Я все это проходил и думал над этим не раз, поверьте мне. Если вы можете накидать алгоритм хотя бы в формате блок схемы, то я буду только рад выкинуть все это шифрование и заменить его на блокнот с паролями.
ну я пытался упростить Вам жизнь, решение в любом случае за Вами, это же Ваш проект, а следить я в любом случае буду, проект интересный
Да я понимаю, просто яж сразу сказал что не выйдет ничего с этим. Другой интересный вариант можно было бы рассмотреть — это генерация паролей на основе времени. Но для этого нужно чтобы у каждого блока был RTC, да еще и расходиться это будет нехило. Как бы вариантов масса, но во всех из них нужно чтобы обе стороны были каким то образом синхронизированы.
angrycoding
Я все это проходил и думал над этим не раз, поверьте мне. Если вы можете накидать алгоритм хотя бы в формате блок схемы, то я буду только рад выкинуть все это шифрование и заменить его на блокнот с паролями.
я бы например, если бы делал, то на gsm модуле, с функцией автозапуска, думаю летом к этому вопросу приду, может Вы и правы, единственное, алгоритмы шифрования в инете пруд пруди, я бы не изобретал велосипед
Думал над этим, но GSM может перестать работать на подземной парковке. Как быть с этим? Стоп а я и не писал своих алгоритмов шифрования, я же вроде бы упомянул что используется AES256?
всегда есть штатная сигналка, и в таких случая, используем ее, а что если рядом с вашей парковкой стоит не хилая глушилка всех сетей. тогда и Ваш девайс заглючит? универсальный механизм — это зло, а еще лучшее — враг хорошего))))
У меня нет дистанционного замка. Я почему и начал все это делать. Просто ЦЗ есть, а брелока и юнита в машине который мог бы с ним работать — нет.
не, ну тго, тупа с ключа открывается, но в такие моменты, цз проверяет, что нет сети, и не противится)))
Ну короче как есть так есть, GSM не хочу, вайфай тоже не хочу, хочу просто и безопасно, по мне так описанное попадает под эти критерии. Если у вас есть идеи как улучшить то выслушаю с удовольствием!
я Вас понял, тем более, Вы говорите, что уже много об этом думали, в любом случае будем следить за проектом, очень хочется, чтобы он был окончательным, удачи Вам
А Bluetooth? :) и телефон
Bluetooth тоже думал, но меня будет ломать доставать каждый раз телефон и включать bluetooth. Это уже на любителя.
JimTonik
А Bluetooth? :) и телефон
у него дальность не большая
angrycoding
Ну короче как есть так есть, GSM не хочу, вайфай тоже не хочу, хочу просто и безопасно, по мне так описанное попадает под эти критерии. Если у вас есть идеи как улучшить то выслушаю с удовольствием!
Можно еще за стекло спрятать www.ironlogic.ru/il.nsf/htm/ru_MatrixIIK и открывать картой :)
Не, самое крутое я когда курил все эти темы, наткнулся на научную работу какого то профессора на тему исследования уязвимостей в сигналках. Там рассматривались мерсы, так вот судя по тому что там написано (не знаю что там на самом деле), у них вообще двери открываются тогда когда в зону действия блока установленного в авто — попадает приемник лежащий в кармане владельца. То есть инициатором диалога — является не ключ — а замок. И в частности мне очень понравилось одно описание взлома: смысл вот в чем чел гуляет по магазину а машина находится на подземной парковке к примеру. Два чувака, один возле машины, другой пасет владельца, между ними канал (через телефон, через инет, не важно короче как). Тот что возле тачки — принимает сигнал замка (а он в этом случае постоянно ищет ключ) и транслирует его через канал — второму челу, тот его принимает, и в свою очередь транслирует его ключу, ключ отвечает, второй принимает ответ — пересылает первому, тот принимает — и закидывает это в замок. В итоге пока чел покупал себе тапки, машина уехала )
Перепутал чуть чуть, там сигнал шлет машина как только кто нибудь дергает ручку. Короче один чел дергает ручку и принимает сигнал от машины, ну а дальше я уже написал )
Круто :) На каждого умного найдется другой умный. Также можно поступить и с двухсторонней сигнализацией… только как-то заставить владельца нажать кнопку :)
Дать ему по голове и попросить вежливо нажать на кнопку )
Меня это вообще поразило, поскольку защиты от этого не может быть вообще никакой.
От удара по голове ? Мередесовский брелок можно спрятать в экранирующий футляр. А так пауки и эвакуаторы решают все проблемы угонщиков :))))
Ну если его спрятать в футляр то теряется весь шарм использования такой люксовой системой. Этож надо его доставать )
angrycoding
Дать ему по голове и попросить вежливо нажать на кнопку )
Меня это вообще поразило, поскольку защиты от этого не может быть вообще никакой.
может, каска строительная)))
Alex6280
зачем это все? для передачи терабайт шифрованной информации? или это будет массовое производство, что угонщикам станет интересно "взламывать" конкретно данный тип сигнализации?
сколько раз за время пользования автомобилем вы собираетесь открывать дверь? ну предположим 20 раз в день в течение 10 лет ежедневно.
20*365*10=73000 (черт с ними, с високосными ;)
Предположим, что передаваемый код представляет собой посылку из 512 бит. Это 2^512. Заносим в массив ключа и массив замка 73000 чисел длиной 512 бит, случайно выбранных из подмножества 2^512. Отправляем в замок последовательно 3 выбранных определенным (жестко заданным) алгоритмом числа из массива. Замок проверяет — есть ли в его массиве на тех же позициях такие же числа. Если да — открывается. Если нет — ничего не делает.
На остаток жизни хватит. Если кому то придет в голову угнать машину, проще будет ее увезти на эвакуаторе.
Памяти замку и ключу потребуется 73000*64=4672000 байт. Быстродействия — можно вообще тупо дискретными элементами на счетчиках сделать.
В общем, нужно стараться искать решение, соразмерное сложности задачи. ИМХО.
Можно еще выдумать "эзотерический" канал обмена инфой — посредством звука. Брелок должен подавать сигналы инфразвуком (как свистки собачьи) а приемник соответсвенно "слушать" эфир и пытаться что то из этого выловить. Плюсы: если потерял брелок можно попытаться открыть двери свистком и еще можно использовать брелок для отпугивания собак кротов бобров и прочей живности которая не равнодушна к инфразвуку.
может просто под кожу вшить RFID метку?
Я рассматривал этот вариант, но неудобно будет с пакетами открывать двери.
неудобно писать против ветра ;)
как вариант, RFID метку можно встроить в кольцо на палец, антенну в ручку двери, туда же — концевик. Дернул за ручку — активация метки, ответ, привет, открылась — нет. Радиус действия метки при этом 20-30 мм. Для того, чтобы злоумышленник смог считать метку, ему надо будет сначала считать пакет запроса от антенны (а она может и в несколько этапов спрашивать, так что тут еще повозиться придется врагам), а потом еще подобраться со сканером вплотную к руке пользователя. Т.к. облучить то они смогут и на расстоянии, а вот считать — нет, т.к. передатчик метки бьет всего на 30 мм.
В общем — было бы желание, а проблема найдется.
А что мешает злоумышленнику поймать первую и вторую посылку ключа для системы с диалоговым кодом и послать в нужном направлении повторно?
Число сгенерированное замком в пункте б, не совпадет с тем что будет им принято в пункте г.
советую почитать для начала ru.wikipedia.org/wiki/%D0…B%D1%8E%D1%87%D0%BE%D0%BC а после изобретать велосипед =)
Когда изобретали велосипед википедию не читали)))
vInteLL
советую почитать для начала ru.wikipedia.org/wiki/%D0…B%D1%8E%D1%87%D0%BE%D0%BC а после изобретать велосипед =)
Спасибо, но я не изобретаю велосипед и не вчера этим заниматься начал ;)
только вот ассиметричного шифрования ардуина не потянет.
так а зачем это ? есть же модули с брелками.
Можно поподробней, какие модули с брелками?
да конечно. я про такие —
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 (если он вообще там есть), я описал как он ломается. Подходит для управления розеткой, но не для данного случая ИМХО