Технологии защищенной связи
Необходимость в защищенной связи
В электронной коммерции очень трудно обойтись без специальных средств обеспечения защищенной связи. Защита данных нужна обеим сторонам, особенно на этапе совершения сделки и использования платежных средств.
При покупке товаров в Интернете с помощью платежных карт клиент должен убедиться в том, что он имеет дело именно с продавцом, а не с лицом, выдающим себя за него, и быть уверен, что переданные им данные не станут доступны никому, кроме партнера, которому они адресованы. Со своей стороны поставщик электронных услуг должен быть уверен, что он поставляет их именно тому лицу, которое их оплатило.
Особую роль система защищенной связи играет во взаимоотношении клиентов и банков. Клиент должен быть уверен в том, что он имеет дело с банком, а банк должен быть уверен в том, что он получает указания на управление счетом от лица, правомочного им распоряжаться.
Технологии защиты данных на путях транспортировки
Сегодня в Интернете и World Wide Web обычно используют две технологии защищенной связи: SHTTP (Secure HTTP) и SSL (Secured Socket Layer), — обе закреплены стандартами. Это не альтернативные технологии — они действуют на разных уровнях и даже могут применяться совместно (SHTTP поверх SSL).
Протокол SSL — это сеансовый протокол, он занимает промежуточное место между прикладными протоколами (HTTP, FTP, SMTP и другими) и транспортным протоколом TCP. Это означает, что с его помощью создается защищенный канал связи (туннель), внутри которого можно работать с любой службой Интернета: WWW, службой передачи файлов, электронной почтой и другими.
Протокол SHTTP - это расширение прикладного протокола HTTP. Это означает, что им пользуются только для защищенной связи в WWW при взаимодействии Web-сервера и броузера. В двух словах разницу между SHTTP и SSL можно сформулировать так: с помощью SHTTP можно отправить одно защищенное сообщение (серверу или клиенту), а с помощью SSL можно создать защищенный сеанс, в рамках которого можно обмениваться многократными сообщениями.
Есть еще такой подход: если нужно отправить защищенное сообщение от клиента к серверу, например при заполнении Web-формы или вводе пароля, то можно ограничиться протоколом SHTTP, а если есть необходимость в двустороннем обмене данными, например при взаимодействии с банком или электронной платежной системой, то используют SSL.
В электронной коммерции наиболее широко применяется протокол SSL. Программные средства, реализующие его, основаны на криптографии, как и средства ЭЦП, однако сама криптографическая система, лежащая в основе 551, является гибридной — в ней сочетаются несимметричные и симметричные алгоритмы шифрования, причем сами алгоритмы могут быть любыми — это зависит от конкретных программных средств. Простейшая модель работы 551-соединения такова: сначала стороны обмениваются своими открытыми ключами, затем, используя открытые , ключи партнеров, приступают к созданию закрытого канала связи и совместно вырабатывают общий симметричный ключ шифрования, с помощью которого в дальнейшем обмениваются данными. Этот симметричный ключ одноразовый и называется сеансовым ключом. Теоретически, партнеры, конечно, могли бы и не создавать совместный симметричный ключ и ограничиться только несимметричными методами криптографии, но они очень медленны. Их хорошо использовать для однократной операции, например для проверки ЭЦП партнера и целостности сообщения, но для двусторонней связи симметричные ключи удобнее, к тому же их криптостойкость намного выше. Одноразовость же сеансового ключа необходима, чтобы промежуточные серверы, участвующие в сеансе, не имели достаточного времени для его компрометации. В следующем сеансе связи сеансовый ключ неизбежно будет новым.
Протокол SSL в электронных банковских технологиях
Основная потребность в защищенной связи возникает при проведении банковских операций, поэтому более подробно работу протокола 55Z мы рассмотрим на модели взаимодействия Банк — Клиент в Интернете. Хотя еще далеко не все банки готовы к предоставлению услуг дистанционного обслуживания клиентов, развитие электронной коммерции постепенно вынуждает их к внедрению новых систем.
Протокол 55i состоит из двух компонентов. Первый — это протокол установления защищенной связи (протокол взаимодействия), и второй — протокол защищенного обмена данными (протокол обмена).
Установление защищенной связи. Протокол взаимодействия предполагает обмен специальными сообщениями между программными средствами сервера и клиента, в ходе которого эти средства настраиваются для совместной работы. Вот как это происходит (см. рис. 10.19).
1. Клиентская программа, обеспечивающая связь по протоколу 551, отправляет серверу свое название и номер версии, а также сообщает о некоторых настройках своих средств шифрования, необходимых для взаимодействия с сервером.
2.Серверная программа, обеспечивающая связь по протоколу 551, отправляет клиенту свое название, номер версии и сведения о настройках системы шифрования. Кроме того, сервер отправляет клиенту сертификат своего публичного ключа, а если этого требуют взаимоотношения, то запрашивает и сертификат открытого ключа клиента (при связи клиента с банком это необходимо всегда).
3.По данным, полученным от сервера, клиент производит его идентификацию с помощью публичного ключа сервера (ключ прилагается к сертификату). Если идентификация не происходит, клиент получает предупреждение и процедура установки соединения завершается. Если сервер успешно идентифицируется, работа продолжается.
4.Обе стороны сравнивают свои программные средства шифрования. Эти средства могут использовать разные алгоритмы как для несимметричного, так и для симметричного шифрования. Они выбирают наилучшие алгоритмы из числа доступных обеим сторонам. Если участники связи расположены в разных странах, то в ходе этого согласования они учитывают особенности национального законодательства (экспортно-импортные, лицензионные и другие ограничения технологий шифрования) и применяют наилучшие алгоритмы из разрешенных.
Если средство для дистанционного банковского обслуживания клиенту поставил сам банк, то, скорее всего, на данном этапе программам нечего согласовывать — они уже предварительно настроены на использование нужных алгоритмов.
5.Используя данные, полученные в ходе первичного обмена, и с учетом того средства шифрования, которое было согласовано обеими сторонами, клиентская программа создает заготовку ключа настройки (premaster secret), затем шифрует ее открытым ключом сервера, взятым из сертификата. Зашифрованная заготовка отправляется серверу.
6.Если серверу необходима идентификация клиента, то клиент подписывает своим закрытым ключом некоторую известную серверу последовательность данных, полученных в ходе первичного контакта. Он отправляет этот образец подписи вместе с заготовкой ключа настройки.
7.Чтением образца подписи клиента с помощью его открытого ключа сервер убеждается в том, что клиент — тот, за кого себя выдает. Если клиент не идентифицируется, сеанс прекращается. Если клиент идентифицируется корректно, сервер расшифровывает заготовку ключа настройки с помощью своего закрытого ключа. Далее сервер выполняет последовательность шагов, в результате которой из заготовки ключа настройки получается ключ настройки (master secret). Клиентская программа в это время выполняет ту же последовательность действий и получает тот же ключ настройки.
8.Далее обе стороны порознь используют ключи настройки для генерации одинаковых сеансовых ключей. Сеансовые ключи — симметричные. Один и тот же ключ используется для шифрования и дешифрования данных в ходе сеанса SSL, а также для проверки целостности сообщений. Таким образом проверяется неизменность данных в ходе транспортировки.
9. Сгенерировав сеансовый ключ, клиент отправляет серверу сообщение о том, что далее он будет им пользоваться. Одновременно он отправляет сообщение, зашифрованное этим ключом, в котором сказано, что процедура установления связи завершена.
10.Сервер отправляет клиенту сообщение о том, что далее в обмене он будет использовать сеансовый ключ. Одновременно он отправляет зашифрованное этим ключом сообщение о том, что серверная часть процедуры создания защищенного канала связи завершена.
11.На этом завершается первая часть работы протокола SSL (протокола взаимодействия) и стороны переходят ко второй части — протоколу обмена данными.
С этого момента они используют сеансовые ключи для шифрования данных и проверки их целостности.
Как видите, этап установления связи происходит при использовании несимметричных технологий шифрования. Его цель — провести идентификацию партнеров и создать сеансовый ключ для симметричного шифрования.
Сервер идентифицируется тем, что клиент шифрует заготовку ключа настройки с помощью открытого ключа сервера. Только тот, кто законно владеет соответствующим ему закрытым ключом, сможет восстановить ключ настройки, а без него невозможно создать тот же сеансовый ключ, который создаст клиент.
Идентификация клиента происходит с помощью его цифровой подписи, которой он подписывает некий случайный набор данных. Открытый ключ клиента, приложенный к его сертификату, сможет правильно открыть цифровую подпись только в том случае, если клиент использовал законный закрытый ключ.
Идентификация сервера по открытому ключу. Клиент получает от сервера его открытый ключ вместе с сертификатом, заверенным удостоверяющим центром. Для того чтобы убедиться, что данный открытый ключ действительно принадлежит серверу, а не предложен посторонним лицом, клиентская программа должна проверить сертификат и получить положительные ответы на четыре следующих вопроса.
1.Соответствует ли текущая дата периоду действия сертификата? Если нет, значит, сертификат недействителен.
2.Зарегистрирован ли центр сертификации, выдавший данный сертификат, на компьютере клиента в качестве доверенного центра сертификации? Если нет, то кто выдал ему сертификат? Зарегистрирован ли этот вышестоящий центр в качестве доверенного? Проверка цепочки центров сертификации продолжится, пока не будет найден вышестоящий центр, который ранее был зарегистрирован на компьютере клиента в качестве доверенного. Если такой центр найден не будет, сертификату доверять нельзя — он выдан неизвестно кем.
3.Соответствует ли публичный ключ центра сертификации его электронной подписи на сертификате, представленном сервером? Если нет, то сертификату доверять нельзя — он поддельный.
4. Совпадает ли доменное имя сервера, указанное в сертификате, с тем доменным именем, по которому в данный момент находится сервер? В принципе, эта проверка не относится к протоколу 551, но она все-таки необходима, чтобы исключить возможность создания защищенного канала, ведущего к подставному партнеру.
Угроза подставного партнера. Как мы только что сказали, клиент должен убедиться в том, что доменное имя сервера, указанное в сертификате, выданном на его открытый ключ, совпадает с доменным именем сервера, с которым в данный момент устанавливается связь. Эта мера предосторожности связана с возможностью создания подставного партнера.
Подставным партнером может быть программа, размещенная злоумышленником на одном из промежуточных серверов, через которые осуществляется установление защищенного соединения по протоколу 551 между клиентом и сервером. Серверу «подставная» программа представляется клиентом, а клиенту — сервером. При этом она перехватывает открытые ключи клиента и сервера и подменяет их своими. В итоге она создает два защищенных канала 551 со своими сеансовыми ключами (рис. 10.20). В одном канале она взаимодействует с сервером, а в другом — с клиентом. Это позволяет ей не только читать данные, проходящие через соединение, но и модифицировать их, причем в каждом из каналов сеансовые ключи не покажут корреспондентам, что что-то было изменено на путях транспортировки. Во избежание этой угрозы чрезвычайно важно, чтобы доменное имя сервера, указанное в сертификате, совпадало с реальным в сеансе связи.
Рис. 10.20. «Подставная» программа создает два защищенных
канала связи там, где должен быть один
Идентификация клиента. Сервер, как и клиент, получает от партнера его открытый ключ вместе с сертификатом, заверенным удостоверяющим центром, но дополнительно еще и образец ЭЦП клиента. Для того чтобы убедиться, что открытый ключ действительно принадлежит клиенту и соответствует закрытому ключу, использованному при создании ЭЦП, сервер должен выполнить ряд проверок и получить положительные ответы на шесть следующих вопросов.
1. Читается ли электронная подпись клиента с помощью его открытого ключа? Если да, то сервер может знать, с кем он имеет дело, однако он еще в этом не уверен. Поскольку связь между клиентом и его доменным именем пока не проверена, он может подозревать, что кто-то воспользовался чужим именем для создания пары ключей и подделки сертификата.
2.Соответствует ли текущая дата периоду действия сертификата? Если нет, сертификат недействителен.
3.Является ли центр сертификации, выдавший сертификат на открытый ключ клиента, доверенным центром? Сервер имеет список центров сертификации, которым доверяет. Если этого центра в списке нет, клиент не будет идентифицирован, пока не будет проверена вся цепочка центров сертификации, то есть, пока она не приведет к центру сертификации, которому сервер доверяет.
4.Соответствует ли публичный ключ центра сертификации его электронной подписи на сертификате, представленном клиентом? Если нет, то сертификату доверять нельзя — он поддельный.
5.Следующая проверка не относится к протоколу 551, но во многих случаях сервер ее проводит. Если клиент корпоративный и тоже представлен Web-сервером, то возможна проверка его доменного имени — имя на сертификате и в реальном сеансе должно быть одним и тем же. Ели же клиент индивидуальный и не имеет доменного имени, на этом этапе сервер может сделать факультативную проверку. Он может обратиться к распределенным сетевым базам данных о людях по протоколу LDAP (Lightweight Directory Access Protocol — Упрощенный протокол доступа к информационным каталогам) и посмотреть, соответствует ли представленный клиентом открытый ключ и сертификат тому, что содержится в информационных каталогах.
Проверка в информационных каталогах может показать, например, что у представившегося клиента на самом деле иной открытый ключ и, соответственно, сертификат. Возможно, она покажет, что сертификат подлинный, но по каким-то причинам был недавно отозван.
6.Самая последняя проверка также не относится к протоколу 55i и определяется внутренней политикой администрации сервера. По установленному имени клиента сервер определяет, имеет ли тот право на предоставление тех услуг или ресурсов, которые запросил.
