Всем здоровья! Возможно кто то занимался данной задачей. Есть брелок выполненный на Atmega328 и JDY40. По воздуху летят данные на такой же JDY40 по определённому протоколу, который подключен к Atmega328. Вообщем сделан воздушный мост. Через некоторое время использования, пришло понимание, что протокол и данные надо шифровать. Шифрование сделал, но вот проблема решена не полностью. Сделав сниффер на таком же железе, можно легко перехватывать данные и даже не важно шифрование тут же начать управлять. Почитал про сигналки на авто, плавающие ключи, но всё это ломается вообще без проблем. У меня трудность ещё в том, что брелок с односторонней связью, данные он не принимает, а только передаёт. Вот и задумался как сделать, чтобы и шифрование было, и чтобы не смог злоумышленник управлять обьектом. Какой алгоритм выбрать. Прошу на пальцах описать, если можно. Спасибо.
Надо делать двухстороннюю связь.
Ну, я так понимаю, речь о шифровании не от спецслужб, от от подростка, который купил на али (или собрал на ардуине) ах… какой крутой сниффер, так ведь?
Тогда простых способов навалом. Например:
Если в девайсах есть RTC, ключом выступает текущая минута. Приёмник, если не совпала контрольная сумма, пробует соседние минуты (чтобы отработать рассинхронизацию часов). Получается, что ключ меняется каждую минуту;
в сообщении “сумма первого и последнего байтов (слов) чему-нибудь фиксированному равна” (или более секюрно, чему-нибудь из 2-5 фиксированных значений). Два таких сообщения с одинаковыми числами в течение часа (дня, недели) не прокатывают, второе - бракуется. Т.е. суммы одинаковые, а числа должны быть разными. Эти два числа образуют ключ. Между ними собственно полезное сообщение, которое простым XOR’ом (или чем похитрее) закодировано этим ключом. Получается, что все сообщения, даже “по-сути-одинаковые” передаются как разные, сниферить никакого смысла нет. Тут можно много фантазировать, но главное - в составном ключе, который не повторяется (повторяется но не слишком часто).
К сожалению, RTC в брелке нет, да он в сон уходит, как только передача состоялась.
А вот второй вариант интересен. Попробую реализовать. Спасибо.
Я попробую объяснить без математики, только на здравом смысле.
- Для простоты представим, что команда у нас одна - “открыть дверь”.
- таким образом задача не шифровать команду, а идентифицировать “ключ” - в нашем случае брелок.
- при этом требуется, чтобы брелок мог открыть дверь без плясок с бубном.
- И одновременно требуется, чтобы злоумышленник не подделал сообщение. Ну не то чтобы никогда, но чтобы ему было не просто!
Кажется, что 3 и 4 противоречат друг другу? Есть такое дело, но можно обойти.
Требуется, чтобы брелок не повторялся. И чтобы замок (в меру своей сложности) помнил сообщения, которые уже получил.
Но важно, что пользователь может случайно в кармане нажать сотню раз и поэтому рассчитывать РОВНО на следующий номер замок не имеет права. При достаточно длинном цикле повтора можно запретить 10-100-1000 предыдущих номеров.
Один из простых способов описал ЕвгенийП выше. Один байт - слабая защита, но “от пионЭров” сойдет.
В целом циклический ключ это неочевидная и достаточно длинная последовательность чисел. Неочевидная для того, чтобы злодей, приняв несколько ключей подряд, не смог догадаться о формуле последовательности. Длинная, для того. чтобы злодей не мог запомнить старый ключ и им воспользоваться через несколько дней, когда перебор пойдет на второй круг.
Замок при этом может помнить лишь последний номер ключа, ассоциированного с данным брелоком. Брелок передает свой номер, текущий ключ и может это всё завернуть во что-то простое, чтобы злодеям мир мёдом не казался.
Как это работает?
- Когда замок знакомят с брелоком, то замок создает место для хранения последнего ключа от брелока с данным номером.
- Брелок при каждом нажатии передает свой номер и следующий ключ из последовтельности.
- замок, приняв сообщение, проверяет, чтобы номер принятого ключа был не меньше, чем прошлый минус “защита” - к примеру минус тысяча или 10000. Если ОК, то дверь открывается и замок запоминает номер принятого ключа для данного брелока.
Последовательности - тут полный интернет высокоэнтропийных генераторов. В простейшем случае можно умножать на одно большое простое число и брать по модулю другого большого простого числа. Это низкоэнтропийная формула, но от “пионЭров” годится. Разумно иметь длину ключа хотя бы в 64 бита… а то как-то не солидно!
Понятно. У меня ключ 128 бит Шифрование AES-128 Данных 16 байт, из которых последние 5 байт свободных. А вот на счет случайных нажатий спасибо. Не подумал об этом.
Это не про то. Тут про другой ключ.
Чтобы не повторялся, может использовать бегущее значение милис в брелке? Не знаю пока, во сне милис может тоже останавливается и при выходе из сна с нуля начинает старт? Замок может сохранять в своём EEprom последний принятый ключ
Сорри, коллега, могу только повторить то. что уже написал:
циклический ключ это неочевидная и достаточно длинная последовательность чисел. Неочевидная для того, чтобы злодей, приняв несколько ключей подряд, не смог догадаться о формуле последовательности. Длинная, для того. чтобы злодей не мог запомнить старый ключ и им воспользоваться через несколько дней, когда перебор пойдет на второй круг.
Для защиты при односторонней передаче требуется не шифр, а подпись. Электронная подпись.
Вот я и написал, как её сделать. - Выше написано. При каждом нажатии генеришь следующую, чтобы сниффер не помог злодею повторное использование возможно через длительное время. Я написал выше - как именно это делать.
ОК, если ты уже шифруешь сообщение, то делай так:
- к сообщению дописывай его номер, например в четырех байтах. (или в двух)
- потом всё это шифруй. можно CRC прибавить - хуже не станет, а только солидности прибавит
- на замке расшифровывай и проверяй текущий номер. Если он больше последнего (но не более, чем на ХХХ) - ОК, если меньше - не ОК.
- если ОК - запомни номер, как последний.
- ХХХ - это количество случайных нажатий в кармане, которое ты допускаешь в своей системе. Должно быть меньше. чем половина максимального номера.
Сорян на запятые, у меня правый шифт дурит и не всегда срабатывает на клаве на кухне…
ЗЫ: разумеется - брелок должен помнить свой последний номер в ЕЕПРОМе!!!
тогда повторное значение (в зависимости от дальнейшего алгоритма) можно будет использовать от 49 до 49*x дней, у меня более 4000 )))
Возьми esp32 и настрой профессиональный сильный шифр. Шифрование на атмеге - пик идиотизма.
Щас советы дойдут до какой-нибудь ATSHA204A, чтобы соседский пацан точно ничего не схулюганил. Вон у неё скока фич! 
Что же ты так категорично то 
. Вполне меня устраивает Enc/Dec AES-128 160 ms . На ESP32 тот же самый скетч показал скорость 0.5 ms
Заказал десяток на попробовать. Некоторые поекты, которые обновляются с сайта производителя простой заливкой, можно лочить на уровне железа, чтобы не было копирвания самого железа. Тема как то была на нашем форуме давно, товарищь заморачивался с этой микросхемой, правда не знаю чем дело заканчилось. А для меня даже хранение ключей в ней для шифрования AES-128, тоже тема. Спасибо.
О как! Я то пошутил, а оно вона - пригодилось! Ну, я рад!
Брелок адин?
Брелок может передавать несколько команд и/или он только свой идентификатор отсылает?
Только свой идентификатор. Брелков много
упрощения шифрации тут можно добиться увеличением избыточности сообщения,
собстно все ранее предложенные варианты уже подразумевают избыточность, и
чем она будет выше, тем “проще”, в смысле затрат проца, может быть алгоритм.
Вот от этого можно отталкиваться:
microRSA
Arduino-SHA-256
microrsa имеет только функции encrypt/decrypt. sign/verify придётся дописывать
истинный ГСЧ можно сделать из стабилитрона или (после некоторой цереброкоитальной активности) светодиода (он умеет быть таким себе стабилитроном)
Широкополосный генератор шума: от десятков Гц до десятков МГц