Comments 19
Прыгающие коды будут быстрее. В качестве ключа — увеличивающееся на единицу с каждой попыткой авторизации число. Авторизация возможна в небольшом окне вокруг «текущего» значения. В случае успешной авторизации сервер синхронизирует свой счётчик. Плюс есть намного большее окно, в котором для авторизации нужно передать несколько кодов подряд (авторизация произойдёт после нескольких успешных попыток подряд). Это позволяет восстанавливать синхронизацию ключей-счётчиков в случае потери связи.
Пакет синхронизации состоит из открытого идентификатора пользователя (чтобы знать какой из ключей использовать) и шифрованного содержиморго. Счётчик является ключом (или частью ключа) шифрования.
В качестве содержимого для шифрования берётся достаточно длинный (т.к. по нему удостоверяется правильность расшифровки и авторизации) постоянный идентификатор (например, имя сервера) и случайная последовательность (которая в после успешной авторизации может использоваться, как ключ к каналу сервер-клиент).
Правда, по-моему оно патентованное по самый уши.
Пакет синхронизации состоит из открытого идентификатора пользователя (чтобы знать какой из ключей использовать) и шифрованного содержиморго. Счётчик является ключом (или частью ключа) шифрования.
В качестве содержимого для шифрования берётся достаточно длинный (т.к. по нему удостоверяется правильность расшифровки и авторизации) постоянный идентификатор (например, имя сервера) и случайная последовательность (которая в после успешной авторизации может использоваться, как ключ к каналу сервер-клиент).
Правда, по-моему оно патентованное по самый уши.
А чем не подошло уже готовое решение — Secure Remote Password Protocol (SRP)?
А чем не подошло ещё более готовое решение — обычная парольная аутентификация с использованием HTTPS?
Бывают случаи, когда надо обойтись без HTTPS и при этом прослушивание трафика не исключается.
Что это за случаи такие?
По сути, насколько я знаю, в SSL используются практически такие же протоколы аутентификации. Я в своей статье хотел более доступно, на каком-то примере, рассказать про эти частные алгоритмы. К тому же в моем случае предполагается, что пользователь не должен вводить пароль. В локальной сети вряд ли будит много «левых» клиентов, подключающихся к серверу, а из интернета вообще очень редко будит требоваться аутентификация между клиентом и сервером (поэтому можно заранее большинство таких аутентификаций запретить). Разве только когда сотрудника отправят в командировку с корпоративным ноутбуком). Вот и решил, так сказать, поэкспериментировать.
>> На первом шаге клиент посылает случайно выбранное число серверу, чтобы он мог зашифровать его общим для них ключом ...
>> … В тоже время злоумышленник не мог бы сформировать хэш HMAC( Nк, Nс, К, С, Кs), т.к. он как минимум не должен знать секретного ключа Ks.
Общий ключ на клиенте где хранится и в каком виде? Вот это и есть проблема.
Дальше у вас ничего в принципе уникального не описывается.
Можно вообще использовать простейшую последовательность аутентификации Kerberos, немного модифицировав его под нужную вам схему работы, чтобы с помощью общего ключа(который при желании можно сделать и самогенеренным сертификатом с парами несимметричных ключей) в защищенном режиме только обменяться сеансовыми ключами(random), которые вы можете сделать хоть в несколько килобайт длиною(а то и мегабайт), и которые в совокупности с режимом шифрования, отличным от ECB, дадут вам необходимую надежность. При этом шифровать трафик можно чуть ли не RC4 алгоритмом, который при грамотной сцепке и грамотной мутации ключа дает достаточно высокую надежность(не столько сам алгоритм, сколько грамотная сцепка блоков) и за счет того, что занимает условно менее десятка строчек кода, дает так же высокую скорость работы(в отличии от SSL, к примеру).
Это все просто как пример. В реальности многое зависит от конкретной задачи, условий работы продукта и требований «заказчика». В некоторых областях нельзя выбрать произвольные алгоритмы, сколь бы надежными они на самом деле не были — требуют только сертифицированные и стандартизированные решения.
>> … В тоже время злоумышленник не мог бы сформировать хэш HMAC( Nк, Nс, К, С, Кs), т.к. он как минимум не должен знать секретного ключа Ks.
Общий ключ на клиенте где хранится и в каком виде? Вот это и есть проблема.
Дальше у вас ничего в принципе уникального не описывается.
Можно вообще использовать простейшую последовательность аутентификации Kerberos, немного модифицировав его под нужную вам схему работы, чтобы с помощью общего ключа(который при желании можно сделать и самогенеренным сертификатом с парами несимметричных ключей) в защищенном режиме только обменяться сеансовыми ключами(random), которые вы можете сделать хоть в несколько килобайт длиною(а то и мегабайт), и которые в совокупности с режимом шифрования, отличным от ECB, дадут вам необходимую надежность. При этом шифровать трафик можно чуть ли не RC4 алгоритмом, который при грамотной сцепке и грамотной мутации ключа дает достаточно высокую надежность(не столько сам алгоритм, сколько грамотная сцепка блоков) и за счет того, что занимает условно менее десятка строчек кода, дает так же высокую скорость работы(в отличии от SSL, к примеру).
Это все просто как пример. В реальности многое зависит от конкретной задачи, условий работы продукта и требований «заказчика». В некоторых областях нельзя выбрать произвольные алгоритмы, сколь бы надежными они на самом деле не были — требуют только сертифицированные и стандартизированные решения.
Спасибо за комментарий. Сам я только недавно более менее серьезно стал изучать криптографию, в результате чего вполне могут быть какие-то пробелы в знаниях. В данной статье, как я написал выше, я не столько хотел придумать что-то уникальное, сколько рассказать на примере про данные способы аутентификации. А хранение ключей это да, уже отдельная проблема.
Да я и не в претензии. По сути я только указал, что во многих сложных схемах криптозащиты зачастую допускаются банальнейшие поверхностные ошибки, из-за которых стойкость системы сходит на нет.
Поэтому даже при использовании самых проверенных и надежных технологий нужно внимательнейшим образом всесторонне рассматривать все места стыковки этих технологий в своих схемах защиты.
Подводят как правило именно эти места.
Точно так же и здесь — если пароли(ключи) программа хранит где-то, вот вам и одно из самых узких мест. Если у злоумышленника есть хоть какой-то потенциальный доступ к этим данным, то уже практически не важно, сколь сложный и мощный алгоритм защиты реализован в программе.
По сути идеальная криптозащита должна быть такой, чтобы публикация всего алгоритма никоим образом не могла сказаться негативно на ее криптостойкости.
Поэтому даже при использовании самых проверенных и надежных технологий нужно внимательнейшим образом всесторонне рассматривать все места стыковки этих технологий в своих схемах защиты.
Подводят как правило именно эти места.
Точно так же и здесь — если пароли(ключи) программа хранит где-то, вот вам и одно из самых узких мест. Если у злоумышленника есть хоть какой-то потенциальный доступ к этим данным, то уже практически не важно, сколь сложный и мощный алгоритм защиты реализован в программе.
По сути идеальная криптозащита должна быть такой, чтобы публикация всего алгоритма никоим образом не могла сказаться негативно на ее криптостойкости.
Теперь понял. Здесь, чтобы частично защититься от утечки ключей, я предложил генерировать эти ключи через рандомный промежуток времени. Причем этот промежуток злоумышленник никак не может знать, т.к. он генерируется на стороне сервера, и уже сам сервер отдает команды о необходимости обновления ключа. К тому же для каждого клиента будит генерироваться уникальный секретный ключ.
Другое дело, что если злоумышленник будит все время скачивать секретный ключ, как только он будит устанавливаться. Но это означает, что на компьютере клиента стоит троян. А это означает, что злоумышленнику то по сути нету смысла скачивать постоянно этот секретный ключ, т.к. он может и так скачать те данные, какие ему нужно, и после этого удалить свое присутствие в системе.
Другое дело, что если злоумышленник будит все время скачивать секретный ключ, как только он будит устанавливаться. Но это означает, что на компьютере клиента стоит троян. А это означает, что злоумышленнику то по сути нету смысла скачивать постоянно этот секретный ключ, т.к. он может и так скачать те данные, какие ему нужно, и после этого удалить свое присутствие в системе.
Именно. А если он каким-то образом выкусит алгоритм, например вы сами по неосторожности засунете всю работу с сервером в DLL, которую злоумышленник тупо сопрет и заюзает и ему уже будет совершенно пофигу, через какой промежуток будет обновляться ключ — ваша либа для него сама все разрулит.
Ровно так же работают большинство взломов к разному дорогому ПО. Просто выкусывают под отладчиком из бинарников все куски кода, работающие с регистрацией программы и их же используют для кейгенов.
То есть весь алгоритм за злоумышленников написали сами авторы этих программ и отдали вместе с триал-версией программы. Парадокс, да.
Именно поэтому так важен последний абзац в моем предыдущем комментарии — алгоритм должен быть стоек к публикации. При желании с натяжкой можно перефразировать, как «взлом вашего ПО должен быть осуществим только с помощью социнженерии либо терморектального криптоанализа», но обеспечение этого вида защиты — задача уже не айтишной службы секьюрити )))
Ровно так же работают большинство взломов к разному дорогому ПО. Просто выкусывают под отладчиком из бинарников все куски кода, работающие с регистрацией программы и их же используют для кейгенов.
То есть весь алгоритм за злоумышленников написали сами авторы этих программ и отдали вместе с триал-версией программы. Парадокс, да.
Именно поэтому так важен последний абзац в моем предыдущем комментарии — алгоритм должен быть стоек к публикации. При желании с натяжкой можно перефразировать, как «взлом вашего ПО должен быть осуществим только с помощью социнженерии либо терморектального криптоанализа», но обеспечение этого вида защиты — задача уже не айтишной службы секьюрити )))
Я с этим согласен. Но в описанных мною протоколах генерация ключей происходит рандомным способом. Также и установление промежутка времени может происходить рандомно. То есть даже если злоумышленник заполучит серверную часть приложения и зареверсит ее, то это ничего ему не даст. Для расшифровки трафика на каком-то промежутке времени ему придется все равно использовать брутфорс.
Это мы уже отвлекаемся от темы. Я-то говорю о концептуальных ошибках. Вы в статье рассматриваете вариант, когда злоумышленник пропускает трафик сквозь себя, то есть работает шлюзом и слушает эфир, как бы не выдавая своего присутствия. В реале же возможна ситуация, при которой вы будете зациклены именно на этой схеме перехвата, а злоумышленнику это и не нужно будет. Он пойдет по более простому пути: сопрет у юзера ключ, расковыряет алгоритм, грамотно подключится отдельной сессией и сольет необходимые ему данные. Возможно при этом вы даже заметите его в логах, но будет поздно. Кроме того, при грамотном подходе социнженерия опять же в помощь — не факт, что вы вообще логи эти регулярно смотрите, и не факт, что программа-анализатор логов распознает интрудера.
Брутфорсить в лоб будут уже как крайний вариант, за неимением более простых способов(тот же терморектальный криптоанализ).
Брутфорсить в лоб будут уже как крайний вариант, за неимением более простых способов(тот же терморектальный криптоанализ).
А в чём Вы рисовали схемы не подскажете? А то у меня задача похожая, но уровень безопасности намного ниже. Вот тоже скоро надо будет рисовать красивые схемки…
Sign up to leave a comment.
Безопасная аутентификация между клиентом и сервером без ввода логина и пароля