Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
Аутентифмкация и выработка сеансового ключа для симетричного... 23.03.04 12:18 Число просмотров: 1709
Автор: 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) Также клиенту можнобудет отправлять старые ключи, прехватив новый - установлденно неверное соединение. Такого быть не должно, то есть в конце этого взаимодействия аутентификация и все необходимые данные для защищенного соединения должны быть переданы.
|
|
|
подробно о проекте
Анализ криптографических сетевых...
