на тему рефераты Информационно-образоательный портал
Рефераты, курсовые, дипломы, научные работы,
на тему рефераты
на тему рефераты
МЕНЮ|
на тему рефераты
поиск
Политика безопасности баз данных
b>4.3 Обеспечение надежного пути

4.3.1 Способы обеспечения надежного пути

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

Для обеспечения такой уверенности необходимо реализовать механизмы безопасного распределения ключами.

Распределение может осуществляться двумя способами:

1. Путем создания центра генерации и распределения ключей;

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

Недостатки первого подхода:

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

компрометация центра распределения приводит к компрометации всей передаваемой между абонентами этого центра информации.

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

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

Подтверждение достоверности абонентов может осуществляться таким образом:

1. Непосредственно между абонентами.

2. С использованием посредника (арбитра).

3. С использованием двух и более посредников.

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

в распределенных сетях, которые насчитывают не один десяток абонентов такой обмен осложняется;

возможна атаки "человек посередине".

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

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

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

4.3.2 Общие подходы использования сертификатов в web-технологиях

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

открытый ключ web-сервера;

даты достоверности (начала и окончания);

поддерживаемые алгоритмы шифровки

уникальное имя (Distinguish Name - DN), которое должно содержать полностью определенное доменное имя web-сервера, званое общим именем (Common Name - CN). Опционально DN может содержать и некоторые другие атрибуты, например, страну (Country - С), штат (State - S), Расположение (Location - L), назову организации (Organization's name - ON), назову службы организации (Organization Unit's name - OU), и другие.

серийный номер сертификата;

атрибуты X.509v3, которые будут сообщать web-навигатору о типе и употреблении

имя и подпись доверенного источника сертификатов (Certification Authority - CA)создание сертификатов можно использовать утилиту ореnssl, которая включает много сервисов по криптографическим алгоритмам.

Существует три типа сертификатов, которые можно использовать в web-технологиях:

1. Самоподписанный сертификат.

2. Сертификат, подписанный доверенным центром сертификации (CA).

3. Сертификат, подписанный местным CA.

4.3.3 Создание сертификата, подписанного доверенным центром сертификации

Алгоритм создания сертификата имеет следующие шаги:

Шаг 1. Создание пара закрытого/открытого ключа (файл server. key) и запроса сертификата (файл request. pem):

ореnssl req - new - sha1 - newkey rsa: 1024 - nodes - keyout server. key - out request. pem \

subj '/O=BANK /OU=KARAMANOV. BANK /CN=www.karamanov. bank. od.ua'

Сертификат также может быть подписан алгоритмами: md5, sha1, md2, mdc2.

Для проверки подписи запроса на сертификат, расположенного в файле request. pem, и просмотр содержания запроса в текстовом виде использовать команды: ореnssl req - іn request. pem - text - verify -noout

Параметр "-text" позволяет вывести содержание сертификата в текстовом виде, параметр "verify" проверяет подпись запроса, созданную по алгоритму SHA1.

Шаг 2. Отсылка запроса на получение сертификата (request. pem) в СА и ожидание, пока он будет подписан и отослан назад в виде сертификата.

Шаг 3. По получении сертификата от доверенного СА необходимо удостовериться в том, что он закодирован в формате PEM, а не TXT или DER. Если же полученный сертификат не отвечает формату РЕМ, то необходимо конвертировать его в каком бы формате он не пришел. Команда для конвертации формата TXT + PEM в РЕМ:

ореnssl x509 -іn server. pem - out server. Crt

Шаг 4. Верификация и тестирование сертификата

Необходимо убедиться в том, что сертификат отвечает раньше созданному закрытому ключу, на основании выполненных команд (результаты выполнения обоих команд должны быть одинаковыми):

ореnssl x509 - noout - modulus - іn server. Crt

В вышеописанных командах параметр - modulus позволяет получить из сертификата файла

server. crt или закрытого /відкритого ключа файла server. keyвідкритий ключ. Используя конвеер данных результаты команд пропускаются через хеш-функцию. Если результаты работы двух функций одинаковые, полученный сертификат отвечает раньше созданному закрытому ключу.

4.3.4 Создание самоподписанного сертификата (сертификата местного центра сертификации)

Этот метод может быть использован в интрасетях или в организациях, которые используют или планируют использовать собственный центр сертификации (СА - Certificate Agency). В этом случае местный сертификат СА должен быть установлен на все веб-навигаторы, которые будут соединяться с безопасным web-сервером.

Для использования этого способа необходимо создать:

локальный закритий/відктритий ключ СА;

сертификат СА;

репозиторий СА для новых ключей.

Для обеспечения надежности всей системы сертификации необходимо выполнить

следующие условия:

локальный СА должен быть создан на отдельном сервере, который не имеет соединения

с сетью;

операционная система должна давать доступ только авторизованному персоналу;

сервер СА должен быть под охраной.

