Шифрование Данных

[DJ Димон]

Привет всем!

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

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

шифрование и дешифрование будет производится при наличии обоих ключей.

Думал использовать RSA, но по коду там два ключа генерируются одновременно, и оба всегда разные, а мне необходимо чтоб один из ключей был const

Немного изменю вопрос, для знающий алгоритма шифрования rsa: 

какой максимальной длинны public key и private key сможет создать 8 битный мк?

и можно ли расчитать время генерации ключей, кодирования и декодирования данных этим мк (допустим с тактовой  частотой 10мГц)? 

Изменено 4 декабря, 2010 пользователем DJ Димон

[Реклама]

Реклама: ООО ТД Промэлектроника, ИНН: 6659197470, Тел: 8 (800) 1000-321

[noise1]

Законодательство почитайте. Дальше 400 метров нельзя. Или используйте сертифицированную систему.

[Реклама]

20% скидка на весь каталог электронных компонентов в ТМ Электроникс!

Акция "Лето ближе - цены ниже", успей сделать выгодные покупки!

Плюс весь апрель действует скидка 10% по промокоду APREL24 + 15% кэшбэк и бесплатная доставка!

Перейти на страницу акции

Реклама: ООО ТМ ЭЛЕКТРОНИКС, ИНН: 7806548420, info@tmelectronics.ru, +7(812)4094849

[DJ Димон]

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

в третьих дальность связи до 100 метров

[Реклама]

Выбираем схему BMS для корректной работы литий-железофосфатных (LiFePO4) аккумуляторов

 Обязательным условием долгой и стабильной работы Li-FePO4-аккумуляторов, в том числе и производства EVE Energy, является применение специализированных BMS-микросхем. Литий-железофосфатные АКБ отличаются такими характеристиками, как высокая многократность циклов заряда-разряда, безопасность, возможность быстрой зарядки, устойчивость к буферному режиму работы и приемлемая стоимость. Но для этих АКБ, также как и для других, очень важен контроль процесса заряда и разряда, а специализированных микросхем для этого вида аккумуляторов не так много. Инженеры КОМПЭЛ подготовили список имеющихся микросхем и возможных решений от разных производителей. Подробнее>>

Реклама: АО КОМПЭЛ, ИНН: 7713005406, ОГРН: 1027700032161

[noise1]

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

[DJ Димон]

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

[приус]

Поставьте Т-230 и будет Вам счастье.

[rtfcnf]

какой максимальной длинны public key и private key сможет создать 8 битный мк?

Если рассматривать компилятор языка "СИ" и допустить, что использовать будем только встроенные типы данных, то ответ на Ваш вопрос лежит в файле "limits.h" или "сlimits.h" (в разных компиляторах могут немного отличаться названия файлов) в этих файлах указаны ограничения во встроенных типах данных. Если же Вы будете писать свою библиотеку представления чисел, то длинна может быть любой, весь вопрос сколько времени займет обсчет всего этого безобразия

ИМХО: Не нужная трата времени, создания такого канала связи, для устройства на восьми битном МК. На худой конец возьмите алгоритм "кайлога" и шифруйте с помощью его.

[o_l_e_g]

Что мешает, представлять ключ в виде массива, например по-байтно?

С ним потом и работать удобнее будет...

[rtfcnf]

Мешает конкретно для RSA, время которое контролер потратит на умножение и возведения в степень такого массива.

[o_l_e_g]

время которое контролер потратит на умножение и возведения в степень такого массива.

Не думаю что сильно повлияет, АЛУ МК у нас, по ТЗ, все-равно 8-битное...

[rtfcnf]

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

>>Не думаю что сильно повлияет, АЛУ МК у нас, по ТЗ, все-равно 8-битное

Восьми битный RSA сломают и очень быстро. Я имел в виду когда писал про своё представление чисел, что мы сами сформируем например 128 битное целое, например как Вы предложили массивом. Вот с ним и придется нам работать, не думаю, что это не напряжет МК.

Изменено 8 декабря, 2010 пользователем rtfcnf

[o_l_e_g]

