Читайте также:

  1. В какой срок в общем случае должен быть составлен акт выездной налоговой проверки?
  2. Вопросы для проверки знаний.
  3. Вопросы для проверки знаний.
  4. Вопросы для проверки знаний.
  5. Вопросы для проверки знаний.
  6. Вопросы для проверки знаний.
  7. Вопросы для проверки знаний.
  8. Вопросы для проверки знаний.
  9. Вопросы для самопроверки
  10. Вопросы для самопроверки
  11. Вопросы для самопроверки
  12. Вопросы для самопроверки

Алисе нужно связаться с Бобом. Сначала она извлекает из базы данных последовательность сертификации от Алисы до Боба и открытый ключ Боба. В этот момент Алиса может инициировать однопроходный, двухпроходный или трехпроходный протокол проверки подлинности.

Однопроходный протокол представляет собой простую передачу данных Бобу Алисой. Протокол устанавливает личности и Алисы, и Боба, а также целостность информации, передаваемой Бобу Алисой. Кроме того, он обеспечивает защиту от вскрытия линии связи с помощью повтора.

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

И в однопроходных, и в двухпроходных алгоритмах используются метки времени. В трехпроходном протоколе добавляется еще одно сообщение Алисы Бобу и позволяет избежать меток времени (и, следовательно, правильного единого времени).

1. Алиса генерирует случайное число RA.

2. Алиса создает сообщение, M = (TA, RA, IB, d), где TA — метка времени Алисы, IB — идентификатор Боба, d — произвольные данные. Для безопасности данные могут быть зашифрованы открытым ключом Боба EB.

3. Алиса посылает Бобу (CA, DA(M)). (CA — это сертификат Алисы, DA — это общий узел дерева сертификации.)

4. Боб проверяет CA и получает EA. Он проверяет, что срок действия этих ключей еще не истек. (EA — это открытый ключ Алисы.)

5. Боб использует EA для дешифрирования DA(M). Этим действием он проверяет и подпись Алисы, и целостность подписанной информации.

6. Боб для точности проверяет IB в M.

7. Боб проверяет TA в M и убеждается, что сообщение является текущим.

8. Дополнительно Боб может проверить RA в M по базе данных старых номеров, чтобы убедиться, что сообщение не является повторяемым старым сообщением.

Двухпроходный протокол состоит из однопроходного протокола и последующего аналогичного однопроходного протокола от Боба к Алисе. После выполнения этапов (1)-(8) однопроходного протокола двухпроходный протокол продолжается следующим образом:

9. Боб генерирует случайное число RB.

10. Боб создает сообщение M’ = (TB, RB, IA, RA, d), где TB — метка времени Боба, IA — идентификатор Алисы, а d — произвольные данные. Для безопасности данные могут быть зашифрованы открытым ключом Алисы EА. RA — случайное число Алисы, созданное на этапе (1).

11. Боб посылает Алисе DВ(M’).

12. Алиса использует EB, чтобы расшифровать DВ(M’). Таким образом, одновременно проверяются подпись Боба и целостность подписанной информации.

13. Алиса для точности проверяет IA в M’.

14. Алиса проверяет TВ в M’ и убеждается, что сообщение является текущим.

15. Дополнительно Алиса может проверить RВ в M’, чтобы убедиться, что сообщение не является повторяемым старым сообщением.

Трехпроходный протокол решает ту же самую задачу, но без меток времени. Этапы (1) — (15) такие же, как в двухпроходном алгоритме, но TA = TВ = 0.

16. Алиса сверяет полученную версию RA с RA, которое было отправлено Бобу на этапе (3).

18. Боб использует EА, чтобы расшифровать DА(RВ). Таким образом одновременно проверяются подпись Алисы и целостность подписанной информации.

19. Алиса сверяет полученную версию RВ с RВ, которое было отправлено Алисе на этапе (10).

| следующая лекция ==>
Сертификаты | Депонирование ключей

Дата добавления: 2014-01-04 ; Просмотров: 364 ; Нарушение авторских прав? ;

Нам важно ваше мнение! Был ли полезен опубликованный материал? Да | Нет

Сергей Панасенко,
к. т. н., начальник отдела разработки ПО фирмы "Анкад"
develop@ancud.ru

Типы аутентификации