Частный СА ключ - самый важный элемент всей системы - если он будет компрометируемый, то все другие сертификаты, подписанные этим СА также будут

компрометируемые.

Алгоритм создания сертификата содержит следующие шаги.

Шаг 1. Подготовить структуру каталога для нового СА:

set SSLDIR=c: \ca

mkdir%SSLDIR%

mkdir%SSLDIR%\certs

mkdir%SSLDIR%\crl

mkdir%SSLDIR%\newcerts

mkdir%SSLDIR%\private

mkdir%SSLDIR%\requests

Создать текстовый файл, например, index. txt, который будет содержать информацию о

созданных сертификатах.

Создать текстовый файл, например, serial, который содержит следующее значение

идентификатору сертификата в hex-формате:

echo 01 >%SSLDIR%\serial

можно создать *. bat файл с данными командами и запустить его.

Шаг 2. Создать основной файл настроек центра сертификации

Название файла, например, openssl. cnf. Пример содержания файла (оптимизировано для

использования с SSL веб-серверами):

# =================================================

# OpenSSL configuration file

# =================================================

RANDFILE = $ENV:: SSLDIR/. rnd

[ca]

default_ca = CA_default

[CA_default]

# Название каталога CA

dir = c: \ca

# Название каталога с сертификатами

сеrts = $dir/certs

# Название каталога с новыми сертификатами, название файла в виде ідентифікатор. pem

(01. pem, 02. pem)new_certs_dir = $dir/newcerts

# Название каталога с CRL-файлами (Certificate Revocation List - Список Аннулированных

Сертификатов)crl_dir = $dir/crl

# Название текстового файла, который будет содержать информацию о созданных

сертификатах

database = $dir/index. txt

# Название текстового файла с секретным ключом CA

private_key = $dir/private/ca. key

# Название текстового файла с сертификатом CA

сеrtificate = $dir/ca. crt

# Название текстового файла, который содержит следующее значение идентификатору

сертификата в hex-формате

serial = $dir/serial

crl = $dir/crl. pem

RANDFILE = $dir/private/. rand

# Период действия сертификата

default_days = 365

# Период обновления CRL-файлов

default_crl_days = 30

# Тип хеш-функции, что используется при установлении подписи

default_md = sha1

# Тип поведения системы при определении значений DN-атрибутов сертификата

preserve = no

# название секции с характеристиками переменных, которые входят к DN-атрибутам

сертификата

policy = policy_anything

name_opt = ca_default

cert_opt = ca_default

# Секция содержит значение переменных, которые входят к DN-атрибутам сертификата менно значение, что и атрибут CA - сертификата. Если значение переменной = 'supplied', то атрибут должен содержаться в сертификате. Если значение переменной = 'optional', то атрибут может содержаться в сертификате. Атрибуты, которые не представлены в секции, будут удалены, если значение переменной preserve = on или опция - preserveDN отсутствует в командной строке.

[policy_anything]

countryName = Karamanov. Bank

stateOrProvinceName = Alexey Karaamnov

localityName = kaa

organizationName = bank

organizationalUnitName = xxx

commonName = xxxx

emailAddress = onpu@i.ua

Шаг 3. Создать пару СА закрытый/открытый ключ и самоподписанный сертификат СА:

ореnssl req \

config $SSLDIR$/openssl. cnf - new - x509 - nodes - days 3652 - sha1 - newkey rsa: 1024 \

keyout $SSLDIR$/private/ca. key - out $SSLDIR$/ca. crt \

subj

'/C=UA/ST=OdessaRegion/L=Odessa/O=Karamanov. Bank /OU=bank /CN=www.karamanov. bank. od.ua'

Команда создает новый (-new) самоподписанный root-сертификат (-x509), который будет

подписан с использованием алгоритма SHA1 (-sha1). Закрытый (частный) ключ RSA будет иметь длину 1024 бит (-newkey rsa: 1024), не будет защищен парольной фразой (-nodes). Запрос на сертификат, что включает открытый ключ, будет содержаться в файле request. pem, а закрытый ключ будет создан в файле "server. key". Параметр "-subj" говорит о том, что сертификат создан для компании, которая расположена в Украине (C=UA), в одесском регионе (ST=OdessaRegion), название компании "ONPU" (O=ONPU), название службы "kaf_SPO" (OU=kaf_SPO), и полностью определенное доменное имя "www.spo. ospu. odessa.ua" #@:. Сертификат может использоваться 10 лет #@;

После выполнения команды будут созданы файлы:

файл ca. key с закрытым ключом центра сертификации;

файл ca. crt с сертификатом.

создали закрытый ключ:

создали сертификат:

4.3.5 Подписание сертификатов с использованием сертификата центра сертификации

Для создания сертификата необходимо выполнить следующие шаги:

Шаг 1. Создать пар закрытый/открытый ключ веб-сервера (файл web_server. key), и запрос на сертификат (файл web_request. pem), используя команды:

