Аутентификация посредством gps[править | править код]
Новейшим направлением аутентификации является доказательство подлинности удаленного пользователя по его местонахождению. Данный защитный механизм основан на использовании системы космической навигации, типа GPS (Global Positioning System).
Пользователь, имеющий аппаратуру GPS, многократно посылает координаты заданных спутников, находящихся в зоне прямой видимости. Подсистема аутентификации, зная орбиты спутников, может с точностью до метра определить месторасположение пользователя. Высокая надежность аутентификации определяется тем, что орбиты спутников подвержены колебаниям, предсказать которые достаточно трудно. Кроме того, координаты постоянно меняются, что сводит на нет возможность их перехвата.
Сложность взлома системы состоит в том, что аппаратура передает оцифрованный сигнал спутника, не производя никаких вычислений. Все вычисления о местоположении производят на сервере аутентификации.
Аппаратура GPS проста и надежна в использовании и сравнительно недорога. Это позволяет её использовать в случаях, когда авторизованный удаленный пользователь должен находиться в нужном месте.
Аутентификация, основанная на местоположении выхода в интернет[править | править код]
Данный механизм основан на использовании информации о местоположении серверов, точек доступа беспроводной связи, через которые осуществляется подключение к сети интернет.
Относительная простота взлома состоит в том, что информацию о местоположении можно изменить, используя так называемые прокси-серверы или системы анонимного доступа.
Многофакторная аутентификация[править | править код]
Основная статья: Многофакторная аутентификация
В последнее время всё чаще применяется так называемая расширенная, или многофакторная, аутентификация. Она построена на совместном использовании нескольких факторов аутентификации. Это значительно повышает защищённость системы.
В качестве примера можно привести использование SIM-карт в мобильных телефонах. Субъект вставляет аппаратно свою карту (устройство аутентификации) в телефон и при включении вводит свой PIN-код (пароль).
Также, к примеру, в некоторых современных ноутбуках присутствует сканер отпечатка пальца. Таким образом, при входе в систему субъект должен пройти эту процедуру (биометрика), а потом ввести пароль.
Выбирая для системы тот или иной фактор или способ аутентификации, необходимо, прежде всего, отталкиваться от требуемой степени защищенности, стоимости построения системы, обеспечения мобильности субъекта.
Можно привести сравнительную таблицу:
5.Аутентификация на основе многоразовых паролей. Требования к парольной защите.
Один из способов аутентификации в компьютерной системе состоит во вводе вашего пользовательского идентификатора, в просторечии называемого «логином» (англ. login — регистрационное имя пользователя, учётка) и пароля — неких конфиденциальных сведений. Достоверная (эталонная) пара логин-пароль хранится в специальной базе данных.
Простая аутентификация имеет следующий общий алгоритм:
Субъект запрашивает доступ в систему и вводит личный идентификатор и пароль.
Введённые неповторимые данные поступают на сервер аутентификации, где сравниваются с эталонными.
При совпадении данных с эталонными аутентификация признаётся успешной, при различии — субъект перемещается к 1-му шагу
Введённый субъектом пароль может передаваться в сети двумя способами:
Незашифрованно, в открытом виде, на основе протокола парольной аутентификации (Password Authentication Protocol, PAP)
С использованием шифрования SSL или TLS. В этом случае неповторимые данные, введённые субъектом, передаются по сети защищённо.
6.Аутентификация на основе одноразовых паролей.
Заполучив однажды многоразовый пароль субъекта, злоумышленник имеет постоянный доступ к взломанным конфиденциальным сведениям. Эта проблема решается применением одноразовых паролей (OTP — One Time Password). Суть этого метода — пароль действителен только для одного входа в систему, при каждом следующем запросе доступа — требуется новый пароль. Реализован механизм аутентификации по одноразовым паролям может быть как аппаратно, так и программно.
Технологии использования одноразовых паролей можно разделить на:
Использование генератора псевдослучайных чисел, единого для субъекта и системы
Использование временных меток вместе с системой единого времени
Использование базы случайных паролей, единой для субъекта и для системы
В первом методе используется генератор псевдослучайных чисел с одинаковым значением для субъекта и для системы. Сгенерированный субъектом пароль может передаваться системе при последовательном использовании односторонней функции или при каждом новом запросе, основываясь на уникальной информации из предыдущего запроса.
Во втором методе используются временные метки. В качестве примера такой технологии можно привести SecurID. Она основана на использовании аппаратных ключей и синхронизации по времени. Аутентификация основана на генерации случайных чисел через определенные временные интервалы. Уникальный секретный ключ хранится только в базе системы и в аппаратном устройстве субъекта. Когда субъект запрашивает доступ в систему, ему предлагается ввести PIN-код, а также случайно генерируемое число, отображаемое в этот момент на аппаратном устройстве. Система сопоставляет введенный PIN-код и секретный ключ субъекта из своей базы и генерирует случайное число, основываясь на параметрах секретного ключа из базы и текущего времени. Далее проверяется идентичность сгенерированного числа и числа, введённого субъектом.
Третий метод основан на единой базе паролей для субъекта и системы и высокоточной синхронизации между ними. При этом каждый пароль из набора может быть использован только один раз. Благодаря этому, даже если злоумышленник перехватит используемый субъектом пароль, то он уже будет недействителен.
По сравнению с использованием многоразовых паролей одноразовые пароли предоставляют более высокую степень защиты.
7.Аутентификация на основе PIN-кода.
Актуальность обеспечения безопасности мобильных средств коммуникации, например, ip-phone, стимулирует новые разработки в этой области. Среди них можно назвать аутентификацию с помощью SMS-сообщений.
Процедура такой аутентификации включает в себя следующие шаги:
Ввод имени пользователя и пароля
Сразу после этого PhoneFactor (служба безопасности) присылает одноразовый аутентификационный ключ в виде текстового SMS-сообщения.
Полученный ключ используется для аутентификации
Привлекательность данного метода заключается в том, что ключ получается не по тому каналу, по которому производится аутентификация (out-of-band), что практически исключает атаку типа «человек посередине». Дополнительный уровень безопасности может дать требование ввода PIN-кода мобильного средства.
Данный метод получил широкое распространение в банковских операциях через интернет.
8.Понятия односторонней, двусторонней и трехсторонней аутентификации.
Односторонняя аутентификация предусматривает обмен информацией только в одном направлении. Данный тип аутентификации позволяет: 1. подтвердить подлинность только одной стороны информационного обмена; 2. обнаружить нарушение целостности передаваемой информации; 3. обнаружить проведение атаки типа "повтор передачи"; 4. гарантировать, что передаваемыми аутентификационными данными может воспользоваться только проверяющая сторона. Двусторонняя аутентификация, в отличие от односторонней, содержит дополнительный ответ проверяющей стороны доказывающей стороне, который должен убедить ее, что связь устанавливается именно с той стороной, которой были предназначены аутентификационные данные. Именно данный тип аутентификации был использован нами при внедрении локальной системы безопасности для одного из предприятий, которое разрабатывает дорожные системы безопасности и производит реверсивные светофоры с различной апертурой, причем система была спроектирована и внедрена в течении 3-х недель согласно всех требований Заказчика.
Трехсторонняя аутентификация содержит дополнительную передачу данных от доказывающей стороны проверяющей. Этот подход позволяет отказаться от использования меток времени при проведении аутентификации.
9.Протокол Нидхема - Шрёдера.
общее название для симметричного и асимметричного протоколов аутентификации и обмена ключами. Оба протокола были предложены Майклом Шрёдером и Роджером Нидхемом[1]. Вариант, основанный на симметричном шифровании, использует промежуточную доверенную сторону. Этот протокол стал основой для целого класса подобных протоколов. Например, Kerberos является одним из вариантов симметричного протокола Нидхема — Шрёдера. Вариант, основанный на асимметричном шифровании, предназначен для взаимной аутентификации сторон. В оригинальном виде оба варианта протокола являются уязвимыми
10.Строгая аутентификация на основе симметричных алгоритмов шифрования.
Рассмотрим следующие варианты аутентификации:
• односторонняя аутентификация с использованием меток времени;
• односторонняя аутентификация с использованием случайных чисел;
• двусторонняя аутентификация.
В каждом из этих случаев пользователь доказывает свою подлинность, демонстрируя знание секретного ключа, так как производит расшифровывание запросов с помощью этого секретного ключа.
При использовании в процессе аутентификации симметричного шифрования необходимо также реализовать механизмы обеспечения целостности передаваемых данных на основе общепринятых способов.
11.Строгая аутентификация на основе асимметричных алгоритмов шифрования.
В протоколах строгой аутентификации могут быть использованы асимметричные алгоритмы с открытыми ключами. В этом случае доказывающий может продемонстрировать знание секретного ключа одним из следующих способов:
- расшифровать запрос, зашифрованный на открытом ключе;
- поставить свою цифровую подпись на запросе.
Пара ключей, необходимая для аутентификации, не должна использоваться для других целей (например, для шифрования) по соображениям безопасности. Важно отметить, что выбранная система с открытым ключом должна быть устойчивой к атакам с выборкой шифрованного текста даже в том случае, если нарушитель пытается получить критичную информацию, выдавая себя за проверяющего и действуя от его имени.
12.Протоколы строгой аутентификации, основанные на использовании цифровой подписи.
В рекомендациях стандарта Х.509 специфицирована схема аутентификации, основанная на использовании цифровой подписи, меток времени и случайных чисел.
Для описания этой схемы аутентификации введем следующие обозначения:
tA, rА и rB- временная метка и случайные числа соответственно;
S A- подпись, сгенерированная участником А;
S B- подпись, сгенерированная участником В;
certA- сертификат открытого ключа участника А;
cert B -сертификат открытого ключа участника В.
Если участники имеют аутентичные открытые ключи, полученные друг от друга, то можно не пользоваться сертификатами, в противном случае они служат для подтверждения подлинности открытых ключей.
13. Этапы идентификации и аутентификации пользователя, реализуемые ОС Windows.
Первый шаг идентификации, поддерживаемый режимом аутентификации, реализуется при входе пользователя в систему. Здесь следует выделить возможность входа в штатном и в безопасном режиме (Safe Mode). В порядке замечания отметим, что принципиальным отличием безопасного режима является то, что при запуске системы в безопасном режиме можно отключить загрузку сторонних по отношению к системе драйверов и приложений. Поэтому, если в системе используется добавочная СЗИ от НСД, можно попытаться загрузить систему в безопасном режиме без компонент СЗИ от НСД, т.е. без средства защиты. С учетом же того, что загрузить систему в безопасном режиме может любой пользователь (в Unix системах – только Root), то СЗИ от НСД должна обеспечивать возможность входа в систему в безопасном режиме (после идентификации и аутентификации) только под учетной записью администратора.
Второй шаг состоит в запуске пользователем процессов, которые уже, в свою очередь, порождают потоки (именно потоки в общем случае и осуществляют обращение к ресурсам). Все работающие в системе процессы и потоки выполняются в контексте защиты того пользователя, от имени которого они так или иначе были запущены. Для идентификации контекста защиты процесса или потока используется объект, называемый маркером доступа (access token). В контекст защиты входит информация, описывающая привилегии, учетные записи и группы, сопоставленные с процессом и потоком. При регистрации пользователя (первый шаг, см. рис. 1) в системе создается начальный маркер, представляющий пользователя, который входит в систему, и сопоставляющий его с процессом оболочки, применяемой для регистрации пользователя. Все программы, запускаемые пользователем, наследуют копию этого маркера. Механизмы защиты в Windows используют маркер, определяя набор действий, разрешенных потоку или процессу.
Рис.1. Этапы идентификации и аутентификации пользователя
В общем случае пользователь имеет возможность запуска процесса как с собственными правами, так и под учетной записью другого пользователя. Запуск пользователем процесса под другой учетной записью возможен только после выполнения процедуры аутентификации – пользователь должен ввести идентификатор и пароль, соответствующие той учетной записи, под которой им будет запущен процесс (например, подобную возможность в ОС Windows предоставляет утилита runas.exe, но, начиная с ОС Windows XP, эта функция уже вынесена в проводник - ее можно реализовать, нажав правой кнопкой мыши на выбранном в проводнике исполняемом файле).
В порядке замечания отметим следующее. С одной стороны, это очень полезная опция, которая может быть использована в корпоративных приложениях, когда на одном компьютере требуется обрабатывать конфиденциальные и открытые данные. При этом предполагается, что для обработки данных различных категорий создаются различные учетные записи. Данная опция предполагает, что одновременно (без перезагрузки) можно обрабатывать данные различных категорий, например, под одной учетной записью обрабатывать необходимым приложением конфиденциальные данные, под другой учетной записью запустить Internet-приложение (у Вас на мониторе может быть открыто одновременно два окна). Естественно, что реализация данной возможности выставляет и дополнительные требования к СЗИ от НСД (например, при подобном запуске приложения ОС Windows между пользователями не изолируется буфер обмена, который в ОС является "принадлежностью" рабочего стола).
Однако важнейшей особенностью рассматриваемого способа запуска процесса является то, что при этом система начинает функционировать в многопользовательском режиме – в системе одновременно зарегистрировано несколько пользователей. Как следствие, может возникнуть проблема однозначной идентификации пользователя при доступе к ресурсу, что характерно для решения задачи реализации разграничительной политики доступа к устройствам (об этом - ниже).
Третий шаг состоит в порождении процессом потоков, которые собственно и обращаются к ресурсам. Система предоставляет разработчикам приложений сервисы олицетворения. Сервис олицетворения (impersonation) предоставляет возможность отдельному потоку выполняться в контексте защиты, отличном от контекста защиты процесса, его запустившего, т.е. запросить олицетворить себя с правами другого пользователя, в результате - действовать от лица другого пользователя. Как следствие, именно на этом этапе и возникают вопросы корректности идентификации и аутентификации пользователя при запросе доступа к ресурсам, а задача идентификации и аутентификации пользователей при запросах на доступ сводится к контролю корректности олицетворения.
В порядке замечания отметим, что аналогичная ситуация имеет место и в ОС семейства Unix, где существуют понятия идентификатора и эффективного идентификатора (под которым собственно и осуществляется запрос доступа к ресурсам).
Вывод. Требование "КСЗ должен обеспечивать идентификацию пользователей при запросах на доступ…" актуально и должно реализовываться современными СЗИ от НСД. При этом задача защиты при выполнении этого требования сводится к контролю корректности олицетворения при запросах доступа к ресурсам, т.к. именно использование сервиса олицетворения может привести к неконтролируемой смене исходного идентификатора.
14.Общие принципы аутентификации в ОС.
Аутентификация или проверка подлинности (authentication). После того как субъект безопасности вводит с клавиатуры или иным способом предоставляет необходимую для идентификации информацию (например, имя пользователя, маркер безопасности), он должен ввести с клавиатуры или представить частную информацию для аутентификации (например, пароль и PIN-код). В Windows субъект безопасности вводит эту информацию на экране регистрации с помощью программ Microsoft Graphical Identification and Authentication DLL (msgina.dll) и Winlogon.exe. Протокол аутентификации и механизм системы кодируют представленную информацию на настольном компьютере и передают запрос аутентификации. Служба аутентификации Windows может быть базой данных SAM или AD. База данных SAM обслуживает локальные процедуры регистрации и регистрацию на контроллерах домена Windows NT 4.0. AD аутентифицирует запросы в Windows 2000 или доменах более поздних версий этой операционной системы. Протокол аутентификации (например, LAN Manager, NT LAN Manager, NTLM, NTLMv2, Kerberos) используется для транспортировки запросов аутентификации и последующих транзакций между экраном регистрации и службой аутентификации. Чуть ниже каждый протокол аутентификации будет рассмотрен отдельно.
15.Алгоритмы формирования NT- и LM-хэшей.
LM-хеш вычисляется следующим образом[1]:
Пароль пользователя приводится к верхнему регистру.
Пароль дополняется нулями или обрезается до 14 байтов.
Получившийся пароль разделяется на две части по 7 байтов.
Эти значения используются для создания двух ключей DES, по одному для каждой 7-байтовой половинки, при этом 7 байтов рассматриваются как битовый поток и после каждых 7 битов вставляется ноль. Так создаются 64 бита, необходимые для ключа DES.
Каждый из этих ключей используется для DES-шифрования ASCII-строки «KGS!@#$%», в результате получаются два 8-байтовых шифрованных значения.
Данные шифрованные значения соединяются в 16-байтовое значение, являющееся LM-хешем.
Еще одна деталь, касающаяся хранения паролей — как к NT- так и к LM-хэшу всегда добавляются спереди 4 байта, назначение которых для меня загадка. Причем 4байта будут присутствовать даже если пароль отключен. В данном случае видно, что длина LM хэша =4 и если посмотреть на его адрес, можно эти 4 байта увидеть несмотря на то что никакого LM-хэша нет. Поэтому при поиске смещений хэшей смело прибавляем 4 байта к адресу, а при учете размеров — вычитаем. Если удобнее читать код — вот примерно так будет выглядеть поиск адресов с учетом инверсии, лишних четырех байтов и прибавления стартового смещения 0xcc (код C#)
Формирование NT-хэша: 1. Пароль пользователя преобразуется в Unicode-строку. 2. Генерируется MD4-хэш на основе данной строки. 3. Полученный хэш шифруется алгоритмом DES, ключ составляется на основе RID пользователя.
16.Протокол Kerberos.
сетевой протокол аутентификации, который предлагает механизм взаимной аутентификации клиента и сервера перед установлением связи между ними, причём в протоколе учтён тот факт, что начальный обмен информацией между клиентом и сервером происходит в незащищенной среде, а передаваемые пакеты могут быть перехвачены и модифицированы.
Пример.
Пункт 1. Договоренность о пароле. Пусть Алиса общается с Бобом. При этом Боб использует информацию только тогда, когда уверен, что информация получена от Алисы. Чтобы избежать подделки — они договорились между собой о пароле, который знают только они вдвоём. При получении сообщения Боб может заключить из письма — знает ли его собеседник пароль. Если собеседнику Боба пароль известен, то можно утверждать, что его собеседником является Алиса.
Пункт 2. Возникновение проблемы передачи пароля. Теперь определим — каким же образом Алисе и Бобу показывать знание пароля. Конечно, можно просто включить пароль в текст письма. Например: «Привет, Боб. Наш пароль.». Если бы только Боб и Алиса были уверены, что их письма никто не читает — тогда можно было бы воспользоваться этим способом. Но, к сожалению, почта передается по сети, в которой работают другие пользователи, среди которых есть любопытная Ева. Ева поставила себе задачу — выяснить пароль, известный только Бобу и Алисе, при помощи которого они обмениваются сообщениями друг с другом. Теперь совершенно ясно, что нельзя указывать пароль просто в тексте письма. Значит, о пароле нельзя говорить открыто, но при этом надо дать знать собеседнику, что пароль вам известен.
Пункт 3. Решение проблемы передачи пароля. Протокол Kerberos решает проблему передачи пароля средствами криптографии с секретным ключом. Вместо того, чтобы сообщать друг другу пароль, участники сеанса связи обмениваются криптографическим ключом, знание которого подтверждает личность собеседника. Но для того, чтобы такая технология была возможна, необходимо, чтобы общий ключ был симметричным, то есть, ключ должен обеспечивать и шифрование, и расшифровку сообщения.
Пункт 4. Проблема обмена паролями. При использовании простых протоколов, типа описанного выше, возникает одна важная проблема. В случае с Бобом и Алисой надо понять, как они договариваются о секретном ключе для переписки друг с другом. Конечно, люди могут встретиться и договориться, но ведь в сетевых переговорах участвуют и машины. Если под Алисой понимать клиентскую программу, а под Бобом — службу на сетевом сервере, то встретиться они никак не могут. Проблема состоит ещё в том, что, когда клиенту надо посылать сообщение на несколько серверов, в этом случае для каждого сервера ей придётся обзавестись отдельным ключом. А серверу тогда потребуется столько секретных ключей, сколько у него клиентов. Необходимость хранить на каждом компьютере такое количество ключей создаёт риск для всей системы безопасности.
Пункт 5. Решение проблемы обмена паролями. Для решения этих проблем проектом «Афина» и был разработан специальный протокол — Kerberos. По аналогии с древнегреческой мифологией, этот протокол был назван в честь трёхголового пса, который защищал выход из царства Аида, — Цербера, или более точно — Кербера. Трём головам Цербера в протоколе соответствуют три участника безопасной связи: клиент, сервер и доверенный посредник между ними. Роль посредника здесь играет центр распределения ключей «Key distribution center», KDC.
17.Организация взаимодействия между Kerberos – областями.
Основным компонентом системы Kerberos является KDC. Он отвечает за аутентификацию компьютеров в области (realm) Kerberos. Обычно область Kerberos совпадает с некоторым доменом или поддоменом Internet. Например, домен threeroomco.com может содержать единственную область Kerberos; в этом случае область скорее всего будет иметь имя THREEROOMCO.COM. В отличие от имен доменов Internet, имена областей Kerberos чувствительны к регистру символов. Для того чтобы подчеркнуть различия между доменом Internet и областью Kerberos, которая определяет тот же набор компьютеров, принято задавать имена областей символами верхнего регистра. Область Kerberos может занимать не весь домен либо включать компьютеры из нескольких доменов. Если в одном домене находятся две или более области Kerberos, то для их идентификации в начало имени области добавляются дополнительные компоненты, например REALM1.THREEROOMCO.COM и REALM1.THREEROOMCO.СОМ.
18.Назначение и типы сертификатов открытых ключей.
Сертификат открытого ключа (сертификат ЭП, сертификат ключа подписи, сертификат ключа проверки электронной подписи (согласно ст. 2 Федерального Закона от 06.04.2011 «Об электронной подписи» № 63-ФЗ)) — электронный или бумажный документ, содержащий открытый ключ, информацию о владельце ключа, области применения ключа, подписанный выдавшим его Удостоверяющим центром и подтверждающий принадлежность открытого ключа владельцу.
Открытый ключ может быть использован для организации защищённого канала связи с владельцем двумя способами:
для проверки подписи владельца (аутентификация)
для шифрования посылаемых ему данных (конфиденциальность)
Существует две модели организации инфраструктуры сертификатов: централизованная (PKI) и децентрализованная (реализуемая на основе т. н. сетей доверия), получившая наибольшее распространение в сетях PGP.
19.Структура сертификата открытого ключа по стандарту Х509.
Согласно RFC 1422, стандарт X.509 определяет понятие «сертификат с открытом ключом» и другие базовые определения PKIX. При этом сертификат с открытым ключом представляет собой определённую структуру данных, которая содержит имя пользователя, открытую составляющую (англ. Public Component) ключа двухключевой криптосистемы этого пользователя и имя компании (далее — «издатель»), который подтверждает, что открытая составляющая привязана к имени пользователя. Эти данные через каждый временной интервал подписываются эмитентом. В сертификатах имена субъекта и издателя являются различимыми именами (англ. Distinguished Names), как определено в системном каталоге Х.500.
20.Механизм аутентификации с использованием сертификата открытого ключа.
Аутентификацию при помощи сертификатов обеспечивают несколько распространенных протоколов, в частности, наиболее известный и широко распространенный протокол Secure Socket Layer (SSL), который применяется практически в каждом web-браузере. Помимо него применяются протоколы Transport Layer Security (TLS) Рис. 2.5 иллюстрирует типичный обмен сообщениями при аутентификации на базе сертификатов, использующий цифровые подписи [70]. Обмен соответствует стандарту аутентификации субъектов на основе криптографии с открытыми ключами [117]. Во многих протоколах предусматривается, что клиент направляет запрос серверу для того, чтобы инициировать аутентификацию. Такой подход, характерный, например, для дополнений аутентификации и шифрования к протоколу Internet File Transfer Protocol, гарантирует, что и пользователь, и сервер поддерживают один и тот же механизм аутентификации. Некоторые протоколы не требуют этого подготовительного шага.
Если сервер В поддерживает метод аутентификации, запрашиваемый пользователем А, то начинается обмен сообщениями. Сообщение Token ID уведомляет о том, что будет выполняться взаимная аутентификация, а также содержит номер версии протокола и идентификатор протокола. Хотя этот идентификатор не обязателен, он намного упрощает процедуру и поэтому обычно используется. Пользователь А ожидает сообщение Token ВА1 от сервера В. Идентификатор протокола в Token ID позволяет пользователю А удостовериться, что сервер В отправляет ожидаемое сообщение. Token ВА1 состоит только из случайного числа ran B, это - своего рода запрос, корректным ответом должна быть цифровая подпись числа ran B. Пользователь А подписывает ответ и отправляет свой сертификат ключа подписи, для того чтобы сервер В при помощи открытого ключа мог выполнить валидацию подписи.
Пользователь А подписывает последовательность из трех элементов: свой запрос ran A, запрос сервера ran B и имя сервера name B. Ran A - это запрос А к серверу В, гарантирующий, что пользователь А подписывает не произвольное сообщение сервера В или другого субъекта, выдающего себя за сервер В. Получив ответ Token АВ от пользователя А, сервер В проверяет, совпадает ли значение ran B с соответствующим значением в сообщении Token ВА1, а по значению name В устанавливает, действительно ли пользователь А желает пройти аутентификацию сервера В. Если какая-либо из проверок дает отрицательный результат, то и аутентификация завершается неудачно. В противном случае сервер В проверяет подлинность сертификата пользователя А и его цифровую подпись, если сертификат и подпись валидны, то аутентификация пользователя А сервером В прошла успешно. Ответ сервера В пользователю А завершает взаимную аутентификацию.
Ответ сервера Token ВА2 состоит из заверенной цифровой подписью последовательности трех элементов: ran A, ran B и name A, где ran A - запрос, сгенерированный А, ran B - исходный запрос сервера В, а name A - имя пользователя А. Получив ответ сервера, пользователь А убеждается, что ran A имеет то же самое значение, что и в сообщении Token АВ, а проверяя значение name A - что сервер В намерен аутентифицировать именно его (пользователя А ). Если какая-либо из проверок дает отрицательный результат, то и аутентификация завершается неудачно. В противном случае пользователь А проверяет подлинность сертификата сервера В и его цифровой подписи. Если они валидны, то пользователь А аутентифицировал сервер В, и взаимная аутентификация выполнена.
21.Логическая структура и компоненты PKI.
22.Организация защищенного удаленного доступа.
Протокол РРР имеет встроенные средства, которые могут быть использованы для организации аутентификации при удаленном взаимодействии. В стандарте RFC 1334 определены два протокола аутентификации: • по паролю — PAP (Password Authentication Protocol); • по рукопожатию — CHAP (Challenge Handshake Authentication Protocol).
К наиболее популярным протоколам централизованного контроля доступа к сети удаленных пользователей относятся протоколы TACACS (Terminal Access Controller Access Control System) и RADIUS (Remote AuthenticationDial-In User Service). Они предназначены в первую очередь для организаций, в центральной сети которых используется несколько серверов удаленного доступа. В этих системах администратор может управлять БД идентификаторов и паролей пользователей, предоставлять им привилегии доступа и вести учет обращений к системным ресурсам.
Протоколы TACACS и RADIUS требуют применения отдельного сервера аутентификации, который для проверки подлинности пользователей и определения их полномочий может использовать не только собственную БД, но и взаимодействовать с современными службами каталогов, например с NDS (Novell Directory Services) и Microsoft Windows NT Directory Service. Серверы TACACS и RADIUS выступают в качестве посредников между серверами удаленного доступа, принимающими звонки от пользователей, с одной стороны, и сетевыми ресурсными серверами — с другой. Реализации TACACS и RADIUS могут также служить посредниками для внешних систем аутентификации.
23.Протокол аутентификации РАР.
Суть работы протокола РАР довольно проста. В процессе аутентификации участвуют две стороны — проверяемая и проверяющая. Протокол РАР использует для аутентификации передачу проверяемой стороной идентификатора и пароля в виде открытого текста. Если проверяющая сторона обнаруживает совпадение идентификатора и пароля с записью, имеющейся у него в БД легальных пользователей, то процесс аутентификации считается успешно завершенным, после чего проверяемой стороне посылается соответствующее сообщение. В качестве стороны, чья подлинность проверяется, как правило, выступает удаленный пользователь, а в качестве проверяющей стороны — сервер удаленного доступа.
Для инициализации процесса аутентификации на базе протокола РАР сервер удаленного доступа после установления сеанса связи высылает удаленному компьютеру пакет LCP (Link Control Protocol) — протокол управления каналом, указывающий на необходимость применения протокола РАР. Далее осуществляется обмен пакетами РАР. Удаленный компьютер передает по каналу связи проверяющей стороне идентификатор и пароль, введенные удаленным пользователем. Сервер удаленного доступа по полученному идентификатору пользователя выбирает эталонный пароль из БД системы защиты и сравнивает его с полученным паролем. Если они совпадают, то аутентификация считается успешной, что сообщается удаленному пользователю.
24.Протокол аутентификации СНАР.
В протоколе CHAP используется секретный статический пароль. В отличие от протокола РАР, в протоколе CHAP пароль каждого пользователя для передачи по линии связи шифруется на основе случайного числа полученного от сервера. Такая технология обеспечивает не только защиту пароля от хищения, но и защиту от повторного использования злоумышленником перехваченных пакетов с зашифрованным паролем. Протокол CHAP применяется в современных сетях гораздо чаще, чем РАР, так как он использует передачу пароля по сети в защищенной форме, и, следовательно, гораздо безопаснее.
Шифрование пароля в соответствии с протоколом CHAP выполняется с помощью криптографического алгоритма хэширования и поэтому является необратимым. В стандарте RFC 1334 для протокола CHAP в качестве хэш-функции определен алгоритм MD5, вырабатывающий из входной последовательности любой длины 16-байтовое значение. Хотя минимальной длиной секрета является 1 байт, для повышения криптостойкости рекомендуется использовать секрет длиной не менее 16 байт. Спецификация CHAP не исключает возможность использования других алгоритмов вычисления хэш-функций.
Для инициализации процесса аутентификации по протоколу CHAP сервер удаленного доступа после установления сеанса связи должен выслать удаленному компьютеру пакет LCP, указывающий на необходимость применения протокола CHAP, а также требуемого алгоритма хэширования. Если удаленный компьютер поддерживает предложенный алгоритм хэширования, то он должен ответить пакетом LCP о согласии с предложенными параметрами. В противном случае выполняется обмен пакетами LCP для согласования алгоритма хэширования.
После этого начинается аутентификация на основе обмена пакетами протокола CHAP.
25.Протокол аутентификации S/Key.
Одним из наиболее распространенных протоколов аутентификации на основе одноразовых паролей является стандартизованный в Интернете протокол S/Key (RFC 1760). Этот протокол реализован во многих системах, требующих проверки подлинности удаленных пользователей, в частности в системе TACACS+ компании Cisco.
Перехват одноразового пароля, передаваемого по сети в процессе аутентификации, не предоставляет злоумышленнику возможности повторно использовать этот пароль, так как при следующей проверке подлинности необходимо предъявлять уже другой пароль. Поэтому схема аутентификации на основе одноразовых паролей, в частности S/Key, позволяет передавать по сети одноразовый пароль в открытом виде и, таким образом, компенсирует основной недостаток протокола аутентификации РАР.
Однако следует отметить, что протокол S/Key не исключает необходимость задания секретного пароля для каждого пользователя. Этот секретный пароль используется только для генерации одноразовых паролей. Для того чтобы злоумышленник не смог по перехваченному одноразовому паролю вычислить секретный исходный пароль, генерация одноразовых паролей выполняется с помощью односторонней, т. е. необратимой, функции. В качестве такой односторонней функции в спецификации протокола S/Key определен алгоритм хэширования MD4 (Message Digest Algorithm 4). Некоторые реализации протокола S/Key в качестве односторонней функции используют алгоритм хэширования MD5 (Message Digest Algorithm 5).
Иногда желательно, чтобы пользователь имел возможность сам назначать секретный постоянный пароль. Для осуществления такой возможности спецификация S/Key предусматривает режим вычисления одноразовых паролей не только на основе секретного пароля, но и на основе генерируемого проверяющей стороной случайного числа. Таким образом, в соответствии с протоколом S/Key за каждым пользователем закрепляется идентификатор и секретный постоянный пароль.
Перед тем как проходить аутентификацию, каждый пользователь должен сначала пройти процедуру инициализации очередного списка одноразовых паролей, т. е. фазу парольной инициализации. Данная фаза выполняется по запросу пользователя на сервере удаленного доступа.
Для ускорения процедуры аутентификации определенное число одноразовых паролей, например несколько десятков, может быть вычислено заранее и храниться на удаленном компьютере в зашифрованном виде.
Протокол аутентификации на основе одноразовых паролей S/Key применяют, в частности, для улучшения характеристик протоколов централизованного контроля доступа к сети удаленных пользователей TACACS и RADIUS.
26.Организация централизованной аутентификации.
27.Система TACACS.
28.Система RADIUS.
29.Статические биометрические системы аутентификации (по отпечатку пальца, по
форме ладони, по лицу, по радужной оболочке и сетчатке глаз).
30.Динамические методы аутентификации.
31.Сравнительная характеристика основных биометрических методов.
32.Способы защиты операционной системы от парольных взломщиков.
33.Назначение цифрового сертификата и его структура.
34.Суть атаки "человек в середине".
35.Базовые модели систем сертификации, их достоинства и недостатки.
36.Защита сообщений в протоколе RADIUS.
37.Классификация систем РЧИ и области применения.
38.Принципы работы низкочастотных систем РЧИ.
39.Принципы работы высокочастотных систем РЧИ.
40.Преимущества и недостатки радиочастотной идентификации.
41. Правила парольной защиты.
42. Принцип работы контроллера Кляйна.
43.Программа вскрытия паролей архивированных документов (ARCHPR)?
44. Программа аудита и восстановления паролей SAMInside.
45. Использование BIOS для защиты от взлома пользовательского пароля.
46. Использование сервисов безопасности ОС Windows для защиты пользовательского пароля.
47. Принцип работы утилиты SYSKEY.
48. Использование сертификатов для идентификации WEB-узлов.
49. Использование сертификатов для проверки подлинности программного обеспечения.
50. Использование сертификатов для цифровой подписи сообщений электронной почты.
51. Порядок проверки подлинности цифрового сертификата.