Как известно, практически в любых компьютерных системах существует необходимость аутентификации. В ходе этой процедуры компьютерная система проверяет, действительно ли пользователь тот, за кого себя выдает. Для того, чтобы получить доступ к компьютеру, в Интернет, к системе удаленного управления банковским счетом и т. д., пользователю необходимо убедительно доказать компьютерной системе, что "он есть та самая персона", а не кто-либо еще. Для этого он должен предъявить системе некую аутентификационную информацию, на основании которой модуль аутентификации данной системы выносит решение о предоставлении ему доступа к требуемому ресурсу (доступ разрешен/нет).

В настоящее время для такой проверки применяется информация трех видов.

Первый — уникальная последовательность символов, которую пользователь должен знать для успешного прохождения аутентификации. Простейший пример — парольная аутентификация, для которой достаточно ввести в систему свой идентификатор (например, логин) и пароль.

Второй вид информации — уникальное содержимое или уникальные характеристики предмета. Простейший пример — ключ от любого замка. В случае же компьютерной аутентификации в этом качестве выступают любые внешние носители информации: смарт-карты, электронные таблетки iButton, USB-токены и т. д.

Читайте также:  Как узнать размер пенсии по инвалидности

И, наконец, третий вид аутентификации — по биометрической информации, которая неотъемлема от пользователя. Это может быть отпечаток пальца, рисунок радужной оболочки глаза, форма лица, параметры голоса и т. д.

Очень часто комбинируют несколько видов информации, по которой проводится аутентификация. Типичный пример: аутентификационная информация хранится на смарт-карте, для доступа к которой нужно ввести пароль (PIN-код). Такая аутентификация называется двухфакторной. Существуют реальные системы и с трехфакторной аутентификацией.

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

Удаленная аутентификация

В случае удаленной аутентификации (скажем, пользователь намерен получить доступ к удаленному почтовому серверу для проверки своей электронной почты) существует проблема передачи аутентификационной информации по недоверенным каналам связи (через Интернет или локальную сеть). Чтобы сохранить в тайне уникальную информацию, при пересылке по таким каналам используется множество протоколов аутентификации. Рассмотрим некоторые из них, наиболее характерные для различных применений.

Доступ по паролю

Простейший протокол аутентификации — доступ по паролю (Password Access Protocol, PAP): вся информация о пользователе (логин и пароль) передается по сети в открытом виде (рис. 1). Полученный сервером пароль сравнивается с эталонным паролем данного пользователя, который хранится на сервере. В целях безопасности на сервере чаще хранятся не пароли в открытом виде, а их хэш-значения (о хэшировании см. "Цифровая подпись — как это делается", "BYTE/Россия" № 1’2004).

Рис. 1. Схема протокола PAP.

Данная схема имеет весьма существенный недостаток: любой злоумышленник, способный перехватывать сетевые пакеты, может получить пароль пользователя с помощью простейшего анализатора пакетов типа sniffer. А получив его, злоумышленник легко пройдет аутентификацию под именем владельца пароля.

По сети в процессе аутентификации может передаваться не просто пароль, а результат его преобразования — скажем, тот же хэш пароля. К сожалению, это не устраняет описанный выше недостаток — злоумышленник с тем же успехом может перехватить хэш пароля и применять его впоследствии.

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

Запрос-ответ

В семейство протоколов, называемых обычно по процедуре проверки "запрос-ответ", входит несколько протоколов, которые позволяют выполнить аутентификацию пользователя без передачи информации по сети. К протоколам семейства "запрос-ответ" относится, например, один из наиболее распространенных — протокол CHAP (Challenge-Handshake Authentication Protocol).

Процедура проверки включает как минимум четыре шага (рис. 2):

  • пользователь посылает серверу запрос на доступ, включающий его логин;
  • сервер генерирует случайное число и отправляет его пользователю;
  • пользователь шифрует полученное случайное число симметричным алгоритмом шифрования на своем уникальном ключе (см. "Современные алгоритмы шифрования", "BYTE/Россия" № 8’2003), результат зашифрования отправляется серверу;
  • сервер расшифровывает полученную информацию на том же ключе и сравнивает с исходным случайным числом. При совпадении чисел пользователь считается успешно аутентифицированным, поскольку признается владельцем уникального секретного ключа.