ореnssl req - new - sha1 - newkey rsa: 1024 - nodes - keyout web_server. key - out web_request. pem \

subj '/O=karamanov. bank /OU=web-server/CN= www.karamanov. bank. od.ua'

Шаг 2. Скопировать запрос на сертификат (файл web_request. pem) в директорию $SSLDIR/requests на узле центра сертификации.

Шаг 3. Подписать запрос на сертификат:

ореnssl ca - cert%SSLDIR%/server. crt - keyfile%SSLDIR%/server. key \

config%SSLDIR%/openssl. cnf - policy policy_anything \

noemailDN - out%SSLDIR%/requests/signed. pem \

infiles%SSLDIR%/requests/web request. Pem

В результате выполнения этих команд будет подписан сертификат (файл signed. pem), который будет находится в каталоге $SSLDIR/newcerts, и в файле $SSLDIR/signed. pem.

4.3.6 Аннулирование сертификатов

Для местных СА в случае компрометации сертификата строго рекомендуется аннулировать сертификат и информировать пользователей о том, что сертификат больше не действительный. Для аннулирования сертификата необходимо отыскать его серийный номер в файле $SSLDIR/index. txt.

V 031237770121C 01 unknown /O=alexey. karamanov/OU=web_server/CN=karamanov. bank. od.ua'

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

ореnssl ca - config $SSLDIR/openssl. cnf - revoke $SSLDIR/newcerts/01. pem

Для создания CRL-файла (Certificate Revocation List - Список Аннулированных Сертификатов), необходимо выполнить команды:

ореnssl ca - config $SSLDIR/openssl. cnf - gencrl - crlexts crl_ext - md sha1 - out $SSLDIR/crl. Pem

Этот файл должен быть опубликован на сайте центра сертификации. В процессе распространения CRL-файлов также рекомендуется использовать Online Certificate Status Protocol (OCSP).

4.3.7 Создание клиентского сертификата

Создание личного клиентского сертификата очень похоже на создание сертификата web - сервера. Единственное отличие заключается в том, что используются другие расширения X.509v3 (секция "ssl_client" с openssl. cnf), а формат хранения закрытого ключа и сертификата - PKCS#12

(также называется PFX). Действия, которые необходимо выполнить для создания клиентского сертификата:

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

ореnssl req - new - sha1 - newkey rsa: 1024 - nodes - keyout client. key \

out request. pem - subj '/O=bank /OU=karamanov. bank/CN=director

Шаг 2. Послать запрос на сертификат (request. pem) в сервер местного центра СА для подписи.

Шаг 3. Задача местного СА - проверить или правильно пользователь заполнил поля в запросе на сертификат.

Шаг 4. После верификации запрос на сертификат (request. pem) скопировать в каталог $SSLDIR/requests на сервере СА.

Шаг 5. Местный СА должен подписать сертификат, используя команды:

ореnssl ca \

plain-config $SSLDIR/openssl. cnf - policy policy_anything - еxtensions ssl_client \

plain-out $SSLDIR/requests/signed. pem - іnfiles $SSLDIR/requests/request. pem

Шаг 6. Отослать пользователю подписанный сертификат (signed. pem).

Шаг 7. По получении подписанного сертификата пользователю необходимо сберечь закрытый ключ вместе с сертификатом в формате PKCS#12, используя команды:

ореnssl pkcs12 - еxport - clcerts - іn signed. pem - іnkey client. key - out client. p12

Список литературы

1. Бабаш А.В., Гольев Ю.И., Ларин Д.А., Шанкин Г.П. О развитии криптографии в XIX веке // Защита информации. Конфидент. №5, 2003, с.90-96. (http://www.agentura.ru)2. Гольев Ю.И., Ларин Д.А., Тришин А.Е., Шанкин Г.П. Криптографическая деятельность в США XVIII-XIX веков. // Защита информации. Конфидент. №6, 2004, с.68-74.

3. Тейер Т., Липов М., Нельсон Э. Надежность программного обеспечения. - Пер. с англ. - М.: Мир, 1981.

4. Липаев В.В. Надежность программных средств. - М.: Синтег, 1998.

5. Кузнецов И.Н. Научные работы: методика подготовки и оформления. - Минск, 2000.

6. Понимание SQL. Мартин Грубер, Вильямс, 2003.

Страницы: 1, 2, 3, 4


© 2003-2013
Рефераты бесплатно, курсовые, рефераты биология, большая бибилиотека рефератов, дипломы, научные работы, рефераты право, рефераты, рефераты скачать, рефераты литература, курсовые работы, реферат, доклады, рефераты медицина, рефераты на тему, сочинения, реферат бесплатно, рефераты авиация, рефераты психология, рефераты математика, рефераты кулинария, рефераты логистика, рефераты анатомия, рефераты маркетинг, рефераты релиния, рефераты социология, рефераты менеджемент.