Тестирование / tsure052

идентификационного номера (personal identification number - PIN) и персонального устройства идентификации пользователя - аппаратного ключа, интеллетульной карты или токена. Интеллектуальные токены характеризуются наличием собственной вычислительной мощности. Они подразделяются на интеллектуальные карты, стандартизованные ISO, и прочие токены. Карты нуждаются в интерфейсном устройстве, прочие токены обычно обладают ручным интерфейсом (дисплеем и клавиатурой) и по внешнему виду напоминают калькуляторы. Чтобы токен начал работать, пользователь должен ввести свой личный идентификационный номер.

По принципу действия интеллектуальные токены можно разделить на следующие категории.

•Статический обмен паролями: пользователь обычным образом доказывает токену свою подлинность, затем токен проверяется компьютерной системой.

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

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

пользователь читает запрос с экрана терминала, набирает его на клавиатуре токена (возможно, в это время вводится и личный номер), а на дисплее токена видит ответ и переносит его на клавиатуру терминала.

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

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

91

типа "запрос-ответ" (challenge-response). Обмен сообщениями начинается в тот момент, когда пользователь, имеющий аппаратный ключ, набирает номер для входа в систему. Главное (master) устройство идентификации пользователя перехватывает звонок и требует ввода идентификационного номера, который по пути проходит через аппаратный ключ и запоминается. Если PIN принадлежит к числу зарегистрированных, устройство идентификации генерирует случайное число и пересылает его пользователю; получив его, аппаратный код генерирует на основе этого числа, PIN пользователя и уникального кода аппаратного ключа ответ на запрос и передает обратно в систему. Система в свою очередь самостоятельно генерирует ответ, и если получившийся ответ совпадает с присланным по линиям связи, то удаленная система получает доступ к сети. Эта процедура хороша еще и тем, что ответ, однажды признанный корректным, не может быть использован повторно: каждый раз как пользователь входит в систему, генерится новое число-запрос, а следовательно, меняется и ответ. Другое преимущество систем такого типа состоит в том, что все данные передаются по сети в зашифрованном виде.

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

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

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

Мандатное управление доступом реализуется на основе результатов сравнения уровня допуска пользователя и степени конфиденциальности информации.

92

2.1.3.ПРОТОКОЛЫ УДАЛЕННОГО ДОСТУПА

Кнастоящему времени разработано несколько протоколов удаленного доступа. Основные из них - следующие:

SLIP (Serial Line Interface Protocol) - протокол взаимодействия с последовательной линией, который применялся с начала 80-х гг в сетях Unix,

RAS (Remote Access Service) - служба удаленного доступа, которая обеспечивает связь компьютеров под управлением операционных систем из клана Windows,

ARAP (Apple Remote Access Protocol) - протокол удаленного доступа фирмы Apple,

предназначенный для организации удаленного доступа в сетях на базе протокола

AppleTalk.

Наиболее распространен протокол PPP (Point-to-Point Protocol) - протокол "Точкаточка". Это группа протоколов, которая является стандартом Интернет. Основная задача

ее- формирование кадров для передачи пакетов сетевого уровня через линию передачи данных. Метод формирования кадров, используемый РРР, обеспечивает одновременную работу через звено передачи данных нескольких протоколов сетевого уровня. Расширяемый протокол LCP (Link Control Protocol) - протокол управления звеном входит в состав РРР и позволяет ему функционировать в линиях передачи данных разных типов. Он позволяет согласовывать размеры пакета, потребовать проведения аутентификации системы на другой стороне линии, определить, функционирует ли звено передачи данных и при необходимости разорвать его. Протоколы семейства NCP (Network Control Protocol) - протоколы управления сетью также входят в РРР и предназначены для конфигурирования различных протоколов сетевого уровня, для назначения адресов. Каждый из протоколов этого семейства предназначен для настройки и обслуживания одного из протоколов сетевого уровня, напр., для настройки параметров протокола IP предназначен протокол IPCP.

2.1.4.ПРОТОКОЛЫ АУТЕНТИФИКАЦИИ УДАЛЕННОГО ДОСТУПА

