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

1.Запрос на ввод идентификатора со стороны системы защиты.
2.Ввод пользователем своего идентификатора (имени) NAME.
3.Запрос на ввод пароля со стороны системы защиты.
4.Ввод пользователем пароля P.
5.Вычисление системой защиты значения односторонней функции y = F(x), соответствующей значению аргумента x = P.
6.Сравнение системой защиты значения F(P) со значением образа S пароля, соответствующего пользователю с идентификатором NAME.
7.Если F(P) = S, то система защиты предоставляет пользователю права доступа, соответствующие идентификатору NAME. В противном случае в журнале регистрируется информация о попытке несанкционированного доступа.

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

Идентификация удаленных рабочих станций может быть выполнена по следующей схеме, основанной на использовании алгоритма шифрования Еk и общего секретного ключа k для удаленных станций A и B (одна из них, к примеру, в вашей постановке задачи - сервер):

Алгоритм идентификации удаленных рабочих станций
1.Станция А посылает запрос на соединение со станцией В.
2.Станция В посылает А случайное число R.
3.Станция А зашифровывает R по секретному ключу k, получая шифртекст Ca = Еk (R, k), и направляет станции В значение Са.
4.Станция В вычисляет Сb = ЕК (R, K) и сравнивает значения Cb и Ca. Если они равны, то принимается решение, что запрос на установление сеанса связи отправлен станцией А, иначе связь прерывается.

Еще могу привести порядок использования систем с симметричными ключами:
1.Безопасно создается, распространяется и сохраняется симметричный секретный ключ.
2.Отправитель создает электронную подпись с помощью расчета хэш-функции для текста и присоединяет ее к тексту.
3.Отправитель использует симметричный алгоритм шифрования/дешифрования вместе с секретным симметричным ключом к полученному пакету (тексту с присоединенной электронной подписью) для получения шифртекста. Таким образом, неявно производится аутентификация, так как только отправитель знает симметричный секретный ключ. Только получатель знает симметричный секретный ключ и может расшифровать этот пакет.
4.Отправитель передает шифртекст. Симметричный секретный ключ никогда не передается по незащищенным каналам связи.
5.Получатель использует тот же самый симметричный алгоритм шифрования/дешифрования вместе с тем же самым симметричным ключом для восстановления исходного текста и электронной подписи. Его успешное восстановление аутентифицирует кого-то, кто знает секретный ключ (иными словами отправителя).
6.Получатель отделяет электронную подпись от текста.
7.Получатель создает другую электронную подпись с помощью расчета хэш-функции для полученного текста.
8.Получатель сравнивает две этих электронных подписи для проверки целостности сообщения (отсутствия его искажения).

P/S/ Здесь в Ek k - это нижний индекс. В других обозначениях также. Очень сложно формулы тут писать
P/S/S/ Речь шла об использовании симметрии. При асимметричной криптографии все гораздо легче Вернее при правильном использоании и того, и другого

Добавлено (27.04.2008, 13:53)
---------------------------------------------
Кста, вопросик,

да, есть инструкции на эту тему, но я не уверен, что именно шифровать ее надо. Достаточно, по-моему, защищенного канала. Или пакеты все-таки передаваемые шифровать надо? Надо будет у В.А. спросить, что имел ввиду.

VPN то это ясно понятно! Своя подстеть в тунеле основной - это бесспорно круто. Можно еще и его, как доп. защиту нацепить.

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

А так поставил снифер, и с таким же "прозрачным" успехом ловишь нешифрованную инфу! Вот в чем трабла! ИНСАЙДЕРЫ - ГЛАВНАЯ УГРОЗА!

-----------------

Кстати, у нас же не однократно кто-то говорил про создание VPN'a для текущего Контингента .. но по каким-то причинам так и не ввели .. И вариант установки на Сервер Терминалов тоже "сдулся" ..

Подожди пару месяцев, к сентябрю, если лето будет творческое, выплюну новую версию Контингента, дам покрячить

Ну чтож, жду твой Контингент на своем операционном столе

Плохо. Очень плохо. Надо что-то делать...

P/S/ Сори, за оффтоп, но проблема действительно серьезная, и спасибо vitalyu и eXceed, что они поднимают эту проблему.

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

P.S. уже оффтоп идет .. тема то не так называлась ..

Добавлено (28.04.2008, 23:28)
---------------------------------------------
Форум просматривают: vitalyu, eXceed