Форум по автобезопасности -
автосигнализации

Уважаемые инженеры AlarmTrade.
Я надеюсь, Вы не используете микросхемы Microchip с блочным шифром Keeloq или любой его модификацией, поскольку этот шифр является абсолютно не стойким (как это было показано на Crypto 2007) и вскрывается с помощью Slide и Meet-in-the-Middle или Slide Cycle атак за 2^35 операций. Методики взлома подробно описаны в следующих документах.
http://www.computerra.ru/think/kiwi/331383/
http://eprint.iacr.org/2007/062.pdf
http://eprint.iacr.org/2007/055.pdf
http://www.schneier.com/blog/archive...oq_broken.html
Что при сегодняшнем уровне бот сетей (компьютеров пораженных вирусом и позволяющим использовать свои вычислительные мощности) равносильно нескольким часам. И пусть никто не говорить, что других микросхем нет и только такое шифрование доступно. Конечно, это самые дешевые чипы с шифрованием. Но если б было желание, то можно и в Зеленограде сделать производство нормальных микросхем с tripleDes ‘ом.

Я надеюсь, вы используете абсолютно надежные АППАРАТНЫЕ Датчики Случайных Чисел позаимствованные у военных, а не какой-нибудь программный ДСЧ. Поскольку любой программный ДСЧ является псевдослучайным и соответственно прогнозируемым. Это же касается и механизма генерации “мастер секрета” для каждого блока сигнализации. Этот ключ должен быть не доступен на любом этапе производства. И наглухо прописываться в блок, чтоб не было возможности его никому и никак узнать, кроме как распаять и просканировать память блока, имея физический доступ к нему. Кроме того, лучше сделать его сменным по желанию клиента но только при физическом доступе к устройству. То, что он у каждого блока свой личный, а не один для всей линейки продукции, это я уж надеюсь, не поддается сомнению.

Также я надеюсь, у Вас не возникло желание сделать Базу Данных со всеми мастер ключами для всех блоков с привязкой к серийнику. Исходя из того, а вдруг у клиента потеряется брелок и нужно будет сделать копию. Ибо эту базу рано или поздно сопрут.
Так один банк пытался хранить пин-коды кредиток, закончилось плачевно 

Кроме того, я надеюсь, Вы используете протоколы обмена данными между блоком и брелком проверенные на стойкость к взлому серьезными методами верификации свойств безопасности протоколов описанными еще Catherine Meadows (Type Checking, Theorem Proving, Model Checking, BAN logic, SPI calculus). Потому что, если Вы используете какой-нибудь облегченный протокол типа “Свой-Чужой”, то при применении простейшей Dolev-Yao модели возникает много потенциальных уязвимостей. Не говоря уже про обнаруженные вышеописанными методиками.
1) Брелок посылает свой Id и код команды блоку.
2) Блок генерирует случайное число X и отсылает брелку
3) Брелок шифрует своим секретным ключом k(X)=X’ b отсылает блоку
4) Блок расшифровывает своим ключом полученный X’ k’(X’)=X” и если X”=X то все ОК и команда выполняется.
В данном случае можно на этапе 2 заглушить посылку блока и подсунуть брелку свое значение (возможно спрогнозированное будущее значение ДСЧ) и заставить брелок его зашифровать. А потом когда у блока придет время к этому якобы случайному числу отправить ему уже имеющееся зашифрованное значение вместо настоящего брелка. То есть брелок не должен шифровать данные если он не уверен от кого они пришли. Либо он должен шифровать только если команда была инициирована с его стороны. Это простейший пример атаки, а их есть еще уйма. В общем смысл в том, что к анализу свойств безопасности протоколов информационного обмена нужно подходить со всей серьезностью так же как и к конкретной реализации алгоритма или протокола. Поскольку алгоритм и протокол могут быть весьма надежными (Keeloq это не касается), а брешь обнаруживается в конкретной реализации. И отсюда вытекает следующее:
Я надеюсь, вы не стараетесь замалчивать и скрывать все принципы работы ваших изделий, прикрываясь корпоративной тайной и Ноу-Хау. А всю техническую документацию по используемым алгоритмам, протоколам и их используемым реализациям предоставляете в открытый доступ как можно большему числу желающих. Ибо любая система которая претендует на сильную защищенность и стойкость ко взлому должна иметь открытую спецификацию. Это уже неоднократно было проверено историей. Те алгоритмы, которые изначально публиковались открыто, являются самыми стойкими. А те, о принципах работы которых долго умалчивалось, находили брешь. Поскольку “все тайное становится явным”. И обратный инжиниринг или интрудеры на фирме все равно вскроют технологию.

В общем, я надеюсь, все выше написанное к Вам не относится и наше отечественное действительно будет самым лучшим. Итак, я надеюсь… , ибо надежда умирает последней 