Рис. 2. Схема протокола аутентификации типа "запрос-ответ".

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

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

Однако в качестве клиентского компьютера может выступать и смарт-карта либо аналогичное "носимое" устройство, обладающее достаточной вычислительной мощностью, например, мобильный телефон. В таком случае теоретически допустима аутентификация и получение доступа к серверу с любого компьютера, оснащенного устройством чтения смарт-карт, с мобильного телефона или КПК.

Протоколы типа "запрос-ответ" легко "расширяются" до схемы взаимной аутентификации (рис. 3). В этом случае в запросе на аутентификацию пользователь (шаг 1) посылает свое случайное число (N1). Сервер на шаге 2, помимо своего случайного числа (N2), должен отправить еще и число N1, зашифрованное соответствующим ключом. Тогда перед выполнением шага 3 пользователь расшифровывает его и проверяет: совпадение расшифрованного числа с N1 указывает, что сервер обладает требуемым секретным ключом, т. е. это именно тот сервер, который нужен пользователю. Такая процедура аутентификации часто называется рукопожатием.

Рис. 3. Схема протокола взаимной аутентификации.

Как видно, аутентификация будет успешна только в том случае, если пользователь предварительно зарегистрировался на данном сервере и каким-либо образом обменялся с ним секретным ключом.

Заметим, что вместо симметричного шифрования в протоколах данного семейства может применяться и асимметричное шифрование, и электронная цифровая подпись. В таких случаях схему аутентификации легко расширить на неограниченное число пользователей, достаточно применить цифровые сертификаты в рамках инфраструктуры открытых ключей (см. "Открытые ключи — опасности и защита от них", "BYTE/Россия" № 7’2004).

Читайте также:  Как отключить домашнюю антенну в москве

Протокол Kerberos

Протокол Kerberos, достаточно гибкий и имеющий возможности тонкой настройки под конкретные применения, существует в нескольких версиях. Мы рассмотрим упрощенный механизм аутентификации, реализованный с помощью протокола Kerberos версии 5 (рис. 4):

Рис. 4. Схема протокола Kerberos.

Прежде всего стоит сказать, что при использовании Kerberos нельзя напрямую получить доступ к какому-либо целевому серверу. Чтобы запустить собственно процедуру аутентификации, необходимо обратиться к специальному серверу аутентификации с запросом, содержащим логин пользователя. Если сервер не находит автора запроса в своей базе данных, запрос отклоняется. В противном случае сервер аутентификации формирует случайный ключ, который будет использоваться для шифрования сеансов связи пользователя с еще одним специальным сервером системы: сервером предоставления билетов (Ticket-Granting Server, TGS). Данный случайный ключ (обозначим его Ku-tgs) сервер аутентификации зашифровывает на ключе пользователя (Kuser) и отправляет последнему. Дополнительная копия ключа Ku-tgs с рядом дополнительных параметров (называемая билетом) также отправляется пользователю зашифрованной на специальном ключе для связи серверов аутентификации и TGS (Ktgs). Пользователь не может расшифровать билет, который необходим для передачи серверу TGS на следующем шаге аутентификации.

Следующее действие пользователя — запрос к TGS, содержащий логин пользователя, имя сервера, к которому требуется получить доступ, и тот самый билет для TGS. Кроме того, в запросе всегда присутствует метка текущего времени, зашифрованная на ключе Ku-tgs. Метка времени нужна для предотвращения атак, выполняемых повтором перехваченных предыдущих запросов к серверу. Подчеркнем, что системное время всех компьютеров, участвующих в аутентификации по протоколу Kerberos, должно быть строго синхронизировано.

В случае успешной проверки билета сервер TGS генерирует еще один случайный ключ для шифрования сеансов связи между пользователем, желающим получить доступ, и целевым сервером (Ku-serv). Этот ключ шифруется на ключе Kuser и отправляется пользователю. Кроме того, аналогично шагу 2, копия ключа Ku-serv и необходимые целевому серверу параметры аутентификации (билет для доступа к целевому серверу) посылаются пользователю еще и в зашифрованном виде (на ключе для связи TGS и целевого сервера — Kserv).

