Andrey Ford
Активный участник
- Регистрация
- 05.11.2007
- Сообщения
- 33 093
- Реакции
- 415
- Баллы
- 83
Вы не устали? Давайте отвлечемся! Разберем самые популярные рассказы о достоинствах диалога. Начнем с «абсолютного преимущества». Пользователя убеждают:
При односторонней передаче все сигналы исходят из брелка, и могут быть разгаданы на современных компьютерах путем записи и последующего анализа. При диалоге это не так – всякий раз система отвечает по-новому, в диалог вносится случайный элемент. Диалог разгадать невозможно!
Это примитивная ложь. Если «хакеры» всесильны, кто мешает им написать подряд все три сигнала (запрос – контроль – ответ), как один псевдо-односторонний код и взломать его? Если такой длинный код можно вскрыть – можно вскрыть и диалог. Но диалог всегда уступит одностороннему брелку с длинным кодом: что и как там внутри (в брелке) намешано – неизвестно, а в диалоге есть известная слабина: сам диалог. Потому как ответ получается (главным образом) из переделанного контроля. И самое глупое, что может сделать разработчик – это открыто сообщить, что «…система в качестве контроля посылает случайное число, а ответ делается из этого числа…». Тут половина секрета уже разгадана, так как хакер вскрывает не весь код, а только его часть.
Системы с односторонней передачей дефектны в принципе. Пользоваться ими – это все равно, что идти по улице и кричать: «Машина откройся! Машина закройся!». Любой подслушает. Любой научится «открывать машину». То ли дело «диалоговый код». Это как на посту: на окрик «Пустите!» у тебя спросят, знаешь ли ты правильный отзыв. Знаешь – пропустят, не знаешь – извини!
Вы знаете, как устроены системы опознавания в военной авиации? Там стоит система запроса «Свой – чужой». Если на запрос с земли самолет правильно не отвечает, его немедленно сбивают! Давайте Вам поставим систему опознавания, как в самолете!
Так вот это все враки! Сам смысл «системы опознавания по отзыву» состоит в том, что правильный отзыв сообщается другим способом, тихонько, ЗАРАНЕЕ, на ушко. В карауле – перед разводом, в авиации – перед полетом.
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 пары приемник-передатчик (напомним, это каналы от брелка к системе и от системы к брелку), то вероятность выхода из строя выше (опять-таки, при прочих равных подходах к проектированию). И психологическая готовность хозяина к возможному сбою или отказу тоже существенно больше.
В действительности, нам совсем не хочется никого пугать. К сожалению, уже дважды мы оказывались правы в своих худших опасениях. Может, хватит?
При односторонней передаче все сигналы исходят из брелка, и могут быть разгаданы на современных компьютерах путем записи и последующего анализа. При диалоге это не так – всякий раз система отвечает по-новому, в диалог вносится случайный элемент. Диалог разгадать невозможно!
Это примитивная ложь. Если «хакеры» всесильны, кто мешает им написать подряд все три сигнала (запрос – контроль – ответ), как один псевдо-односторонний код и взломать его? Если такой длинный код можно вскрыть – можно вскрыть и диалог. Но диалог всегда уступит одностороннему брелку с длинным кодом: что и как там внутри (в брелке) намешано – неизвестно, а в диалоге есть известная слабина: сам диалог. Потому как ответ получается (главным образом) из переделанного контроля. И самое глупое, что может сделать разработчик – это открыто сообщить, что «…система в качестве контроля посылает случайное число, а ответ делается из этого числа…». Тут половина секрета уже разгадана, так как хакер вскрывает не весь код, а только его часть.
Системы с односторонней передачей дефектны в принципе. Пользоваться ими – это все равно, что идти по улице и кричать: «Машина откройся! Машина закройся!». Любой подслушает. Любой научится «открывать машину». То ли дело «диалоговый код». Это как на посту: на окрик «Пустите!» у тебя спросят, знаешь ли ты правильный отзыв. Знаешь – пропустят, не знаешь – извини!
Вы знаете, как устроены системы опознавания в военной авиации? Там стоит система запроса «Свой – чужой». Если на запрос с земли самолет правильно не отвечает, его немедленно сбивают! Давайте Вам поставим систему опознавания, как в самолете!
Так вот это все враки! Сам смысл «системы опознавания по отзыву» состоит в том, что правильный отзыв сообщается другим способом, тихонько, ЗАРАНЕЕ, на ушко. В карауле – перед разводом, в авиации – перед полетом.
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 пары приемник-передатчик (напомним, это каналы от брелка к системе и от системы к брелку), то вероятность выхода из строя выше (опять-таки, при прочих равных подходах к проектированию). И психологическая готовность хозяина к возможному сбою или отказу тоже существенно больше.
В действительности, нам совсем не хочется никого пугать. К сожалению, уже дважды мы оказывались правы в своих худших опасениях. Может, хватит?