Я имел в виду когда писал про своё представление чисел, что мы сами сформируем например 128 битное целое, например как Вы предложили массивом. Вот с ним и придется нам работать, не думаю, что это не напряжет МК.

А разница то какая? Это на языке высокого уровня, будет красиво и удобно, только и всего. На нижнем уровне, это 128 битное, будет выглядеть как 16 восьмибитных ячеек памяти, тот же массив...который, кстати, также последовательно будет прогоняться через АЛУ при действиях над ним.

[rtfcnf]

>>А разница то какая?

При использовании "ПИКА" с аппаратном "Кайлогом" у нас будет:

1. Проще код.

2. Практически RealTime в передаче и приеме данных.

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

Хотя не зная целиком задачу, трудно что либо дальше говорить.

[o_l_e_g]

rtfcnf, наличие аппаратного шифратора, в корне меняет дело,но речь то шла, о реализации криптоалгоритма собственными средствами МК.

[rtfcnf]

Олег, если четко отвечать на поставленный вопрос в первом посте, то я это сделал в своем первом ответе. Повторюсь, нет не стоит RSA использовать на восьми битниках. Извиняюсь, если несколько сумбурно тогда ответил. И предложил свой вариант, использовать "Кайлог".

[DJ Димон]

от RSA мк повесится вычислять, на него покроме шифрования ещё много чего висит, аппаратный девайс не вариант, железо уже готовое..  rtfcnf, Можно по подробнее про  >>"Кайлог" ? что это где почитать? яндекс мне один вариант предложил с видеоклипом))

необходимо такой алгоритм, чтоб нельзя было один и тот же пакет данный (даже с одинаковыми не кодированными данными)  использовать дважды, ну или как то примерно так. У меня ещё такая мысль, взять к примеру RC4 в обоих устройствах есть ключ, к примеру байт на 56, исполнитель генерирует 8 псевдослучайных байт и отправляет хосту, тот с помошью  56+8(которые сгенерировал исполнитель)  шифрует данные и отправляет обратно. но как то мне кажется не удачная идея...

Изменено 9 декабря, 2010 пользователем DJ Димон

[rtfcnf]

"Кайлог" по английски пишется так: Keeloq

По сути KeeLoq является алгоритмом создания псевдослучайной последовательности на основе начального значения, другими словами если мы в приемник и передатчик в ведем одно и тоже начальное значение, то используя этот алгоритм получим на обоих устройствах одинаковые псевдослучайные последовательности. Вот их я и предлагаю использовать в виде сеансовых ключей. Так как у Вас радио канал двух направленный мы в реализации сможем избежать моментов уменьшающих криптоустойчивость системы на которую идут создатели авто-сигнализаций. Реализовать программно Keelog не сложно, но у Микрочипа есть контроллеры в которых они генерируется аппаратно. Что выбрать решать Вам.

Теперь как я представляю Вашу систему:

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

И так продолжаем:

Сеанс связи начинается и заканчивается командами "start" и "stop", их тоже лучше формировать динамически, при нормальном окончании сеанса связи, устройства генерируют новые ключи и так далее.

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

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

Изменено 9 декабря, 2010 пользователем rtfcnf

[DJ Димон]

Я вижу тут такое решение, исполнитель должен сам генерировать какую то часть ключа и передавать её хосту для шифрования пакета (в этом случае только исполнитель будет иметь возможность задавать переменную, от которой зависит вид пакета) в таком случае взломать такой алгоритм можно перехватом и накоплением пакетов за длительный период, к примеру если эта часть ключа будет иметь длинну 2 байта, то через 6656 комбинаций ключи будут повторятся и можно найти под него уже когдато использованный пакет. Эти проблемы решить увеличением этого ключа а также сделать таймаут устройства, между ответами установить к примеру 3 сек, тогда атака перебором займёт очень много времени.

А так как хост будет иногда связан с ПК, можно к примеру через n дней менять основной ключ.

тогда такой вопрос, какой должен быть алгоритм, который бы подходил под эти требования, а именно, имел 2 ключа A(ключ который будет генерировать исполнитель) и B(постоянный ключ прошит в обоих устройствах), причём зная A и зашифрованный пакет, нельзя было вычислить B.

