Возможные уязвимости в представленном алгоритме обмена между ключом и замком через радиоканал?
Здравствуйте! Нужен совет по поводу безопасности использования представленной схемы аутентификации между замком и ключом (имеется ввиду ключ открывающий удаленный замок, через радиоканал):
1. Ключ генерирует абсолютно уникальную последовательность (никогда не повторяется), назовем ее "K1".
2. Ключ посылает запрос в замок, запрос состоит из K1 и H1 = MD5(K1 + SALT1)
3. Замок проверяет равенство H1 = MD5(K1 + SALT1)
4. Замок генерирует абсолютно уникальную последовательность (никогда не повторяется), назовем ее "K2".
5. Замок отвечает ключу пакетом, который состоит из H2 = MD5(K2 + SALT2)
6. Ключ делает H3 = MD5(H2 + SALT3) и отсылает это обратно замку
7. Замок проверяет равенство H3 = MD5(H2 + SALT3) и соотв. образом реагирует на это
Каковы возможные уязвимости? Безопасно ли (применительно к данному контексту) использование MD5?
Обновление вопроса:
Вообщем посоветовали мне следующее:
1. Выкинуть шаги 1 - 3 полностью
2. Заменить MD5 на HMAC вариацию HMAC-MD5 / HMAC-SHA1
MD5(K1 + SALT1) - это всего лишь цифровая подпись, она используется лишь для того чтобы замок мог определить, что запрос был послан действительно ключом. В моем случае это вообще никак не влияет на безопасность системы в целом, т. н. защита от дурака (с тем же успехом ключ мог бы посылать строку "open")
Армянское Радио: нет, ни в коем случае не принял этого на свой счет, Вы не так меня поняли. Мой комментарий был скорее в духе "докажите что эта система имеет серъезный изъян". Указанный Вами шаг, как я уже отметил, не влияет на безопасность системы.
token: на первом шаге можно вытащить MD5(SALT1), на шестом MD5(SALT3). Перебором находим SALT3 (для этого есть ASIC по скромным ценам), зная SALT3 и H2 делаем H3, всего хорошего, дорогой велосипед.
Итого, все ваши навороты свелись к поиску коллизии одной хэш-функции.
Армянское Радио: давайте на минутку забудем про переборы? Никто в здравом уме не будет сидеть и подбирать это все. Я правильно понимаю что на шестом шаге да и на первом тоже, проблема в том, что можно (теоретически) найти соль, зная часть сообщения?
token: На сколько я понимаю, этот алгоритм должен обеспечить не срабатывание замка, на какие-либо случайные сигналы и помехи. Если да, то, имхо, вполне подойдет. Но он обеспечит только это - "защиту от дурака".
Для чего-то более серьезного не годится, т.е. я имею ввиду, что при желании любой "не дурак" зная алгоритм и имея замок сможет собрать свой собственный ключ.
res2001: ну можно еще и заксорить K1 и H1 = MD5(K1 + SALT1), это не важно, поскольку - не влияет на безопасность системы в целом, я уже отвечал в комментарии, что вместо этого с таким же успехом, ключ мог бы посылать строку "open" в открытом виде.
Ну и посылайте open открытым текстом - для "защиты от дурака" достаточно.
Хотя я бы послал по длиннее строку.
Мне не ясно предназначение алгоритма. "Защита от дурака"? Если да, то пойдет и такой или "open". Чего вы хотите от этого алгоритма?
res2001: защита от дурака значит, что замок не будет тратить время на то, чтобы отвечать на любую фигню которую ему послали. Для того чтобы замок принял и начал обрабатывать запрос, необходимо чтобы левая часть посылки была корректно подписана правой частью.
Ну вот. Сразу бы так. :)
Подойдет ваш алгоритм, о чем я пишу уже третий пост. Думаю, что в вашем случае особо задаваться вопросом про "возможные уязвимости" и использованием МД5 не стоит. Вряд ли "фигня" догадается по случайному числу рассчитать МД5 и запихнуть все это на вход замку.
Вот если бы речь шла действительно об аутентификации, то совсем другое дело, ваш алгоритм был бы не пригоден..
res2001: ну вот тут товарищ Армянское Радио говорит о том, что зная K1 и алгоритм (MD5) - становится довольно несложно найти SALT1, а зная SALT1 в свою очередь мы можем взломать первый шаг (т. е. начать процесс аутентификации)
В общем я хочу, что бы вы определились чего же хотите от этого алгоритма, т.к. надежная аутентификация и защита от дурака - разные вещи и требуют разных подходов и алгоритмов.
На счет МД5 - алгоритм давно взломан, есть эффективные методы поиска коллизий. Не уверен, что по хэшу и известному К1 можно найти SALT1, но я тут не особо в теме.
SHA1 так же ломается, но требуется больше вычислительных ресурсов.
Взлом хэш алгоритма заключается в нахождении коллизии на известный хэш, т.е. нахождение такого значения хэш которого будет таким же, как известный хэш. Это значение не обязательно должно совпадать с искомым паролем (поэтому и зовется коллизией). В любом хэш алгоритме есть коллизии, дело только в том на сколько долго их находить. Как правило подбор в лоб - процедура очень затратная (иначе не было бы смысла заморачиваться ни с хэшами ни с криптографией), но используя определенные особенности (уязвимости) алгоритмов можно найти способ для более быстрого нахождения коллизий. Для МД5 такой способ найден.
HMAC - это вообще не хэш алгоритм и не алгоритм криптографии, смотри википедию. Поэтому использовать MD5 или HMAC-MD5 - стойкость одинакова, такая какую выдает МД5, т.е. никакая.
На сегодня актуальны и пока не сломаны алгоритмы из состава SHA2, например SHA256 или SHA512. Можно использовать их.
И нужно отказаться от хранения постоянного общего секрета (SALT), его надо вырабатывать на лету, например по алгоритму Диффи-Хелмана, а дальше шифровать трафик каким-нибудь 3DES, AES или нашим гостом.
А если прикрутить сертификаты, то можно использовать SSL.
1. словом salt обозначают открытую случайную последовательность, нужную для борьбы с rainbow tables. Если материал секретный, то это либо ключ, либо производная от него.
2. K2 и SALT2 в вашем алгоритме не нужны совсем, поскольку никак не используются второй стороной. По сути вы отправляете с замка случайный H2 и проверяете, что ключ знает SALT3.
3. В описании нигде не видно, как ключ и замок идентифицируют сообщения как часть одного процесса аутентификации. Ну т.е. как замок получив что-то (предположительно H3) ассоциирует это с ранее отосланным H2?
1. Вы правы, Salt да не совсем верно, правильнее было бы переименовать SALTX в KEYX, а KX в NONCEX
2. K2 - это счетчик вида: 1#случайное число, 2#случайное число и т. д. ; K2 и SALT2 - нужны лишь для того чтобы скрыть детали его реализации
3. Никак не ассоциируют, здесь это не важно, только тот ключ что принял H2 может отправить корректный ответ
3 -- это зря. Если кто-то перехватил хоть раз какую-нибудь пару K1 и H1 он сможет неограниченно переходить к шагу 4. Это значит что он сможет нарушить работу нормальных ключей, заставляя замок генерировать новый H2.
Простой
Простой
Средний
Простой
