Добавил:
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Курсовые / Протоколы защиты.doc
Скачиваний:
37
Добавлен:
16.04.2013
Размер:
262.66 Кб
Скачать

Цепочки сертификатов

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

Корневой центр сертификации.

Как говорилось ранее, каждый сертификат требует, чтобы изготовитель подтвердил идентификацию субъекта сертификата, вплоть до корневого сертификационного центра. Это представляет проблему: кто поручится за сертификат корневого центра, который не имеет изготовителя? В данном случае, сертификат производится «самовыпуском», так что изготовитель и субъект сертификата совпадают. В результате человек должен проявлять дополнительную осторожность, доверяя самовыпущенному сертификату. Широкая публикация открытых ключей корневым центром сокращает риск при доверии данным ключам – становится очевидным, если кто-то публикуют ключи, заверяя, что он тот же центр. Пользовательские агенты настроены на доверие хорошо известным сертификационным центрам.

Некоторые компании, такие как ThawteиVeriSignоснованы как сертификационные центры. Такие компании предоставляют следующие услуги:

  • проверка запросов сертификатов

  • обработка запросов сертификатов

  • выпуск и управление сертификатами

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

Протокол«рукопожатия»

Протокол Secure Sockets Layer(SSL) использует комбинацию симметричных и асимметричных алгоритмов шифрования. Симметричные алгоритмы значительно быстрее асимметричных, но последние обеспечивают лучшие средства аутентификации. СеансSSLвсегда начинается с обмена сообщениями, называемым «рукопожатием» (SSLhandshake). «Рукопожатие» позволяет серверу подтвердить свою подлинность клиенту, используя приемы алгоритмов с открытым ключом, а затем позволяет клиенту и серверу взаимодействовать для создания симметричного ключа, используемого для быстрого шифрования и расшифровывания данных, а также обнаружения вмешательства во время сеанса. Также во время рукопожатия сервер может проверять подлинность клиента.

«Рукопожатие» SSLсостоит из следующих шагов:

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

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

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

  4. Используя данные, сгенерированные на предыдущих шагах, клиент (взаимодействуя с сервером в зависимости от используемого им шифра) создает предглавный ключ для сеанса, шифрует его на открытом ключе сервера (полученном с сертификатом сервера на шаге 2) и отправляет серверу зашифрованный предглавный ключ.

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

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

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

  8. Клиент посылает сообщение серверу, информируя, что последующие сообщения будут зашифрованы сеансовым ключом. Затем отдельно он посылает зашифрованное сообщение о завершении клиентской части «рукопожатия».

  9. Сервер отправляет сообщение клиенту, информируя его, что последующие сообщения будут зашифрованы сеансовым ключом. Затем отдельно отправляется зашифрованное сообщение, сигнализирующее о завершении серверной части «рукопожатия».

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

  11. Это нормальное состояние защищенного канала. В любое время, по внутренним или внешним причинам, любая сторона может перенастроить соединение, в данном случае процедура повторяется.

Тут вы можете оставить комментарий к выбранному абзацу или сообщить об ошибке.

Мы не исправляем ошибки в тексте (почему?), но будем благодарны, если вы все же напишите об ошибках.