Проверка безопасности аутентифицированного варианта Диффи-Хеллмана

Question

РЕДАКТИРОВАТЬ

Я все еще надеюсь на некоторые советы по этому поводу, я попытался уточнить свои намерения ...

Когда я натолкнулся на сопряжение устройств в моей среде мобильной связи, я изучалмного статей по этой теме, а также некоторые материалы из предыдущих вопросов здесь.Но я не нашел готового для реализации протокольного решения - поэтому я изобрел дериват и, поскольку я не специалист по криптографии, я не уверен в предостережениях по безопасности окончательного решения:

Основные вопросы

• Достаточно ли SHA256 в качестве функции фиксации?
• Является ли добавление общего секрета в качестве информации аутентификации в строке фиксации безопасным?
• Что такоеобщая безопасность 1024-битной группы DH
• Я предполагаю, что не более 2 ^ -24-битной вероятности успешной атаки MITM (из-за 24-битного вызова).Это правдоподобно?
• Какая может быть самая многообещающая атака (кроме того, чтобы вырвать устройство из моих онемевших, холодных рук)

Это эскиз алгоритма

• Для сопряжения в первый раз реализовано решение, предложенное в разделе «Соглашение о ключе в одноранговых беспроводных сетях» (DH-SC).Я основал его на обязательстве, полученном из:
  • Исправление "UUID" для взаимодействующего объекта / роли (128 бит, отправляется при запуске протокола, до принятия)
  • Открытый ключ DH (192секретный ключ, основанный на 1024-битной группе Оукли)
  • 24-битный случайный вызов
• Фиксация вычисляется с использованием SHA256
  • c = sha256 (UUID || DH pub || Chall)
• Обе стороны обмениваются этим обязательством, открывают и передают простое содержание вышеуказанных значений.

    Alice                                   Bob
    ca = commit()                        
                    -------^ ca
                                            cb = commit()
                    cb ^-----------
    open
                    ---^ DH pub a, chall a
                                            open
                    DH pub b, chall b ^---

• 24-битное случайное число отображается пользователю для ручной аутентификации.

• Сеансовый ключ DH (128 байтов, см. Выше) вычисляется

• Когдапользователь выбирает постоянное соединение, сеансовый ключ сохраняется с удаленным UUID в качестве общего секрета

• При следующем подключении устройств фиксация вычисляется путем дополнительного хеширования предыдущего ключа сеанса DH перед случайнымвызов.Конечно, он не передается при открытии.

  • c = sha256 (UUID || DH pub || DH sess || Chall)

• Теперь пользователю не нужно проверять подлинность, когда локальная сторона может получить такое же обязательство, используя свой собственный, сохраненный предыдущий ключ сеанса DH.После успешного подключения новый сеансовый ключ DH становится новым общим секретом.

Поскольку это не совсем соответствует протоколам, которые я нашел до сих пор (и, таким образом, их доказательств безопасности), я быбыть очень заинтересованным, чтобы узнать мнение еще нескольких ребят с поддержкой шифрования.КСТАТИ.я читал о протоколе "EKE", но я не уверен, какой дополнительный уровень безопасности.

Answer 1

«Достаточно ли SHA256 в качестве функции фиксации?»

Использование SHA256 должно быть вполне приемлемым.Единственная проблема, о которой я слышал, заключается в том, что у нее есть уязвимость расширения хеша.Если вы создаете несколько хэшей, используя одни и те же данные, не просто объединяйте больше данных в конец уже хэшированных данных.В вашем посте есть два хэша "sha256 (UUID || DH pub || Chall)" и "sha256 (UUID || DH pub || DH sess || Chall)".Если бы этот второй был "sha256 (UUID || DH pub || Chall || DH sess)", то между значениями хеш-функции была бы связь, если бы UUID, DH pub и Chall имели те же значения, что и раньше.Вам следует либо позаботиться о том, чтобы избежать проблемы с расширением хеша, либо включить значение соли в данные, которые нужно хешировать, либо передавая соль через ссылку, либо используя разные значения для каждого пути кода.