Протоколы аутентификации удаленного доступа имеют ряд особенностей:

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

93

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

•возможность проведения аутентификации в процессе работы соединения, что устраняет риск перехвата установленного звена передачи данных после проведения аутентификации между удаленным компом и сервером удаленного доступа;

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

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

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

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

Впроцессе конфигурирования, поддержки и разрыва звена связи протокол РРР

проходит через последовательность фаз. Эта последовательность приведена на Рис. 7, где в скобках указаны английские названия фаз работы протокола РРР.

94

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

Рис. 7

Последовательность фаз работы протоколов семейства PPP

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

95

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

2.1.4.1.Протокол аутентификации РАР

Протокол РАР (Password Authentication Protocol) обеспечивает простейший метод аутентификации. Он использует двухзвенную процедуру обмена пакетами. Эта процедура может отрабатываться только после установления звена передачи данных. После того, как фаза установления звена передачи данных завершена, пара значений, состоящая из идентификатора и пароля, передается по звену до тех пор, пока аутентификация не будет подтверждена или звено не будет разорвано.

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

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

Для того, чтобы инициировать процесс аутентификации с использованием протокола РАР, проверяющая сторона должна выслать пакет LCP, указывающий протокол РАР (за протоколом РАР закреплен шестнадцатеричный номер с023) в качестве протокола аутентификации. После этого сторона, чья подлинность проверяется, и проверяющая сторона производят обмен пакетами РАР. Пакет протокола РАР имеет формат, приведенный на Рис. 8.

96

Биты

(Identifier)

Данные (Data) ...

Рис. 8 Формат пакета аутентификации

Поле КОД (Соdе) указывает тип пакета. Определены пакеты трех типов:

•ЗАПРОС АУТЕНТИФИКАЦИИ – Authenticate-Request;

•ПОДТВЕРЖДЕНИЕ АУТЕНТИФИКАЦИИ – Authenticate-Ack;

•ОТКАЗ В АУТЕНТИФИКАЦИИ – Authenticate-Nak.

Поле ИДЕНТИФИКАТОР (Identifier) содержит уникальное значение, которое позволяет определить, какому запросу соответствует полученный ответ. Поле ДЛИНА (Lenght) содержит длину пакета в байтах. Длина и формат поля ДАННЫЕ (Data) определяются типом пакета РАР.

Пакеты ЗАПРОС АУТЕНТИФИКАЦИИ используются для передачи данных аутентификации проверяющей стороне. Пакет этого типа должен повторно передаваться по звену передачи данных до тех пор, пока не будет получен действительный пакет ПОДТВЕРЖДЕНИЕ АУТЕНТИФИКАЦИИ, или пока не истечет таймер, который может присутствовать в некоторых реализациях.

Поле данных РАР в пакете ЗАПРОС АУТЕНТИФИКАЦИИ содержит:

•идентификатор проверяемой стороны;

•длину идентификатора проверяемой стороны в байтах;

•пароль;

•длину пароля в байтах.

Проверяющая сторона, получив пакет ЗАПРОС АУТЕНТИФИКАЦИИ и выполнив проверку, должна выслать в зависимости от результатов проверки пакет

ПОДТВЕРЖДЕНИЕ АУТЕНТИФИКАЦИИ или ОТКАЗ В АУТЕНТИФИКАЦИИ. Если пакет будет потерян, то проверяемая сторона, не получив его, вышлет пакет ЗАПРОС АУТЕНТИФИКАЦИИ повторно. В этом случае проверяющая сторона должна повторно сформировать пакет ПОДТВЕРЖДЕНИЕ АУТЕНТИФИКАЦИИ или ОТКАЗ В АУТЕНТИФИКАЦИИ. Пакет ПОДТВЕРЖДЕНИЕ АУТЕНТИФИКАЦИИ используется для извещения проверяемой стороны о том, что подлинность была подтверждена. Если проверяющая сторона обнаружит несоответствие указанного в пакете ЗАПРОС

97