Теперь пользователь должен послать целевому серверу полученный на предыдущем шаге билет, а также метку времени, зашифрованную на ключе Ku-serv. После успешной проверки билета пользователь наконец-то считается аутентифицированным и может обмениваться информацией с целевым сервером. Ключ Ku-serv, уникальный для данного сеанса связи, часто применяется и для шифрования пересылаемых в этом сеансе данных.

В любой системе может быть несколько целевых серверов. Если пользователю необходим доступ к нескольким из них, он снова формирует запросы к серверу TGS — столько раз, сколько серверов нужно ему для работы. Сервер TGS генерирует для каждого из таких запросов новый случайный ключ Ku-serv, т. е. все сессии связи с различными целевыми серверами защищены при помощи разных ключей.

Процедура аутентификации по протоколу Kerberos выглядит достаточно сложной. Однако не стоит забывать, что все запросы и зашифровывание их нужными ключами автоматически выполняет ПО, установленное на локальном компьютере пользователя. Вместе с тем необходимость установки достаточно сложного клиентского ПО — несомненный недостаток данного протокола. Впрочем, сегодня поддержка Kerberos встроена в наиболее распространенные ОС семейства Windows, начиная с Windows 2000, что нивелирует данный недостаток.

Второй недостаток — необходимость в нескольких специальных серверах (доступ к целевому серверу обеспечивают как минимум еще два, сервер аутентификации и TGS). Однако в системах с небольшим числом пользователей все три сервера (аутентификации, TGS и целевой) могут физически совмещаться на одном компьютере.

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

Выбор того или иного протокола зависит в первую очередь от важности информации, доступ к которой предоставляется по результатам аутентификации. Другой критерий — удобство использования. И здесь, как и везде, полезно соблюдать разумный баланс. Иногда, если нет особых требований к секретности процедуры аутентификации, вместо надежного (но непростого в реализации) протокола типа Kerberos лучше использовать "элементарный" парольный протокол РАР, простота и удобство применения которого часто перевешивают все его недостатки.

Другие статьи из раздела

  • Решение Fortinet для безопасности подключенных автомобилей
  • Решение для защиты критичных сегментов сетевой инфраструктуры
  • Решения HID Global для безопасности приложений Интернета вещей
  • Check Point отметила рост атак на корпоративные сети
  • Новые троянцы для Linux

Поместить в блог

Комментарии к статье

Рекламные ссылки

Chloride
Демонстрация Chloride Trinergy
Впервые в России компания Chloride Rus провела демонстрацию системы бесперебойного электропитания Chloride Trinergy®, а также ИБП Chloride 80-NET™, NXC и NX для своих партнеров и заказчиков.

Читайте также:  Нужен ли сейчас знак шипы на автомобиле

NEC Нева Коммуникационные Системы
Завершена реорганизация двух дочерних предприятий NEC Corporation в России
С 1 декабря 2010 года Генеральным директором ЗАО «NEC Нева Коммуникационные Системы» назначен Раймонд Армес, занимавший ранее пост Президента Shyam …

компания «Гротек»
С 17 по 19 ноября 2010 в Москве, в КВЦ «Сокольники», состоялась VII Международная выставка InfoSecurity Russia. StorageExpo. Documation’2010.
Новейшие решения защиты информации, хранения данных и документооборота и защиты персональных данных представили 104 организации. 4 019 руководителей …

Видеоролики

МФУ Panasonic DP-MB545RU с возможностью печати в формате А3
Хотите повысить эффективность работы в офисе? Вам поможет новое МФУ #Panasonic DP-MB545RU. Устройство осуществляет

Adaptec by PMC
RAID-контроллеры Adaptec Series 5Z с безбатарейной защитой кэша
Опытные сетевые администраторы знают, что задействование в работе кэш-памяти RAID-контроллера дает серьезные преимущества в производительности …

Chloride
Трехфазный ИБП Chloride от 200 до 1200 кВт: Trinergy
Trinergy — новое решение на рынке ИБП, впервые с динамическим режимом работы, масштабируемостью до 9.6 МВт и КПД до 99%. Уникальное сочетание …

