> Так понял, что преимуществ этого протокола в том, что > клиент тоже причастен к вычислению секретного ключа. Почему > в этом случае не подходит, скажем, обмен по > Diffie-Hellman'у вместо key1 и key2? Есть ли преимущество Не знаю ;) В исходном предложении DH не использовался, я так понял, что есть сображения какие-то...
> от того, что на третьем шаге уже используется сеансовый ключ? Вычислительно проще юзать симметричную крипту
Хотелось бы узнать Ваше мнение о следующем протоколе. Протокол рассматривается как временная быстрореализуемая альтернатива IKE. Перед началом обмена обоим сторонам известны открытые ключи RSA друг друга. Результат - выработка разделяемого секретного ключа и идентификатора (SID) последующего соединения.
> альтернатива IKE. Перед началом обмена обоим сторонам > известны открытые ключи RSA друг друга. Результат - Если ониужеизвестны, зачем шифровать на открытых ключах?
> выработка разделяемого секретного ключа и идентификатора > (SID) последующего соединения. > > Step 1. Client --> Server > Esr_pub_key [ Rc ] Посылаем метку времени клиента, зашифрованную на открытом ключе сервера? И зачем она серверу?
> Step 2. Server --> Client > Ecl_pub_key [ SID, SK, Rs, Rc ] Шлем клиенту идентификатор и сеансовый ключ, зашифрованные на открытом ключе клиента. В принципе, этого уже достаточно для работы. Зачем сюда еще добавлять метку времени сервера и возвращать метку клиента?
> Step 3. Client --> Server > Esr_pub_key [ HASH[SID, SK, Rs] ] А этот шаг вообще непонятно зачем
Какова область применения данного протокола?
Я понимаю так, что открытый ключ сервера известен всем. ТОгда на первом шаге клиент шлет свой ID, зашифрованный на открытом ключе сервера (идентификация). Сервер расшифровывает ID, по нему находит в своей базе открытый ключ клиента, вырабатывает сеансовый ключ и шлет его клиенту в зашифрованном на открытом ключе клиента виде.
Если клиент тот, за кого себя выдает, он может расшифровать посылку и дальше гнать данные на сеансовом ключе, т.е. аутентификация идет автоматически.
Аутентифмкация и выработка сеансового ключа для симетричного...23.03.04 12:18 Автор: lunc <Alexander Krizhanovsky> Статус: Member
> > альтернатива IKE. Перед началом обмена обоим сторонам > > известны открытые ключи RSA друг друга. Результат - > Если ониужеизвестны, зачем шифровать на открытых > ключах?
Аутентифмкация и выработка сеансового ключа для симетричного шифрования.
> > выработка разделяемого секретного ключа и > идентификатора > > (SID) последующего соединения. > > > > Step 1. Client --> Server > > Esr_pub_key [ Rc ] > Посылаем метку времени клиента, зашифрованную на открытом > ключе сервера? И зачем она серверу?
Временные штампы предотвращают повтор сообщений.
> > Step 2. Server --> Client > > Ecl_pub_key [ SID, SK, Rs, Rc ] > Шлем клиенту идентификатор и сеансовый ключ, зашифрованные > на открытом ключе клиента. В принципе, этого уже достаточно > для работы. Зачем сюда еще добавлять метку времени сервера > и возвращать метку клиента?
Так клиент убеждается в подлинности сервера, что тот получил первое сообщение и может его расшифровать.
> > Step 3. Client --> Server > > Esr_pub_key [ HASH[SID, SK, Rs] ] > А этот шаг вообще непонятно зачем
Этот шаг для подтверждения того, что клиент получил правильные SID и SK.
Аутентификация клиента.
> Какова область применения данного протокола?
Аутентификация и выроботка секретного ключа для последующего IPSec-соединения. Применяться это все будет в VPN. Этот протокол просто как временная бысрореализуемая альтернатива IKE Pre-shared keys. Понятия клиент и сервер здесь понимаются из последовательности запросов (кто первый запрашивает соединение). На самом деле это две полностью равноправные точки.
> Я понимаю так, что открытый ключ сервера известен всем. > ТОгда на первом шаге клиент шлет свой ID, зашифрованный на > открытом ключе сервера (идентификация). Сервер > расшифровывает ID, по нему находит в своей базе открытый > ключ клиента, вырабатывает сеансовый ключ и шлет его > клиенту в зашифрованном на открытом ключе клиента виде. > Если клиент тот, за кого себя выдает, он может расшифровать > посылку и дальше гнать данные на сеансовом ключе, т.е. > аутентификация идет автоматически.
Думаю, здесь есть два недостатка.
1) Один раз перехватив зашифрованный ID клиента можно будет создавать большое колличесво соединений, закрывающихся по тайм-ауту. Но все же не хотелось бы - проверка временного штампа занимает меньше времени, чем тайм-аут. В ID нет необходимости - при инициализации процесса аутентификации ему передается параметром открытый ключ клиента.
2) Также клиенту можнобудет отправлять старые ключи, прехватив новый - установлденно неверное соединение. Такого быть не должно, то есть в конце этого взаимодействия аутентификация и все необходимые данные для защищенного соединения должны быть переданы.
> > Если ониужеизвестны, зачем шифровать на открытых > > ключах? > > Аутентифмкация и выработка сеансового ключа для > симетричного шифрования. ;) Ну общая-то цель понятна...
Я имел ввиду, если перед началом соединения ключи уже известны, то можно просто по Диффи-Хеллмену посчитать общий секрет, зашифровать на нем случайно сгенеренный сеансовый ключ (ну, плюс метку времени, с учетом перечисленных тобой угроз), получить от другой стороны аналогичную посылку и канал готов. Но раз тут набор из большого количества точек, а не звезда, то это не пойдет.
> > Посылаем метку времени клиента, зашифрованную на > открытом > > ключе сервера? И зачем она серверу? > > Временные штампы предотвращают повтор сообщений. Т.е. в роли случайного числа. Ок.
> > для работы. Зачем сюда еще добавлять метку времени > сервера > > и возвращать метку клиента? > > Так клиент убеждается в подлинности сервера, что тот > получил первое сообщение и может его расшифровать. Ок
> > > Step 3. Client --> Server > > > Esr_pub_key [ HASH[SID, SK, Rs] ] > > А этот шаг вообще непонятно зачем > > Этот шаг для подтверждения того, что клиент получил > правильные SID и SK. ИМХО - лишнее. Если он получил их неправильными, то после расшифрования потока от него бред получится. Хотя, одна посылка - не принципиально...
> запрашивает соединение). На самом деле это две полностью > равноправные точки. ПРинципиальный момент...
> Думаю, здесь есть два недостатка. > 1) Один раз перехватив зашифрованный ID клиента можно будет > создавать большое колличесво соединений, закрывающихся по Согласен, без тайм-штампа - никак.
> 2) Также клиенту можнобудет отправлять старые ключи, > прехватив новый - установлденно неверное соединение. Такого А цель? DoS? Так ее и в предлагаемой схеме можно устроить, если исходить из того, что злоумышленник может подменять сообщения в канале. КЛиент будет отвечать хешем с непарвильным SID,SK, и тот же результат: "установлденно неверное соединение"
Может так:
"инициатор соединения" - Клиент
"принимающий соединение" - Сервер
E,pkserv - шифрование на открытом ключе сервера
E,pkclient - шифрование на открытом ключе клиента
E,K - шифроание на общем секретном ключе
> > > > Step 3. Client --> Server > > > > Esr_pub_key [ HASH[SID, SK, Rs] ] > > > А этот шаг вообще непонятно зачем > > > > Этот шаг для подтверждения того, что клиент получил > > правильные SID и SK. > ИМХО - лишнее. Если он получил их неправильными, то после > расшифрования потока от него бред получится. Хотя, одна > посылка - не принципиально.. >
> > 2) Также клиенту можнобудет отправлять старые ключи, > > прехватив новый - установлденно неверное соединение. > Такого > А цель? DoS? Так ее и в предлагаемой схеме можно устроить, > если исходить из того, что злоумышленник может подменять > сообщения в канале. КЛиент будет отвечать хешем с > непарвильным SID,SK, и тот же результат: "установлденно > неверное соединение"
Цель здесь такая. Есть модуль (машина конечных сосотояний) для установки соединения (установка будущих контекстов безопасности) и есть другая машина конечных состояний - сам простокол защищенного соединение (IPSec, например). Результат работы первой не должен влиять на работу второй (изолированность). То есть в конце обмена должно быть принято решение о том принять соединение или разорвать. При получениие сервером шифрованного хеша он разрывает связ, клиент - сам виноват :) С другой стороны клиент мог получить неверные параметры - это похоже на проблемму трех армий....
Так понял, что преимуществ этого протокола в том, что клиент тоже причастен к вычислению секретного ключа. Почему в этом случае не подходит, скажем, обмен по Diffie-Hellman'у вместо key1 и key2? Есть ли преимущество от того, что на третьем шаге уже используется сеансовый ключ?
Не знаю ;) В исходном предложении DH не использовался, я так...25.03.04 13:39 Автор: cybervlad <cybervlad> Статус: Elderman
> Так понял, что преимуществ этого протокола в том, что > клиент тоже причастен к вычислению секретного ключа. Почему > в этом случае не подходит, скажем, обмен по > Diffie-Hellman'у вместо key1 и key2? Есть ли преимущество Не знаю ;) В исходном предложении DH не использовался, я так понял, что есть сображения какие-то...
> от того, что на третьем шаге уже используется сеансовый ключ? Вычислительно проще юзать симметричную крипту
Спасибо!26.03.04 13:15 Автор: lunc <Alexander Krizhanovsky> Статус: Member
подробно о проекте
Анализ криптографических сетевых...
новое сообщение
закрытая нитка
новое сообщение
в закрытой нитке
старое сообщение
