Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
| |
Аутентифмкация и выработка сеансового ключа для симетричного... 23.03.04 12:18 Число просмотров: 1710
Автор: 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) Также клиенту можнобудет отправлять старые ключи, прехватив новый - установлденно неверное соединение. Такого быть не должно, то есть в конце этого взаимодействия аутентификация и все необходимые данные для защищенного соединения должны быть переданы.
|
|
<theory>
|
Протокол аутентификации: Ваше мнение 22.03.04 20:44
Автор: 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] ]
Rc, Rs - Клиентский и серверный временные штампы.
HASH - хэш.
SK - Симетричный ключ для последующего защищенного соединения.
Esr_pub_key, Ecl_pub_key - функции шифрования RSA открытыми ключамми сервера и клиента соответственно.
|
|
Если они _уже_ известны, зачем шифровать на открытых... 23.03.04 11:43
Автор: cybervlad <cybervlad> Статус: Elderman
|
> альтернатива 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) Также клиенту можнобудет отправлять старые ключи, прехватив новый - установлденно неверное соединение. Такого быть не должно, то есть в конце этого взаимодействия аутентификация и все необходимые данные для защищенного соединения должны быть переданы.
|
| | |
;) Ну общая-то цель понятна...
24.03.04 16:38
Автор: cybervlad <cybervlad> Статус: Elderman
|
> > Если ониужеизвестны, зачем шифровать на открытых
> > ключах?
>
> Аутентифмкация и выработка сеансового ключа для
> симетричного шифрования.
;) Ну общая-то цель понятна...
Я имел ввиду, если перед началом соединения ключи уже известны, то можно просто по Диффи-Хеллмену посчитать общий секрет, зашифровать на нем случайно сгенеренный сеансовый ключ (ну, плюс метку времени, с учетом перечисленных тобой угроз), получить от другой стороны аналогичную посылку и канал готов. Но раз тут набор из большого количества точек, а не звезда, то это не пойдет.
> > Посылаем метку времени клиента, зашифрованную на
> открытом
> > ключе сервера? И зачем она серверу?
>
> Временные штампы предотвращают повтор сообщений.
Т.е. в роли случайного числа. Ок.
> > для работы. Зачем сюда еще добавлять метку времени
> сервера
> > и возвращать метку клиента?
>
> Так клиент убеждается в подлинности сервера, что тот
> получил первое сообщение и может его расшифровать.
Ок
> > > 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 - шифроание на общем секретном ключе
Клиент:
посылает E,pkserv(time1,key1)
Сервер:
посылает E,pkclient(time2,key2,time1)
вычисляет K=key1 xor key2
Клиент:
проверяет time1
вычисляет K=key1 xor key2
посылает E,K(time2)
Сервер:
проверяет time2
По шагам одинаково, ибо хендшейк все равно, меньше чем за 3 не сделать...
|
| | | |
;) Ну общая-то цель понятна... 24.03.04 17:30
Автор: lunc <Alexander Krizhanovsky> Статус: Member
Отредактировано 24.03.04 17:34 Количество правок: 1
|
Большое спасибо за помощ.
> > > > Step 3. Client --> Server
> > > > Esr_pub_key [ HASH[SID, SK, Rs] ]
> > > А этот шаг вообще непонятно зачем
> >
> > Этот шаг для подтверждения того, что клиент получил
> > правильные SID и SK.
> ИМХО - лишнее. Если он получил их неправильными, то после
> расшифрования потока от него бред получится. Хотя, одна
> посылка - не принципиально..
>
> > 2) Также клиенту можнобудет отправлять старые ключи,
> > прехватив новый - установлденно неверное соединение.
> Такого
> А цель? DoS? Так ее и в предлагаемой схеме можно устроить,
> если исходить из того, что злоумышленник может подменять
> сообщения в канале. КЛиент будет отвечать хешем с
> непарвильным SID,SK, и тот же результат: "установлденно
> неверное соединение"
Цель здесь такая. Есть модуль (машина конечных сосотояний) для установки соединения (установка будущих контекстов безопасности) и есть другая машина конечных состояний - сам простокол защищенного соединение (IPSec, например). Результат работы первой не должен влиять на работу второй (изолированность). То есть в конце обмена должно быть принято решение о том принять соединение или разорвать. При получениие сервером шифрованного хеша он разрывает связ, клиент - сам виноват :) С другой стороны клиент мог получить неверные параметры - это похоже на проблемму трех армий....
>
> Может так:
> "инициатор соединения" - Клиент
> "принимающий соединение" - Сервер
> E,pkserv - шифрование на открытом ключе сервера
> E,pkclient - шифрование на открытом ключе клиента
> E,K - шифроание на общем секретном ключе
>
> Клиент:
> посылает E,pkserv(time1,key1)
>
> Сервер:
> посылает E,pkclient(time2,key2,time1)
> вычисляет K=key1 xor key2
>
> Клиент:
> проверяет time1
> вычисляет K=key1 xor key2
> посылает E,K(time2)
Так понял, что преимуществ этого протокола в том, что клиент тоже причастен к вычислению секретного ключа. Почему в этом случае не подходит, скажем, обмен по 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
|
|
|
|
|
подробно о проекте
Анализ криптографических сетевых...
