Polnaya_metodichka

Рис. 2. Формат ESP-пакета без аутентификации

Далее размещается поле зашифрованных данных, для выравнивания его длины до кратного размеру блока шифрования может использоваться поле заполнитель. После поля заполнителя размещается хвостовик, содержащий два поля: длины заполнителя (Pad len) и кода следующего заголовка (Next hdr).

Документы RFC IPsec не регламентируют конкретный алгоритм шифрования, но допускают использование DES, triple-DES, AES и Blowfish для шифрования поля данных.

Помимо шифрования, ESP может опционально предоставлять возможность аутентификации, с привлечение алгоритма HMAC. В отличие от AH, однако, эта аутентификация производится только для ESP заголовка и зашифрованного поля данных. При этом не перекрывается весь IP пакет.

Управление ключами

Система IKE (Internet Key Exchange) позволяет двум партнерам динамически аутентифицировать друг друга, согласовать использование ассоциации безопасности (Security Association), включая секретные ключи, и генерировать сами ключи. Система IKE

использует ISAKMP (Internet Security Association Key Management Protocol – протокол управления ключами ассоциации безопасности Интернет. Протокол ISAKMP сам по себе не регламентирует какой-либо конкретный алгоритм обмена ключами, он содержит в себе описание ряда сообщений, которые позволяют согласовать использование алгоритмов обмена ключами.

Механизм обмена ключами в IKE берется из протокола Oakley. Основой протокола обмен ключами Oakley является алгоритм Диффи-Хелмана, дополненный некоторыми усовершенствованиями.

В IPsec при обмене ключами предусмотрено использование сертификатов. Для получения сертификата посылается запрос в сертификационный центр СА (Certificate Authority).

29. Защищенные сетевые протоколы. Протокол SSL.

SSL (англ. Secure Sockets Layer — уровень защищённых сокетов) — криптографический протокол, который обеспечивает установление безопасного соединения между клиентом и сервером. Протокол обеспечивает конфиденциальность обмена данными между клиентом и сервером, использующими TCP/IP, причём для шифрования используется асимметричный алгоритм с открытым ключом.

SSL предоставляет канал, имеющий 3 основных свойства:

Аутентификация. Сервер всегда аутентифицируется, в то время как клиент аутентифицируется в зависимости от алгоритма.

Целостность. Обмен сообщениями включает в себя проверку целостности.

Конфиденциальность канала. Шифрование используется после установления соединения и используется для всех последующих сообщений.

Типы сертификатов

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

Есть три способа получить SSL-сертификат:

1.использовать сертификат от источника сертификатов;

2.использовать самоподписанный сертификат;

3.использовать "пустой" сертификат

Использование сертификата от источника сертификатов

Источники сертификатов (CA) - это организации, которым доверяет вся отрасль и которые занимаются выдачей Интернет-сертификатов. Например, такой сертификат можно получить от компании VeriSign. Чтобы получить сертификат, подписанный источником, необходимо предоставить достаточно информации источнику, чтобы он смог проверить вашу личность. Тогда источник создаст новый сертификат, подпишет его и доставит его вам.

Использование самоподписанного сертификата

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

Использование "пустого" сертификата

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

Структура

Цифровой сертификат содержит следующие фрагменты информации о личности владельца сертификата и источнике сертификатов:

полное (уникальное) имя владельца сертификата;

публичный ключ владельца;

дата выдачи цифрового сертификата;

дата окончания действия сертификата;

полное (уникальное) имя издателя (источника сертификата);

цифровая подпись издателя.

Подключение по SSL всегда инициируется клиентом вызовом URL-адреса, начинающегося с https:// вместо http://.

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

После того как сертификат был получен, необходимо установить его подлинность (аутентифицировать). В протоколе SSL есть два типа аутентификации:

аутентификация на стороне клиента;

аутентификация на стороне сервера.

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

Сертификат имеет следующий вид

Следующая диаграмма показывает шаги, необходимые для установки защищенной сессии по протоколу SSL.

30. Защищенные сетевые протоколы. Протокол SET.

Протокол SET (Secure Electronic Transaction) был разработан консорциумом во главе с Visa и Master Card. Официальной датой рождения стандарта SET является 1

февраля 1996 г. В этот день Visa International и MasterCard International совместно с рядом технологических компаний (включая IBM, GlobeSet) объявили о разработке единого открытого стандарта защищенных Интернет-расчетов. SET представляет собой набор протоколов, предназначенных для использования другими приложениями (такими, как Web-браузер). Он был рекомендован как стандарт обработки транзакций, связанный с расчетами за покупки по кредитным картам в Интернет.

В декабре 1997 г. была создана некоммерческая организация SETCo LLC, призванная координировать работы по развитию стандарта и осуществлять тестирование и сертификацию предлагаемого на рынке программного обеспечения с целью контроля над соответствием этого программного обеспечения спецификациям SET.

В основе системы безопасности, используемой SET, лежат стандартные криптографические алгоритмы DES (Data Encryption Standard — стандарт шифрования данных) и RSA (Rivest-Shamir-Adleman — алгоритм цифровой подписи Райвеста-Шамира- Адлемана). Инфраструктура SET построена в соответствии с инфраструктурой открытого ключа (Public Key Infrastructure, PKI) на базе сертификатов, соответствующих ISOстандарту X.509.

Протокол SET не привязан ни к HTTP, ни к Web-коммерции. Его можно использовать с самыми различными протоколами. SET шифрует сами сообщения, а не канал связи, как, например. SSL.

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

Владелец карточки и магазин устанавливают у себя программное обеспечение - Cardholder Wallet и Merchant Server соответственно. Эквайер должен установить себе Payment Gateway.

Всем участникам необходимо получить Certificate Authority так называемые сертификаты, которые используются для формирования цифровых подписей и шифрования данных. Для этого участники запрашивают и получают сертификаты от сертифицирующих организаций (SETCo). SET-сертификат Интернет-Магазина содержит идентификационные параметры торговой точки. SET-сертификат Покупателя – это электронный документ, который содержит зашифрованные параметры платежной карты (её номер, имя владельца и т. д.).

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

Преимущества использования SET:

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

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

клиенты не пострадают от перехвата номера кредитки и от покупки у несуществующих продавцов.

Недостатки использования SET:

Дороговизна решения и высокие эксплуатационные расходы

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

Очень существенный минус в том, что владельцу карточки требуется установить на свой компьютер довольно сложный в настройке Cardholder Wallet.

Оригинальный SET предполагает, что все участники платежа в Интернете (владелец карточки, магазин, банк-эквайер) получили в Certificate Authority так называемые сертификаты, что существенно усложняет процедуру покупки и приводит к удорожанию транзакций. Стандарт MIA SET - это несколько

упрощенный вариант протокола SET (Secure Electronic Transaction).

Полноценное использование SET-технологий, предполагает наличие SETсертификатов у всех участников сделки. Но существует также упрощённый вариант – технология MIA SET, которая также признана международными платёжными систeмами.

MIA SET предполагает, что владельцу карточки и магазину не нужно устанавливать у себя сложного программного обеспечения. Фактически, Cardholder Wallet перекочевывает на сервер эмитента, а Merchant Server - на сервер эквайера. Эмитент и эквайер обмениваются между собой по SET от имени владельца карточки и магазина. Эмитент при этом может на свое усмотрение использовать любые средства идентификации владельца карточки (пароль, смарт-карта и т.д.). Это же правило распространяется и на эквайера при идентификации магазина. Благодаря этому MIA SET более прост во внедрении и эксплуатации чем традиционный SET.

Важно отметить, что Visa объявила о том, что некогда популярный протокол SET уже не отвечает современным требованиям безопасности и должен быть замещен более совершенными системами, такими как — Verified by Visa, работающий на основе протокола 3D Secure и Secure Payment Application (SPA) от MasterCard.