Протоколы проверки подлинности

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

  • Протокол PAP (Password Authentication Protocol – Незашифрованный пароль)
  • Протокол CHAP (Challenge-Handshake Authentication Protocol – Шифрованная проверка подлинности)
  • Протокол MS-CHAP (Microsoft Challenge Handshake Authentication Protocol – Шифрованная проверка подлинности Microsoft)
  • Протокол MS-CHAP v2 (Шифрованная проверка подлинности Microsoft, версия 2)
  • Протокол EAP-MD5 (Extensible Authentication Protocol-Message Digest 5 – Протокол расширенной проверки подлинности по методу MD5-Challenge)
  • Протокол EAP-TLS (Extensible Authentication Protocol-Transport Level Protocol – Расширенный протокол проверки подлинности на основе сертификата)

Для PPTP-подключений Вы должны использовать протоколы MS-CHAP, MS-CHAP v2 или EAP-TLS. Только эти три протокола проверки подлинности предоставляют механизм создания одинаковых ключей шифрования как на VPN-клиенте, так и на VPN-сервере. Шифрование MPPE использует этот ключ для шифрования всех данных, передаваемых по протоколу PPTP через VPN-подключение. Протоколы MS-CHAP и MS-CHAP v2 являются протоколами проверки подлинности с использованием паролей.

При отсутствии сертификатов пользователя или смарт-карт настоятельно рекомендуется использовать протокол MS-CHAP v2, поскольку он обеспечивает лучшую безопасность по сравнению с протоколом MS-CHAP, а также обеспечивает взаимную проверку подлинности (VPN-сервер выполняет проверку подлинности VPN-клиента и наоборот).

Примечание
Если Вы используете протокол проверки подлинности на основе пароля, настройте использование в Вашей сети только надежных паролей. Надежными являются длинные (более 8 знаков) пароли, содержащие случайный набор символов в верхнем и нижнем регистрах, цифр и спецсимволов. Пример надежного пароля: "f3L*q02

>xR3w#4o". При наличии домена Active Directory примените параметры групповой политики, чтобы задать обязательное использование стойких паролей.

Протокол EAP-TLS разработан для использования совместно с инфраструктурой сертификата, сертификатами пользователя или смарт-картами. При использовании протокола EAP-TLS для проверки подлинности VPN-клиент отправляет свой сертификат пользователя, а VPN-сервер – сертификат компьютера. Это наиболее надежный метод проверки подлинности, поскольку он не использует пароли.

Примечание
Вы можете использовать сторонние центры сертификации до тех пор, пока в сертификат, находящийся в хранилище компьютера сервера проверки подлинности в Интернете (Internet Authentication Service, IAS), содержит цель (также известную как Enhanced Key Usage, EKU – использование расширенного ключа или политика выдачи сертификатов (certificate issuance policy)) "Проверка подлинности сервера". Цель сертификата определяется идентификатором объекта (object identifier, OID). OID для сертификата, используемого для проверки подлинности сервера имеет значение "1.3.6.1.5.5.7.3.1". В дополнение к этому условию сертификат пользователя, установленный на клиент удаленного доступа Windows 2000, должен содержать цель "Проверка подлинности клиента" (OID "1.3.6.1.5.5.7.3.2")
.

Для L2TP/IPSec-подключений может использоваться любой протокол проверки подлинности, потому что проверка подлинности происходит после создания защищенного канала между VPN-клиентом и VPN-сервером известное также, как сопоставление безопасности IPSec (IPSec security association, SA). Тем не менее, рекомендуется использовать протоколы MS-CHAP v2 или EAP-TLS, как предоставляющие наиболее надежную проверку подлинности пользователей.

Вопросы проектирования: выбор протокола проверки подлинности

При выборе протокола проверки подлинности для VPN-подключений обратите внимание на следующие моменты:

  • При использовании смарт-карт или наличии инфраструктуры сертификатов, выдающей сертификаты пользователей, используйте протокол проверки подлинности EAP-TLS как для PPTP-, так и для L2TP-подключений. EAP-TLS поддерживается только клиентами ОС Windows XP и Windows 2000.
  • Если необходимо использовать протокол проверки подлинности на основе паролей, используйте MS-CHAP v2 и задайте обязательное использование надежных паролей при помощи групповой политики. MS-CHAP v2 поддерживается компьютерами, работающими под управлением Windows XP, Windows 2000, Windows NT 4.0 с установленным пакетом обновлений 4 (SP4) или более поздним, Windows ME, Windows 98, и Windows 95 с установленным Windows обновлением Dial-Up Networking 1.3 или более поздними обновлениями производительности и безопасности.

Оставить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *