Некоторое время назад мне по работе пришлось столкнуться с проектированием и реализацией протокола аутентификации. Побочным эффектом этой работы стал протокол, назовем его для краткости MAuth, который использует симметричное шифрование с длиной ключа всего 40 бит, секретный ключ которого, получить невозможно. Речь сегодня пойдет именно о нем…
MAuth является развитием семейства протоколов EKE, предложенных в 1992 году Стивеном Беллоуином и Майклом Мерриттом. Предупреждая критику такого «секьюрного» протокола, сразу оговорюсь, что область применения MAuth ограничена передачей информации, актуальной только на момент передачи. Выражаясь математически – в течение времени T с момента ее отправки одной из сторон.
Примером задачи, которая успешно решается данным протоколом, является защита соединения при удаленном управлении каким-либо объектом. Здесь требуется обеспечить невозможность управления без знания секретного ключа и надежную системы аутентификации клиента. Команды управления объектом не являются чем-то секретным и описаны в его технической документации.
Воспользуемся следующей нотацией описания защищенных протоколов. Режим рукопожатия MAuth включает всего три шага:
I. C -> S: C
II. S -> C: {Ns}Kcs
III. C -> S: {K'cs}Kcs
, где C и S — идентификаторы клиента и сервера аутентификации, соответственно;
Ns – псевдослучайное число, сгенерированное сервером;
Kcs – секретный ключ, известный клиенту и серверу;
K'cs – сессионный ключ, K'cs = H(Kcs + Ns). Здесь H – криптографическая хэш-функция.
В режиме передачи все сообщения шифруются сессионным ключом, который имеет такую же длину, как и секретный – 40 бит. Это и есть самое «узкое» место MAuth.
Предположим, что злоумышленнику известна первая команда, которую клиент пересылает серверу. В этом случае, методом грубой силы он может подобрать сессионный ключ за время T. При использовании современных алгоритмов симметричного шифрования, уязвимость которых еще не найдена (к примеру, Blowfish), мы имеем достаточный запас времени до истечения T, чтобы выполнить все необходимые нам операции и разорвать соединение.
Данный протокол устойчив ко всем видам как пассивных, так и активных атак. Прослушивание ничего не даст злоумышленнику, кроме получения идентификатора клиента. Использование сильного генератора псевдослучайных чисел не дает возможности угадать Ns. Взлом сессионного ключа также не даст возможности получить Kcs, так как подобрать хэш случайного числа (Kcs + Ns) не представляется возможным.
Повторное воспроизведение сообщений наткнется на отказ сервера. По этой причине псевдослучайное число должно быть уникальным в рамках общения сервера с данным клиентом.
Подмена сообщений также приведет к разрыву соединения. Причем взаимная аутентификация сервера клиентом здесь осознанно опущена для увеличения скорости и простоты протокола. Если злоумышленник попытается выдать себя за сервер, то клиент, получив на 4-ом шаге ответ зашифрованный неверным сессионным ключом, просто разорвет соединение.
В соответствии с постановлением правительства РФ №957 «Об утверждении положений о лицензировании отдельных видов деятельности, связанных с шифровальными (криптографическими) средствами» согласно пункту 1-д положения о разработке шифровальных средств, MAuth можно свободно использовать в коммерческих приложениях.
Кроме того, использование симметричного шифрования дает нам возможность избавиться от третьей стороны (удостоверяющего центра). А защищенная передача 5 байт информации при регистрации клиента видится довольно простой задачей (можно передать при встрече, либо по телефону).
Большое спасибо за ревью статьи Ивану Ручкину и Дмитрию Тилик.
Через сутки после опубликования описания протокола MAuth, он был взломан хабраюзером NeverWalkAloner. Он заметил, что после взлома сессионного ключа K'cs за время T (при условии, что злоумышленник знает содержание одного из сообщений), имея на руках {K'cs}Kcs, методом полного перебора можно получить и секретный ключ Kcs. В итоге через время 2T после начала сессии злоумышленник получает в свое распоряжние контроль над объектом управления.
Как лечить? Изменим режим рукопожатия следующим образом:
I. C -> S: C
II. S -> C: {Ns}H(Kcs)
III. C -> S: {H(Kcs — Ns)}H(Kcs)
, где H — криптографическая хэш-функция (размер хэша — 40 бит).
Все последующие сообщения шифруются сессионным ключом K'cs = H(Kcs + Ns).
К бонусам прибавляется еще один: переменная длина секретного ключа Kcs.
Соавтор исправленной версии MAuth: NeverWalkAloner.
Зачем?
MAuth является развитием семейства протоколов EKE, предложенных в 1992 году Стивеном Беллоуином и Майклом Мерриттом. Предупреждая критику такого «секьюрного» протокола, сразу оговорюсь, что область применения MAuth ограничена передачей информации, актуальной только на момент передачи. Выражаясь математически – в течение времени T с момента ее отправки одной из сторон.
Примером задачи, которая успешно решается данным протоколом, является защита соединения при удаленном управлении каким-либо объектом. Здесь требуется обеспечить невозможность управления без знания секретного ключа и надежную системы аутентификации клиента. Команды управления объектом не являются чем-то секретным и описаны в его технической документации.
Как?
Воспользуемся следующей нотацией описания защищенных протоколов. Режим рукопожатия MAuth включает всего три шага:
I. C -> S: C
II. S -> C: {Ns}Kcs
III. C -> S: {K'cs}Kcs
, где C и S — идентификаторы клиента и сервера аутентификации, соответственно;
Ns – псевдослучайное число, сгенерированное сервером;
Kcs – секретный ключ, известный клиенту и серверу;
K'cs – сессионный ключ, K'cs = H(Kcs + Ns). Здесь H – криптографическая хэш-функция.
В режиме передачи все сообщения шифруются сессионным ключом, который имеет такую же длину, как и секретный – 40 бит. Это и есть самое «узкое» место MAuth.
Предположим, что злоумышленнику известна первая команда, которую клиент пересылает серверу. В этом случае, методом грубой силы он может подобрать сессионный ключ за время T. При использовании современных алгоритмов симметричного шифрования, уязвимость которых еще не найдена (к примеру, Blowfish), мы имеем достаточный запас времени до истечения T, чтобы выполнить все необходимые нам операции и разорвать соединение.
Данный протокол устойчив ко всем видам как пассивных, так и активных атак. Прослушивание ничего не даст злоумышленнику, кроме получения идентификатора клиента. Использование сильного генератора псевдослучайных чисел не дает возможности угадать Ns. Взлом сессионного ключа также не даст возможности получить Kcs, так как подобрать хэш случайного числа (Kcs + Ns) не представляется возможным.
Повторное воспроизведение сообщений наткнется на отказ сервера. По этой причине псевдослучайное число должно быть уникальным в рамках общения сервера с данным клиентом.
Подмена сообщений также приведет к разрыву соединения. Причем взаимная аутентификация сервера клиентом здесь осознанно опущена для увеличения скорости и простоты протокола. Если злоумышленник попытается выдать себя за сервер, то клиент, получив на 4-ом шаге ответ зашифрованный неверным сессионным ключом, просто разорвет соединение.
Бонусы
В соответствии с постановлением правительства РФ №957 «Об утверждении положений о лицензировании отдельных видов деятельности, связанных с шифровальными (криптографическими) средствами» согласно пункту 1-д положения о разработке шифровальных средств, MAuth можно свободно использовать в коммерческих приложениях.
Кроме того, использование симметричного шифрования дает нам возможность избавиться от третьей стороны (удостоверяющего центра). А защищенная передача 5 байт информации при регистрации клиента видится довольно простой задачей (можно передать при встрече, либо по телефону).
Большое спасибо за ревью статьи Ивану Ручкину и Дмитрию Тилик.
UPD от 07.12.2010
Через сутки после опубликования описания протокола MAuth, он был взломан хабраюзером NeverWalkAloner. Он заметил, что после взлома сессионного ключа K'cs за время T (при условии, что злоумышленник знает содержание одного из сообщений), имея на руках {K'cs}Kcs, методом полного перебора можно получить и секретный ключ Kcs. В итоге через время 2T после начала сессии злоумышленник получает в свое распоряжние контроль над объектом управления.
UPD от 10.12.2010
Как лечить? Изменим режим рукопожатия следующим образом:
I. C -> S: C
II. S -> C: {Ns}H(Kcs)
III. C -> S: {H(Kcs — Ns)}H(Kcs)
, где H — криптографическая хэш-функция (размер хэша — 40 бит).
Все последующие сообщения шифруются сессионным ключом K'cs = H(Kcs + Ns).
К бонусам прибавляется еще один: переменная длина секретного ключа Kcs.
Соавтор исправленной версии MAuth: NeverWalkAloner.