Дата: Четверг, 06 Январь 2011, 22:50 | Сообщение # 35
Группа: Свои
Сообщений: 321
откуда: Донецк
авто: skoda A5 2.0 FSI + ГБО
Награды: 3
Skoda рейтинг: 113
Диалоговый код: панацея или нет?
(или прививка антидепрессантов)
Понять – значит упростить.
(Д. Строгов)
Последнее время фирмы-производители охранных систем рекламируют диалог как абсолютную защиту от электронного взлома. Да, диалоговые системы могут стать очередной ступенькой в совершенствовании автомобильных охран. Но сравним их с односторонними. Попытаемся выяснить, насколько удобнее и секретнее диалоговый код, может ли он считаться панацеей. Иначе разочарование может быть слишком жестоким.
Ограничения в рассмотрении проблемы
Для простоты условимся считать, что каналы связи от системы к брелку и от брелка к системе одинаковы. Особенности частотных диапазонов (низкочастотный, стандартный четыреста-мегагерцовый или гигагерцовый) обсуждать не будем. Не станем сопоставлять и разные способы модуляции.
Рассматривать стоит только настоящий диалог. Простые «двусторонние» системы, механически соединяющие в одном брелке передатчик (одностороннее управление системой с брелка) и приемник (оповещение от системы) к теме не относятся.
Сравнивая односторонние и диалоговые системы, будем считать, что подход к шифрованию одинаково строг для обеих систем.
1. Алгоритм диалога
Инициатором диалога может выступать система. Вкратце это выглядит так:
система раз за разом, достаточно часто и сильно излучает в эфир коды (запрос);
брелок, принимая запрос, подготавливает необходимый ответ;
при нажатии на кнопку брелка в эфир передается ранее подготовленная команда;
которая принимается и (после проверки) выполняется системой.
Плюсы и минусы очевидны. Хорошо, что можно использовать сигналы запроса для подтверждения наличия связи; да и реакция системы на кнопки брелка моментальная. Но все плохо с энергопотреблением, есть проблема с надежностью дальнего контроля связи, могут быть трудности при реализации некоторых режимов работы.
Если инициатор диалога брелок, то взаимодействие другое:
сначала брелок передает в систему запрос;
система отвечает контрольным сигналом;
по этому сигналу брелок шифрует ответ;
система проверяет ответ и выполняет команду.
Плюсы – низкое потребление энергии, а проверка связи не зависит от диалога и имеет большую дальность. Минусы – сигналы, как в брелке, так и в системе, обрабатываются в режиме реального времени. Для современных микропроцессоров это не проблема, но некоторая «прибалтийская задумчивость» может присутствовать.
Вывод: оптимально если инициатор диалога брелок (а точнее – хозяин автомобиля, нажимающий на кнопку брелка). Все остальное выполняется автоматически.
2. Дальность при диалоге
Вспомним, что чем длиннее код, выше вероятность его искажения. То есть, чем больше двоичных цифр путешествует по каналу связи, тем меньше дальность.
Ненадолго вернемся к односторонней передаче кода. Сначала коды были очень простыми и короткими. Но требования защищенности (от помех в эфире и от сканеров) быстро расставили все по местам: код должен быть длинноватым! Иначе система «выловит код из случайных помех», или его подберут с помощью простого «сканера» (так называются устройства, «сканирующие» = подбирающие код). Причем, если от эфирных помех можно защититься достаточно просто, то со сканером все хуже.
Посчитаем: если код передается в эфир за 10 мсек (типовая величина), то на гарантированный подбор 20-битного кода уйдет около 10 тысяч секунд, или меньше трех часов. Какая-либо защита от сканера начинается с 24-28 бит: только тогда время подбора кода будет большим (для 24 бит это два дня).
Промежуточный вывод: При передаче данных по каналу от брелка к системе приходится использовать коды не менее 25 бит. Более короткие коды опасны, и должны быть защищены от сканирования другими способами.
Подумаем, а какие данные нужно передавать от брелка к системе:
1. Брелок имеет номер. Для передачи этого номера нужны разряды. Когда их 20, это миллион комбинаций. Уменьшать разрядность нежелательно, так как если битов всего 15, то брелков будет только 32 тысячи;
2. Надо передавать в эфир номер нажатой кнопки брелка, и не одной. Дополнительная информация (разряжена батарейка, кнопка нажималась долго) не повредит. Это еще около 4-6 бит;
Такими были первые простейшие брелки. Увы, сегодня простым кодом пользоваться нельзя, так как с простыми брелками можно выпустить не более чем миллион систем. Потом брелки начнут повторяться. А еще нужно защититься от «грабберов». Значит, в код придется ввести еще несколько переменных – это номер нажатия и индекс фирмы:
3. Номер излучаемого кода должен изменяться. Для этого используется «счетчик нажатий». Чтобы счетчик «не повторялся», нужно 15-20 бит;
4. В коде должно быть отличие, позволяющее различать брелки, сделанные разными фирмами. Обычно это 16 бит.
Итого, минимально получим около 55-60 бит. Заметьте, это открытый код! То есть, он нешифрованный – его можно записать, а потом легко вычислить любой из будущих.
Прелесть перехода к "плавающей" (она же прыгающая, динамическая, изменяемая и т.д.) системе кодирования в том, что она не приводит к существенному удлинению кода. В ней есть не только постоянная часть (она соответствует номеру брелка), но и переменная (зашифрованная хитроумным алгоритмом). Переменная часть состоит из счетчика нажатия и дополнительной информации, которая должна подтвердить правильность принятой команды. Естественно, переменная часть не может быть короткой, тогда расшифровка алгоритма будет слишком легкой. Негласным стандартом стало кодирование в 32 бита. Вот мы и получили пресловутый, сначала убивший всех конкурентов, а потом незаслуженно посрамленный алгоритм Keeloq. Для него каждый пункт выглядит так:
1. Номер брелка «С» состоит из 28 бит
2. Код нажатой кнопки «B» имеет 4 бита
3. Счетчик нажатия «x» принимает 16 бит*
4. «Отличие» в неявном виде занимает 16 бит*
Итого 64 бита.
* Заметим, что в структуре Keeloq последние два пункта «перемешаны», поэтому говорить об «отличии» в явном виде не приходится.
Еще один промежуточный вывод: Односторонние системы используют коды длиной около 60 бит. Попытки «сэкономить» глупы: ограничивается количество брелков или команд, ослабляется кодовая защита.
Теперь аналогично рассмотрим диалог. Основываемся на выводе из первой главки.
Сначала брелок должен передать в эфир свой номер и счетчик нажатия (напомним, это запрос). Это необходимо, чтобы система поняла: скорее всего, нажата кнопка своего, правильного брелка. Часть этой информации должна быть зашифрована!
В противных случаях (счетчик нажатия или номер брелка не шифруются) могут быть проблемы. Хорошо, если система будет вступать в диалог со всеми брелками подряд, или с шумовыми помехами из эфира. Хуже, если угонщик сможет легко спровоцировать ее «поболтать» (легко изготовив и излучив в эфир провоцирующий код). Он может «испытывать терпение системы», раз за разом передавая такой код, пытаясь подсунуть в качестве ответа на контроль случайное число. Это будет работа на уровне классического сканера. Для коротких ответов (смотри первый промежуточный вывод) это может быть фатальным.
Неправильно включать в запрос только часть номера брелка или часть счетчика нажатия. Эта информация все равно будет передана в эфир (не при первой передаче, так при второй). Такая уловка только снизит секретность, но никак не повлияет на дальность. А ведь мы говорим сейчас именно о ней!
Запрос. Итак, нажатие на кнопку приводит к передаче в эфир следующей информации: «Система, слушай: Я - брелок номер 125. На мою кнопку нажали в 101-ый раз. Отзовись!».
При этом в эфир ориентировочно 36 бит.
Контроль. Теперь система, получив и обработав сигнал из эфира, откликается: «Ты хто?». Приятно, что нас не волнует длина этого сигнала. Система (в отличие от брелка, где приемник и передатчик питаются от одной дохленькой батарейки) работает на мощном аккумуляторе с неограниченным ресурсом по току (по мощности передачи).
Формальные ограничения по мощности передачи нас не волнуют – во-первых, пусть поймают и докажут! Во-вторых, даже в Европе стандартам не очень следуют, а у нас в России – тем более. Поэтому считаем, что система отвечает «со всей дури», и любой сигнал будет принят брелком. То есть он не будет искажен и в суммарной длине путешествующих кода число битов в контроле можно пропустить.
Ответ. Выслушав эфир, брелок посылает подтверждение: «Откройся, Пихто!». В нем – дополнительная информация, подтверждающая, что брелок свой, плюс сама команда (номер кнопки).
В сумме около 20-24 бит (помните обсуждение промежуточного вывода в начале главки? меньше просто нельзя!).
Это в идеальных условиях, когда никто не мешает и не дешифрует. Попытки противодействия только удлинят диалог. Ну да ладно, не будем мелочиться. Просто сложим длину передаваемых кодов (от брелка к системе), сравним со вторым промежуточным выводом и подведем итог.
Вывод: Диалоговый код не имеет преимуществ по дальности (или помехозащищенности) перед односторонней передачей данных.
Отступление №1