В примечании стороны: действительно ли необходимо передавать Chall, если у вас уже сохранен предыдущий сеансовый ключ и вам не нужно просить пользователя вручную подтвердить код вызова?

"Является ли добавление общего секрета какинформация аутентификации в строке коммита safe? "

Я предполагаю, что вы хотите спросить:" Безопасно ли включать секретную информацию в хеш, который должен быть обнародован? "Если секрет является чем-то, что действительно трудно угадать, и для выполнения атаки грубой силы потребуется очень много времени, тогда да, это безопасно.Если секрет легко угадать или имеет только несколько возможных значений, то нет, это небезопасно, если только вы одновременно не включите трудно угадываемый секрет, чтобы заставить потенциального подслушивателя угадывать все такие секреты одновременно.Для большого, эффективно случайного числа, такого как общий секрет DH, это должно быть просто прекрасно.

"Какова общая безопасность 1024-битной группы DH"

Я не уверен, еслиDH group 1024 - это то, что вы хотите использовать.Обмен ключами, который считается столь же эффективным, как и алгоритм хеширования SHA256, который вы используете, будет 521-битным ECDH.Криптографическая стойкость ECDH считается равной 1/2, поэтому, если вы хотите 256-битную защиту, вы хотите 521-битную ECDH.К сожалению, я не уверен в безопасности многих отдельных 521-битных групп ECDH, которые были опубликованы.

"Я предполагаю, что не более 2 ^ -24 битов вероятность успешной атаки MITM (из-за 24-битного вызова). Это правдоподобно? "

Существует более одного способа выполнить MITM-атаку.Ева будет использовать каждый находящийся в ее распоряжении ресурс для выполнения своих атак, и если вы не будете осторожны, она будет использовать то, о чем вы даже не подумали.Вот почему рецензирование необходимо в криптографии.

Answer 2

Проще говоря, если вы делаете свое собственное криптографическое решение, то оно слабое.

Для небольшой истории ребята из VISA должны начать снова 4 раза, прежде чем оно станет достаточно сильным.

IЯ не эксперт по безопасности, но это то, что мой криптоучитель говорил нам каждый раз.

Answer 3

Я придумала эту возможную атаку, основываясь на моем понимании протокола, вдохновленного Атакой Лоу на протокол открытого ключа Нидхэма-Шредера :

• Алиса хочет восстановить соединение. Рассчитывает свое обязательство ca и отправляет Бобу. Сообщение захвачено Мэллори.
• Мэллори отвечает. Она не знает общего секрета, поэтому она придумывает один. Вычисляет cb и отправляет Алисе.
• На этом этапе Алиса еще не может проверить общий секрет. Поэтому она отправляет DHpubA и ChallA.
• Мэллори игнорирует сообщения Алисы и исчезает.

Теперь у Мэллори есть действительный DHpubA, ChallA и соответствующий (действительный) ок.

• Мэллори посылает СА Бобу.
• Боб отвечает cb.
• Мэллори отправляет действительный набор DhpubA, ChallA
• Боб отправляет свой DhpubB и ChallB

Поскольку Боб может проверять сообщения Мэллори, она аутентифицируется как Алиса. Очевидно, что Мэллори не знает DHprivA, так как она не может вычислить текущий ключ сеанса, но, тем не менее, у вас есть недостаток безопасности, так как Боб думает, что он разговаривает с Алисой.

Общие рекомендации : избегайте внедрения собственного криптографического решения и не доверяйте проверкам безопасности кому-либо, кроме признанной охранной фирмы.

Если вы чувствуете, что стандартные требования криптографии не удовлетворяют вашим требованиям безопасности, попробуйте указать свои требования и спросить, существует ли протокол безопасности, соответствующий им.

Answer 4

Звучит нормально.Не уверены, что вы имели в виду под «fix [ed] UUID»?Может ли мошенническое приложение получить доступ к UUID и ключам сеанса: они хранятся в масштабе всей системы или в службе?В SDK есть текст, который предполагает, что любое хранилище ключей всегда ожидает подтверждения пользователя перед возвратом ключа.