Реверс-инжиниринг модифицрованной CRC

Здравствуйте.

Есть некая величина А (слово) также есть константа X и некая переменная D - зеркальное отражение результата этой же функции от предыдущей величины А.
Эти величины (6 байт) проходят функцию CRC-CCITT (0x1021, init=0x0000, finalxor=0x0000, refin-refout=false) и дают двухбайтное значение.
Третья сторона может получить контролируемую величину А и CRC-значение, которое с этой величиной завязано.

Можно ли считать такой алгоритм достаточно защищенным от подмены величины А и пересчета корректного CRC, такого, которое, посчитавшись по тому же самому алгоритму, подтвердилось бы на принимающей стороне?

Это вкратце. Есть небольшая иллюстрация (в приложении), там нарисовано все, что происходит.

Подсчет шагов для брутфорса (если он верен) дает дикие цифры.

Также читал про RevEng. Насколько я понял, таким способом можно узнать только полином, по которому считается CRC. И то полином-то как раз можно узнать, если известны все байты, от которых берется CRC (6 байт). А алгоритм компиляции сообщения третья сторона не знает. К тому же RevEng, если я правильно понял вообще поддерживает поиск полинома только по двухбайтному сообщению.

Буду признателен за любую помощь.

Миниатюры

 

0

Сообщение от idementia считать ... защищенным

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

Reverse-Engineering a CRC Algorithm
Calculating Reverse CRC
CRC and how to Reverse it

0

Все варианты по ссылкам предлагают замену сообщения, когда оно известно.

В сабже, у злоумышленника нет сообщения. У него есть только два байта, которые находятся в 6-байтном сообщении (и то разбросаны), способ образования которого ему неизвестен.

0

CRC линейна по XOR. Так что, забудьте про стойкость. Алго в криптоанализе считается известным по определению.

0

Алго в криптоанализе считается известным по определению.

В двух словах-то можете расписать? Почему алгоритм составления сообщения известен? Мне интересна конкретика хотя бы в общем виде.
Так-то и хеш-функции ломаются, уже не ново.
А то выглядит как " я дартаньян ... " и т.п.

0

Сообщение от idementia Почему алгоритм составления сообщения известен?

Принцип Керкгоффса

0

Я понял идею. В моем случае сохранение секректности алгоритма, я считаю, можно признать неактуальным.
На контроллере после составления проекта весь код преобразуется в машинный и зашивается в нем самом. Для злоумышленника нет возможности дистанционно его вытащить.
Имхо, это уже оговорки идейного характера.
Мне интересны аспекты технических уязвимостей. При условии, что "внутри" обменивающихся сторон алгоритм защищен от несанкционированного доступа.

0

Сообщение от idementia алгоритм защищен от несанкционированного доступа

Так не бывает :-)

К примеру: Как я процессор PSX разбирал

0

Ну я знаю, что ломается все, что угодно, при желании, конечно. В сфере ИБ это всегда первый ответ на вопросы "дает ли ваша система 100%-ную защиту?".
Но и я не пентагон защищаю. Это работа в рамках диплома и на данном этапе мне интересно увидеть, какие бреши в технической реализации, чтобы это обдумать и учесть, если что.

PS кстати да и для реальных контроллеров механизм, я считаю, неплох. Он не требует большого количества ресурсов и, в отсутствие механизмов контроля целостности и подлинности (а они, собственно, средствами ПЛК и не реализованы), обеспечит примитивную, но защиту. От кул хацкеров АСУ ТП защитит

0

Сообщение от idementia бреши в технической реализации

CRC16 имеет весьма ограниченное число значений (2^16). Оставляя в стороне взлом железа (декапитация чипов - это отдельная индустрия. Что невскрываемо здесь, вскроют в Китае, вопрос только денег и интереса), пространство ключей так мало (64K), что при достаточном числе перехваченных сообщений может быть просто составлена таблица "вопрос - ответ" (как это делалось в эмуляторах dongles) - без даже попытки реверса алгоритма.

1

Из-за такого варианта и вводится переменная. Благодаря переменной, завязанной на предыдущем значении, два одинаковых значения крайне маловероятно дадут одинаковый CRC.
Естественно, до тех пор, пока злоумышленник не поймет завязку.

0

Сообщение от gazlan Так что, забудьте про стойкость. Алго в криптоанализе считается известным по определению.

Мною дважды была решена задача с неизвестным криптоалго.
Один раз это было неизвестное отбеливание на входе и выходе расширенного DES с итоговым ключом шифрования в 128 бит. 64 бита (не 56 !) ключа для расширенного DES в ядре алго и еще 64 бита для отбеливания входа и выхода. Примененного в реально работающей криптосистеме. Я даже по этому поводу необходимый критерий невзламываемости неизвестного отбеливания входа и выхода у известного криптоалгоритма вывел. Кстати, эту-же задачу еще один человек сумел решить, хотя и не дошлифовав результат до исчерпывающего.
Второй раз - это алгоритм шифрования памяти на лету у секурного микроконтроллера. Он оказался сетью Фейстеля в 4 звена со своими S-Box-ами, все дела. Всего 4 звена, потому-что на большее не хватало времени, ведь это все надо было делать на лету.
Т.е. мной дважды была решена задача нахождения практически примененного неизвестного криптоалгоритма при наличии триад : открытый текст, ключ, шифрованный текст. Триад при этом потребовалось порядка тысячи в каждом случае. Но сии результаты оказались не диссертабельными, поскольку не представляли собой никакого метода, а лишь рукопашную работу. В лучшем случае подход к рукопашной работе. Но зато я прусь от того, что типа открыл некий перпендикулярный криптоанализ. Правда об этом почти никто не знает. Ну и он никому не нужен.

1

Сообщение от Ethereal Правда об этом почти никто не знает. Ну и он никому не нужен

0