Данный метод аутентификации основан на использовании пароля, который известен обеим сторонам. Он никогда не передается по звену передачи данных, хотя доступен обеим сторонам в незашифрованном виде. Используемый алгоритм требует, чтобы пароль имел длину не менее одного байта. Так как используется односторонняя хэшфункция, то практически невозможно вычислить пароль, даже зная исходные последовательности в пакете ВЫЗОВ и пакете ОТКЛИК.

Последовательность, содержащаяся в пакете ВЫЗОВ, должна быть уникальной (иначе можно было бы повторно использовать перехваченный ранее пакет ОТКЛИК, посланный в ответ на пакет ВЫЗОВ, содержащий ту же самую последовательность, и таким образом сфальсифицировать процедуру) и непредсказуемой (иначе можно было бы, предсказав эту величину, составить пакет ВЫЗОВ и, имитируя проверяющую сторону, послать проверяемой стороне этот пакет, получить и сохранить пакет ОТКЛИК, дождаться использования такого же пакета ВЫЗОВ настоящей проверяющей стороной и послать в ответ полученный "обманным путем" пакет ОТКЛИК).

Процедура аутентификации с помощью протокола СНАР может быть затребована так же, как и в случае с протоколом РАР, только с указанием шестнадцатиричного номера, соответствующего СНАР (с223) и метода аутентификации, то есть используемой хэш-функции. Причем стандартной функцией, которая должна поддерживаться во всех реализациях, является МD5 (Message Digest Version 5 – профиль сообщения, версия 5). После этого производится обмен пакетами протокола CНАР. Эти пакеты имеют тот же формат, что и пакеты протокола РАР (Рис. 8). Поле КОД указывает тип пакета.

Поле ИДЕНТИФИКАТОР содержит уникальное значение, которое позволяет определить, какому запросу соответствует полученный ответ. Поле ДЛИНА содержит длину пакета в байтах. Длина и формат поля ДАННЫЕ определяются типом пакета СНАР.

Процедура аутентификации начинается с отправки проверяющей стороной пакета ВЫЗОВ. Этот пакет должен быть отправлен повторно, если в ответ на него не был получен пакет ОТКЛИК. Кроме того, такой пакет может быть отправлен уже в ходе работы протоколов сетевого уровня для того, чтобы убедиться, что система на противоположной стороне звена передачи данных осталась той же самой.

Поле данных СНАР в пакете ВЫЗОВ содержит:

99

•произвольную последовательность символов, которая должна быть уникальной для каждого посланного пакета ВЫЗОВ; ее длина зависит от применяемого алгоритма генерации этой последовательности и не зависит от используемой хэш-функции;

•длину последовательности в байтах;

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

пару идентификатор-пароль.

Пакет ОТКЛИК должен быть отправлен проверяемой стороной в ответ на каждый принятый пакет ВЫЗОВ. Поле данных СНАР в пакете ОТКЛИК содержит:

•результат воздействия односторонней хэш-функции на строку символов, полученную путем конкатенации идентификатора проверяющей стороны из пакета ВЫЗОВ, хранимого локально пароля и последовательности символов из пакета ВЫЗОВ; длина результата зависит от применяемой хэш-функции (16 байт для функции МD5); в случае использования двусторонней (взаимной) аутентификации пароли, используемые для получения результата, не должны совпадать (иначе злоумышленник сможет, получив пакет ВЫЗОВ, отправить его в качестве собственного, получить в ответ пакет ОТКЛИК и отправить его в качестве собственного пакета ОТКЛИК);

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

Получив пакет ОТКЛИК, проверяющая сторона сравнивает содержимое результата из этого пакета с вычисленной самостоятельно на основании тех же исходных данных с помощью той же хэш-функции величиной. В зависимости от результата этого сравнения проверяющая сторона высылает, либо пакет ПОДТВЕРЖДЕНИЕ, либо пакет ОТКАЗ. После передачи пакета ОТКАЗ проверяющая сторона разрывает звено передачи данных.

Поле данных СНАР в пакете ПОДТВЕРЖДЕНИЕ и пакете ОТКАЗ содержит:

•сообщение, которое, как правило, содержит текст, содержание которого стандартом не устанавливается;

•длину сообщения в байтах.

100