Диалоговый код: панацея или нет?
(или прививка антидепрессантов)
Понять – значит упростить.
(Д. Строгов)
 Последнее время фирмы-производители охранных систем рекламируют диалог как абсолютную защиту от электронного взлома. Да, диалоговые системы могут стать очередной ступенькой в совершенствовании автомобильных охран. Но сравним их с односторонними. Попытаемся выяснить, насколько удобнее и секретнее диалоговый код, может ли он считаться панацеей. Иначе разочарование может быть слишком жестоким.
Ограничения в рассмотрении проблемы
Для простоты условимся считать, что каналы связи от системы к брелку и от брелка к системе одинаковы. Особенности частотных диапазонов (низкочастотный, стандартный четыреста-мегагерцовый или гигагерцовый) обсуждать не будем. Не станем сопоставлять и разные способы модуляции.
Рассматривать стоит только настоящий диалог. Простые «двусторонние» системы, механически соединяющие в одном брелке передатчик (одностороннее управление системой с брелка) и приемник (оповещение от системы) к теме не относятся.
Сравнивая односторонние и диалоговые системы, будем считать, что подход к шифрованию одинаково строг для обеих систем.
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
Вы не устали? Давайте отвлечемся! Разберем самые популярные рассказы о достоинствах диалога.
Начнем с «абсолютного преимущества». Пользователя убеждают:
- При односторонней передаче все сигналы исходят из брелка, и могут быть разгаданы на современных компьютерах путем записи и последующего анализа. При диалоге это не так – всякий раз система отвечает по-новому, в диалог вносится случайный элемент. Диалог разгадать невозможно!
Это примитивная ложь. Если «хакеры» всесильны, кто мешает им написать подряд все три сигнала (запрос – контроль – ответ), как один псевдо-односторонний код и взломать его? Если такой длинный код можно вскрыть – можно вскрыть и диалог. Но диалог всегда уступит одностороннему брелку с длинным кодом: что и как там внутри (в брелке) намешано – неизвестно, а в диалоге есть известная слабина: сам диалог. Потому как ответ получается (главным образом) из переделанного контроля. И самое глупое, что может сделать разработчик – это открыто сообщить, что «…система в качестве контроля посылает случайное число, а ответ делается из этого числа…». Тут половина секрета уже разгадана, так как хакер вскрывает не весь код, а только его часть.
- Системы с односторонней передачей дефектны в принципе. Пользоваться ими – это все равно, что идти по улице и кричать: «Машина откройся! Машина закройся!». Любой подслушает. Любой научится «открывать машину». То ли дело «диалоговый код». Это как на посту: на окрик «Пустите!» у тебя спросят, знаешь ли ты правильный отзыв. Знаешь – пропустят, не знаешь – извини!
- Вы знаете, как устроены системы опознавания в военной авиации? Там стоит система запроса «Свой – чужой». Если на запрос с земли самолет правильно не отвечает, его немедленно сбивают! Давайте Вам поставим систему опознавания, как в самолете!
Так вот это все враки! Сам смысл «системы опознавания по отзыву» состоит в том, что правильный отзыв сообщается другим способом, тихонько, ЗАРАНЕЕ, на ушко. В карауле – перед разводом, в авиации – перед полетом.
3. Секретность диалогового кода
Шутки в сторону! Ключевой вопрос: гарантирует ли диалог большую секретность, чем односторонняя передача. Переведем все описанное на формальный язык. Как и раньше, упростим ситуацию и сравним двусторонний код с односторонним.
Для обычного одностороннего кода (аналог «стандартного Keeloq’а») будем считать, что код «F» образуется из известного нажатия «x», номер брелка «С», номер кнопки «B» и основного секрета (пароля) производителя «А»:
F=F(x,C,B,A)
Эту функцию расшифровать сложно, так как необходимо подобрать пароль «А». На знании (подбор, угадывание, воровство и т.д.) пароля «А» строится работа современных грабберов.
Для продвинутого одностороннего кода (аналог «полного Keeloq’а») немного сложнее. Закон изменения кода различен для каждого брелка «С», так как отличаются сами пароли «Ac»:
Fc=F(x,C,B,Ac)
Функция индивидуальна и для ее разгадывания необходимо всякий раз подобрать пароль «Ac» (напомню, он неизвестен). Особенность ее в том, что чем длиннее пароль, тем лучше она защищена от подбора.
Вот теперь, когда мы вспомнили терминологию, применявшуюся для описания систем с односторонней передачей данных, сделаем следующее.
Запрос. Запишем точно в таких же обозначениях все, что относится к примитивному диалоговому коду:
Y=F(x,C,B)
То есть практическая константа! К секретности она не имеет никакого отношения, это просьба начать диалог. Если константа «нешифрованная» и представляет собой простую геометрическую сумму (последовательно поставленные коды) – тем хуже, но не намного.
Контроль. Затем система уточняет, кто и зачем ее спрашивает:
Di
Он передается в открытом виде и являет собой ПРОСТЫЕ константы, назовем их для простоты «Di». После приема следующего правильного кода запроса «Y» константа будет другой: «Di+1».
Ответ1. Наконец, переработав вопрос, брелок передает:
Zi=Z(Di)
И это называется секретным кодом? Бросьте, он секретен постольку, поскольку еще никто не пытался (не хотел, не собирался) его вскрывать.
Вообще это называется Security Through Obscurity (STO, секретность через неясность). Весь секрет в том, как именно устроена функция «Z». Попробуйте объяснить внятно, чем шифрование в функции: «Fc=F(x,C,B,Ac)» хуже (напомню, «x» и «Ac» неизвестны), чем в функции «Z =Z(Di)» (напомню, «Di» заранее известны)? Не понятно? Нам тоже…
Ведь в первом случае необходимо разгадать неизвестную функцию неизвестных аргументов, во втором - неизвестную функцию известных аргументов. Что проще?
Только не надо примитивных провокаций на тему: «Функция «F» заранее всем известна, это Keeloq, а функция «Z» нет!». Во-первых, нет такой функции – сам Keeloq еще не вскрыт. Во вторых, мы же договорились в самом начале, что «…подход к шифрованию одинаково строг для систем любых типов…». И под страааашным словом Keeloq мы подразумеваем не больше, чем Keeloq-подобную структуру зашифрованного кода.
Ответ2. Не получилось – не беда! Сделаем следующий шаг. Перейдем от примитивного диалогового кода к обычному, то есть аналогу того самого «стандартного Keeloq’а», которым всех стращают (заслуженно). Введем в ответ пароль «A», общий для всех брелков одного производителя:
Zi=Z(Di,A)
Что изменилось? Функция шифрования слегка усложнилась, и просто узнать (украсть) секрет этой функции стало недостаточно. Нужно украсть еще и пароль. Но взлом не усложнился. Так как вид функции «Z» неизвестен, то совершенно все равно, что разгадывать – вид самой функции или вид самой функции вместе с паролем. Разве что производителю проще изменить шифрование, если пароль «A» просто украдут.
Ответ3. Ну и финальный шаг очевиден:
Zic=F(x,Di,C,B,Ac)
Самое важное: пароль «Ac» становится индивидуальным для каждого из брелков. Константы «x», «Di», «C», «B» для данного сеанса связи известны в прямом эфире, сколько из них использовать – одну или все сразу, абсолютно все равно, к секретности отношения не имеет. Пожалуй, «B» неплохо бы оперативно использовать (только для проверки номера нажатой кнопки).
Вам это ничего не напоминает? Да-да, это и есть тот самый Keeloq-подобный код, с которого все и началось! И стоило огород городить?
Ответ4. А дальше что? Остался только один выход – перенести основное противостояние с «изюминки» (то есть с диалога) в запрос (сделать его таким же, как в Keeloq’е). Тогда функция запроса «Y» будет хорошо зашифрована. Вот только диалог тут вроде как уже и не нужен. Но об этом чуть-чуть позже.
Увы, неизбежный вывод: Диалоговый код в своей классической трактовке не имеет никаких преимуществ в секретности перед односторонней передачей данных (при равных подходах к шифрованию).
4. А что в реальности?
Это самая короткая из главок. Удивительное совпадение изложенных умозрительных заключений (сделанных еще 4 года назад) с данными из открытых источников заставило (наконец!) дописать текст. Слово авторам одной из реализаций диалогового кода:
Запрос: статический код 32 бита;
Контроль: динамический код 24 бита;
Ответ: динамический код 24 бита.
Вывод: Это STO в чистом виде.
5. Что же делать?
Не надо расстраиваться! Мы же с Вами уже получили итоговый результат: для того, чтобы успешно конкурировать (не на словах, а на деле) с системами односторонней передачи, использующими Keeloq-подобный код в «полном объеме» необходимо… Да-да! Использовать этот самый Keeloq! Причем, лучше – с самого начала. То есть шифровать с его помощью сам запрос.
Все отличие с односторонними системами будет состоять в следующем:
- В односторонних системах после приема кода может наступить снятие с охраны;
- В двусторонних за приемом первого кода (запроса) следует автоматическое подтверждение правильности снятия (контроль-ответ, то есть самостоятельно, без излишнего напряжения организма пользователя).
Впрочем, подтверждение бывает и в односторонних системах. Например, с помощью метки, контактного ключа, прикладывания пальца, набора кодовой комбинации, и проч. Причем, принципиально на других принципах – что позволяет (например) не так бояться кражи брелка, как отрезания пальца вместе с ним.
Вывод: Сделайте самостоятельно.
Отступление №2. Неужели так все плохо?
Вы опять стали плохо спать? Вам кажется, что Вас опять обманули? Вообще-то, хорошо помогает валерьянка, но доброе слово тоже приятно:
- Да, уже сегодня диалог помогает! Владельца системы труднее обмануть методом подмены кода (в терминах упомянутой статьи);
- Увы, его можно обмануть множеством других способов, например, сымитировав отказ радиоканала управления сплошной заградительной помехой. Так как в управлении системой задействованы 2 пары приемник-передатчик (напомним, это каналы от брелка к системе и от системы к брелку), то вероятность выхода из строя выше (опять-таки, при прочих равных подходах к проектированию). И психологическая готовность хозяина к возможному сбою или отказу тоже существенно больше.
В действительности, нам совсем не хочется никого пугать. К сожалению, уже дважды мы оказывались правы в своих худших опасениях. Может, хватит?
Magic Ring,
2006-2009 г.
Продолжение....
|
Проблемы одностороннего доступа