Comments 11
Можно ли SESPAKE сделать augmented (как этот термин употребляют в зарубежной литературе): то есть только одна сторона знает значение низкоэнтропийного ключа (пароля), а вторая нет, но может проверить его знание? Какие особенности и камни предкновения для создания augmented протоколов вы могли бы отметить? Насколько приемлимо было бы вместо низкоэнтропийного использовать его усиленную версию (PBKDF2, Argon2, ...)? Но здесь вроде возникает существенное усложнение в виде того что сначала надо передать идентификатор по которому сервер найдёт соль, потом передать эту соль клиенту и только после этого клиент сможет «воссоздать» усиленную версию.
Чтобы прийти к общему знаменателю, я немного расширенно опишу, что такое 'augmented' для протоколов семейства PAKE. Суть augmented не в том, что сторона, пусть B, не знает пароль (в SESPAKE сторона B, строго говоря, тоже не знает пароль), а в том, что если противник взламывает B, то есть получает хранящееся там значение, то он не может с помощью этого значения аутентифицироваться на B от имени A.
В SESPAKE это условие не выполняется — противник просто пропустит этап вычисления Q_PW^A, а будет использовать значение Q_PW, полученное при взломе B (хотя, если противнику нужно аутентифицироваться с использование именно заданного интерфейса, например, терминала, то ему все-таки придется вынуть пароль PW из Q_PW^A). Поэтому, как Вы правильно заметили, SESPAKE в строгом смысле не является augmented. В некотором смысле его можно назвать nearly-augmented.
Примером augmented-протокола является протокол AugPAKE, который наряду с SESPAKE рассматривается в группе CFRG. В нем сторона B хранит g^PW, а стороне A необходимо знание именно PW для аутентификации на B. Поэтому, если противник узнает g^PW, вскрыв сервер, то он не сможет аутентифицироваться на B, т.к. для этого нужно знать строго именно PW.
Казалось бы, замечательное свойство, почему бы не делать все протоколы augmented?! Если вдуматься, то дополнительная защита, которую дает augmented, именно в случае протоколов семейства PAKE крайне слаба. Изначальный посыл PAKE протоколов состоит в том, что общий секрет малоэнтропийный, т.е. его легко перебрать. Поэтому в таких условиях кажется странным говорить о том, что в случае взлома стороны B и выведывания g^PW, противник не получает PW — он его просто подберет, что он может сделать, т.к. мы находимся в условиях PAKE-протокола. Поэтому в случае, например, AugPAKE данное свойство реально что-то дает, если после взлома сервера противнику необходимо немедленно на него аутентифицироваться — в этом случае у него просто не будет времени на перебор. Однако такой случай выглядит странно и не очевидно, что стоит создавать что-то специальное для того, чтобы обеспечить защиту в таком случае.
При спорных плюсах свойство augmented имеет следующие недостатки, которые покажем на примере AugPAKE:
1) Стороны A и B не симметричны — действия A и B существенно отличаются, что может стать негативным фактором при реализации.
2) AugPAKE требует большего количества вычислений на кривой, чем SESPAKE, именно из-за поддержки augmented. Если B — карточка, то трудоемкость действий B крайне важна.
Ответ на вопрос, можно ли добавить в SESPAKE свойство augmented, таков: 'добавить' augmented нельзя, т.к. нужно будет существенно менять протокол в той части, где вырабатывается ключ. То есть это будет уже не 'добавить', а 'сделать новый'.
По поводу использования усилений. В SESPAKE они уже используются — обратите внимание на то, что сторона A использует не сам PW, а F(PW,salt,2000). На самом деле, F — это и есть PBKDF2. salt передается от B к A именно так, как Вы написали. Нет никаких проблем в использовании не явно PW, а какой-то функции от PW. Однако это имеет какой-то смысл лишь в случае, когда необходимо учитывать угрозу взлома сервера. В этом случае 2000 итераций, заложенных в PBKDF2, позволят несколько усложнить противнику перебор. Использование salt защищает от методов типа rainbow-table, но не увеличивает перебор экспоненциально, т.к. salt известен противнику.
В SESPAKE это условие не выполняется — противник просто пропустит этап вычисления Q_PW^A, а будет использовать значение Q_PW, полученное при взломе B (хотя, если противнику нужно аутентифицироваться с использование именно заданного интерфейса, например, терминала, то ему все-таки придется вынуть пароль PW из Q_PW^A). Поэтому, как Вы правильно заметили, SESPAKE в строгом смысле не является augmented. В некотором смысле его можно назвать nearly-augmented.
Примером augmented-протокола является протокол AugPAKE, который наряду с SESPAKE рассматривается в группе CFRG. В нем сторона B хранит g^PW, а стороне A необходимо знание именно PW для аутентификации на B. Поэтому, если противник узнает g^PW, вскрыв сервер, то он не сможет аутентифицироваться на B, т.к. для этого нужно знать строго именно PW.
Казалось бы, замечательное свойство, почему бы не делать все протоколы augmented?! Если вдуматься, то дополнительная защита, которую дает augmented, именно в случае протоколов семейства PAKE крайне слаба. Изначальный посыл PAKE протоколов состоит в том, что общий секрет малоэнтропийный, т.е. его легко перебрать. Поэтому в таких условиях кажется странным говорить о том, что в случае взлома стороны B и выведывания g^PW, противник не получает PW — он его просто подберет, что он может сделать, т.к. мы находимся в условиях PAKE-протокола. Поэтому в случае, например, AugPAKE данное свойство реально что-то дает, если после взлома сервера противнику необходимо немедленно на него аутентифицироваться — в этом случае у него просто не будет времени на перебор. Однако такой случай выглядит странно и не очевидно, что стоит создавать что-то специальное для того, чтобы обеспечить защиту в таком случае.
При спорных плюсах свойство augmented имеет следующие недостатки, которые покажем на примере AugPAKE:
1) Стороны A и B не симметричны — действия A и B существенно отличаются, что может стать негативным фактором при реализации.
2) AugPAKE требует большего количества вычислений на кривой, чем SESPAKE, именно из-за поддержки augmented. Если B — карточка, то трудоемкость действий B крайне важна.
Ответ на вопрос, можно ли добавить в SESPAKE свойство augmented, таков: 'добавить' augmented нельзя, т.к. нужно будет существенно менять протокол в той части, где вырабатывается ключ. То есть это будет уже не 'добавить', а 'сделать новый'.
По поводу использования усилений. В SESPAKE они уже используются — обратите внимание на то, что сторона A использует не сам PW, а F(PW,salt,2000). На самом деле, F — это и есть PBKDF2. salt передается от B к A именно так, как Вы написали. Нет никаких проблем в использовании не явно PW, а какой-то функции от PW. Однако это имеет какой-то смысл лишь в случае, когда необходимо учитывать угрозу взлома сервера. В этом случае 2000 итераций, заложенных в PBKDF2, позволят несколько усложнить противнику перебор. Использование salt защищает от методов типа rainbow-table, но не увеличивает перебор экспоненциально, т.к. salt известен противнику.
Спасибо за объяснение. Вначале пробежал глазами и не увидел что пароль уже усиливается. Да, собственно под «добавить augmented» я и подразумевал вопрос: не будете ли вы делать и стандартизировать augmented версию (понимаю что фактически это всё-равно другой протокол уже будет)? Или у вас (и у других) нет пока потребностей в подобной версии (у которой безусловно есть и сложности и минусы и не столь очевидные вектора атаки от которых защищают)?
Прошу прощения за такую задержку с ответом. Вы правы, для добавления augmented нужно будет существенно менять этап выработки ключа — это будет уже другой протокол (учитывая изменения в этапе выработки, этап подтверждения также изменится, т.к. под HMAC нужно будет засовывать другие данные). Пока в разработке такого протокола потребности нет.
Я вот заметил, что проблемы «прототипа» протокола PAKE, описанные в статье, связаны с тем, что для маскирования открытого ключа DH паролем используется простое умножение по модулю.
А что если не умножать открытый ключ DH на хеш пароля, а шифровать симметричным блочным шифром? Будем передавать не g^a*H(pw), а E(g^a, H(pw)), где E(x,y) — блочный шифр над данными x с ключом y. Тогда не нужно заботиться о разных порождающих элементах с неизвестным дискретным логарифмом. Протоколы на этой основе называются EKE (Encrypted key exchange). Поправьте, если ошибаюсь. Есть ли в этой схеме еще какие-нибудь подводные камни, позволяющие проводить оффлайн-атаку на пароль?
А что если не умножать открытый ключ DH на хеш пароля, а шифровать симметричным блочным шифром? Будем передавать не g^a*H(pw), а E(g^a, H(pw)), где E(x,y) — блочный шифр над данными x с ключом y. Тогда не нужно заботиться о разных порождающих элементах с неизвестным дискретным логарифмом. Протоколы на этой основе называются EKE (Encrypted key exchange). Поправьте, если ошибаюсь. Есть ли в этой схеме еще какие-нибудь подводные камни, позволяющие проводить оффлайн-атаку на пароль?
Здравствуйте!
Спасибо большое за очень дельный комментарий! О возможности шифровать элементы группы мы написать хотели, но, признаться, не хватило времени.
С шифрованием g^a есть важная проблема. Если вы возьмете «боевую» используемую для практике группу – группу точек эллиптической кривой – то каждый элемент (точка кривой) будет иметь вид (x,y), где x и y связаны уравнением кривой. Если вы зашифруете данную точку на ключе, выведенном из пароля, то возможно будет, перебирая пароли оффлайн, найти те, для которых результат расшифрования является корректной точкой кривой. Если не вводить дополнительной компрессии (писать x и один бит, соответствующий «знаку» y, что возможно для ряда кривых), то пароль по E(g^a) можно будет за одно наблюдение восстановить мгновенно и однозначно. Если применять, то критерии для отбраковки все равно останутся (пусть и более слабые) и по наблюдению за одной пересылкой (в каждой сессии протокола их будет минимум две) можно будет получать отбраковку части парольного множества. 10-15 наблюдений за протоколом – и пароль угадан.
Поэтому в случае шифрования будет принципиально важно использование высокоэнтропийных секретов, а не паролей, а в нашем случае как раз приходится «замешивать» пароль в той же группе, что и основные преобразования.
Ответил кратко, так что если получилось не вполне ясно, буду рад внести любые пояснения и уточнения.
Спасибо большое за очень дельный комментарий! О возможности шифровать элементы группы мы написать хотели, но, признаться, не хватило времени.
С шифрованием g^a есть важная проблема. Если вы возьмете «боевую» используемую для практике группу – группу точек эллиптической кривой – то каждый элемент (точка кривой) будет иметь вид (x,y), где x и y связаны уравнением кривой. Если вы зашифруете данную точку на ключе, выведенном из пароля, то возможно будет, перебирая пароли оффлайн, найти те, для которых результат расшифрования является корректной точкой кривой. Если не вводить дополнительной компрессии (писать x и один бит, соответствующий «знаку» y, что возможно для ряда кривых), то пароль по E(g^a) можно будет за одно наблюдение восстановить мгновенно и однозначно. Если применять, то критерии для отбраковки все равно останутся (пусть и более слабые) и по наблюдению за одной пересылкой (в каждой сессии протокола их будет минимум две) можно будет получать отбраковку части парольного множества. 10-15 наблюдений за протоколом – и пароль угадан.
Поэтому в случае шифрования будет принципиально важно использование высокоэнтропийных секретов, а не паролей, а в нашем случае как раз приходится «замешивать» пароль в той же группе, что и основные преобразования.
Ответил кратко, так что если получилось не вполне ясно, буду рад внести любые пояснения и уточнения.
Спасибо актуальная статья, еше бы математические выкладки подкреплять псевдокодом, а то за годы борьбы мозг атрофировался и уже с трудом переводит вольную математическую вязь в стройную алгоритмическую форму.
Здравствуйте!
Спасибо большое за комментарий, в будущих статьях постараемся. Что же касается текущей – если интересен псевдокод/код по самому SESPAKE, Вам всегда помогут авторы документа ТК26/драфта RFC — адреса указаны в драфте.
Спасибо большое за комментарий, в будущих статьях постараемся. Что же касается текущей – если интересен псевдокод/код по самому SESPAKE, Вам всегда помогут авторы документа ТК26/драфта RFC — адреса указаны в драфте.
Закладки для ФСБ в этом чудо-протоколе не забыли сделать?
Добрый день!
Конечно, аргументированно ответить на подобные обвинения и обосновать, что «не верблюд», невозможно, но повторимся, что обоснования стойкости в статье по ссылке приводятся в абсолютном случае, без дополнительных предположений (которые можно было бы истолковать как «если нет закладок»).
Из конкретики – предлагаю Вам обратить внимание на часть данной заметки, посвященную важности выбора порождающих элементов с заведомо неизвестными друг относительно друга логарифмами. Более удобного и правильного места для внедрения закладок, чем формирование элемента h с известным дискретным логарифмом, в протоколе нет – в этом случае как раз только авторы разработки смогли бы получать (при некоторых моделях нарушителя) доступ к ключу, что было бы весьма правильной «закладкой». Мы специально останавливаемся на этом месте (а в документе ТК 26 и в драфте RFC отдельно приводятся прообразы хэшей порождающих элементов), так как подобные Вашему намеки о возможных закладках, увы, были ожидаемы.
Конечно, аргументированно ответить на подобные обвинения и обосновать, что «не верблюд», невозможно, но повторимся, что обоснования стойкости в статье по ссылке приводятся в абсолютном случае, без дополнительных предположений (которые можно было бы истолковать как «если нет закладок»).
Из конкретики – предлагаю Вам обратить внимание на часть данной заметки, посвященную важности выбора порождающих элементов с заведомо неизвестными друг относительно друга логарифмами. Более удобного и правильного места для внедрения закладок, чем формирование элемента h с известным дискретным логарифмом, в протоколе нет – в этом случае как раз только авторы разработки смогли бы получать (при некоторых моделях нарушителя) доступ к ключу, что было бы весьма правильной «закладкой». Мы специально останавливаемся на этом месте (а в документе ТК 26 и в драфте RFC отдельно приводятся прообразы хэшей порождающих элементов), так как подобные Вашему намеки о возможных закладках, увы, были ожидаемы.
Sign up to leave a comment.
О выработке неперебираемых ключей на основе перебираемых паролей