Я не знаю выполнится ли это условие если использовать ключ key шифрования RC4(это примерно то же про что вы и говорили "Кодировать данные можно простой операцией XOR..."), если key = A+B (56байт постоянного ключа + 8 переменный), мне кажется зная B и имея шифр можно будет вычислить весь ключ.

+в том что генерировать будет только 1 устройство, чем мы решаем вопрос рассинхронизации, и невозможность подменить это число левым устройством.

Пока у меня такой вариант в голове висит.

[rtfcnf]

Я не знаю выполнится ли это условие если использовать ключ key шифрования RC4(это примерно то же про что вы и говорили "Кодировать данные можно простой операцией XOR..."), если key = A+B (56байт постоянного ключа + 8 переменный), мне кажется зная B и имея шифр можно будет вычислить весь ключ.

В том то и дело, что используя Keeloq мы имеем возможность при каждой сессии менять ВЕСЬ ключ. Не зная начального значения, вычислить его практически не возможно, в сети встречал две работы по поводу взлома на основе накопления данных, посмотрите их, но там достаточно большое число передач берется, и к томуже они основаны, на том, что передается чисто код Keeloq(ка), у нас же по сути "хеш", минус конечно в том, что сообщения скорей всего у Вас типовые, но можно-же добавить например номер сообщения придав уникальность сообщению.

Основная проблема при использовании Keeloq(ка) как синхронизировать последовательности в условиях не гарантированного канала передачи. Вчерашнее моё предложение по передачи дополнительного значения к начальному состоянию "кайлога" уже не выглядеть совсем бредовой, при условии, что мы передаем не само значение, а аргумент к какой нибудь не линейной функции.

ИМХО:

Если делаете что-то, что подлежит сертификации, то есть смысл пригласить человека который разберется в теме, если чисто для себя, то Вы уверены, что Вас кто то будет ломать?

Изменено 10 декабря, 2010 пользователем rtfcnf

[DJ Димон]

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

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

Изменено 10 декабря, 2010 пользователем DJ Димон

[evgesha53]

оффтоп извиняюсь.

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

И много полезного,для себя под черпнёте.

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

Вот это очень интересно,я думал,что именно он сломан.Интересно,как-же тогда у меня вскрыли машину,забрали сумку,закрыли и свалили? .Правда в сумке,кроме обеда ничего особого не было .Когда что-то лежит,я сумку из рук не выпускаю. .Сейчас просто дебилы накупили аппаратуры и сами себя палют.Профессионалы,потом угреются лет на 5 за тарелочку с котлетами.

[DJ Димон]

смотря какую машину   есть много способов вскрыть некоторые "образцы" не трогая сигналку

[evgesha53]

есть много способов вскрыть некоторые "образцы" не трогая сигналку

Конкретно,о сигналках с кейлогом.Я например ни одного такого способа не знаю.Если сигнализация работает,то вскрыть-то её можно.Я и сам многие авто могу открыть,по специфике работы своей.Но надо как-то блокировать сигналку.Я не говорю о простых приборах,где достаточно радио-звонок перепаять.У меня только одна мысль,заставить как-то заглючить сигналку,а больше ни каких мыслей нет.

[DJ Димон]

ну если это чтото вазовское, то в 80% случаях концевик на какой-нибудь двери не работает, открывай не хочу, и тырь котлеты

а на волге вообще на 2х дверях концевики не предусмотрены заводом изготовителем, главно нет на передней правой и на задней левой

очень часто замечал что сигналка установлена, а концевики эти нет , ну и ещё есть некоторые моменты.... сам года 2 сигналки ставил

Изменено 17 декабря, 2010 пользователем DJ Димон

[evgesha53]

Да я не про наши тазики и не примитив.Это-то понятно всё.У меня из dodge стащили,сигналка вроде Alligator s350.С концевиками и остальным всё там хорошо.Машину,открыли и закрыли.Вот,что интересно.Прибор-то

совершенствованный динамический код Keeloq ™ с защитой от сканирования и перехвата