3.2.3. Системы с симметричной аутентификацией
Например, перевод денег со счета на счет между банками может быть выполнен путем простого обмена двумя сообщениями. В чековых системах это имеет смысл только для СЭП с неотложным вы-полнением платежей, так как получатель не может даже проверить аутентичность платежного сообщения - хеш-код может проверить только банк. Таким образом, получатель даже не знает, имеет ли плательщик сумму, необходимую для выполнения платежа, до тех пор, пока не получит сообщение от банка с хеш-кодом, который он сможет проверить.
Примером такой СЭП являлась первоначальная версия СЭП NetBill, но новые версии этой СЭП стали использовать для аутенти-фикации сообщений цифровую подпись.
3.2.4. Системы с аутентификацией посредством цифровой подписи
СЭП с аутентификацией сообщений посредством цифровой подписи открывают широкие возможности для построения аналогов традиционных банковских систем: чековых, систем денежных пере-водов, систем с кредитными картами. Ручные подписи на банков-ских документах заменяются цифровыми подписями, секретные ключи подписывающего хранятся на защищенных устройствах, а сама структура документооборота и формы документов остаются точно такими же, как в традиционных платежных системах.
Выделяют три области применения СЭП с аутентификацией по-средством цифровой подписи:
Домашнее банковское обслуэ/сивание. Такие СЭП имитируют традиционные технологии банковского обслуживания физических лиц, включая открытие счетов, перевод денежных средств, платеж-ные поручения и пр.
Благодаря использованию сети Интернет бан-ковское обслуживание становится доступно для клиентов системы, находящихся дома или на работе. Очевидно, , что все пересылки со-общений должны защищаться криптографическими методами. В ка- честве примера можно назвать немецкий стандарт HBCI (Ноте Banking Computer Interface).Системы с защищенными кредитными картами. Такие системы получили в настоящее время, пожалуй, наибольшее распро-странение. СЭП строится как комплекс прикладных программ на базе одной из спецификаций защищенных протоколов электронных платежей: CyberCash, іКР (фирмы IBM), а чаще всего на базе специ-фикации SET (Secure Electronic Transactions).
Чековые системы. С точки зрения криптографии такие СЭП не имеют реальных отличий от систем с кредитными картами - различия заключаются только в самой банковской технологии. В качестве примера чековой системы с аутентификацией посредством цифровой подписи можно упомянуть американскую FSTC (Financial Services Technology Consortium).
Остановимся более подробно на спецификации SET. Она была разработана как компромисс между множеством протоколов элек-тронных платежей, сконструированных отдельными фирмами (Cy-berCash, іКР, SEPP, STT), а потому получилась довольно сложной и объемной. Сейчас она стала стандартом де-факто для банковских платежных систем, обслуживающих кредитные карты. В качестве технического средства реализации кредитных карт избираются либо карты с магнитной полосой, либо (и чаще всего) ИК.
Спецификация SET (Secure Electronic Transactions) - результат совместных усилий двух крупнейших международных систем бан-ковских платежей: MasterCard International и VISA International - с целью создания единой системы электронных платежей по кре-дитным картам. До разработки SET каждая из двух организаций выдвигала свой собственный протокол электронных платежей и каждая заручилась для этого поддержкой множества коммуникацион-ных компаний и фирм-производителей компьютерной техники. Сейчас большинство участников рынка информационных технологий отдает предпочтение именно SET, и среди них такие крупнейшие корпорации, как IBM, Microsoft, Netscape, GTE и др.
SET включает три тома общим объемом более 1 ООО страниц: бизнес-руководство, техническое руководство, руководство про-граммиста.
В ней описана модель взаимодействия участников сис-темы электронных платежей, а также протоколы обмена данными, форматы данных, порядок применения криптографических алгорит-мов, применение ИОК для управления открытыми ключами. SET использует схему открытого шифрования RSA-OAEP.Рассмотрим в общем виде основные компоненты и процессы, изложенные в этой спецификации (для краткости мы ограничимся их качественным описанием). В SET определяются основные участ-ники СЭП.
Продавец (merchant) - любое лицо, продающее товары, инфор-мацию или оказывающее услуги.
Эквайрер (acquirer) - организация, которая обслуживает кредит-ные карты и следит за финансовыми потоками: известными приме-рами таких организаций являются MasterCard, EuroPay, VISA.
Эмитент (issuer) - организация, выпускающая в обращение кредитные карты и передающая их покупателям: обычно это банк или другое подобное кредитно-финансовое учреждение.
Держатель карты (cardholder) - всякое лицо, получившее кре-дитную карту от эмитента и использующее ее для совершения поку-пок в магазинах либо через веб-сервис сети Интернет. В качестве кредитной карты чаще всего используется карта с магнитной поло-сой либо ИК.
Платежный шлюз эквайрера (acquirer payment gateway) - ком-понент системы, обеспечивающий интерфейс между продавцом и банковской информационной системой, используемой эквайрером и эмитентом. Важно помнить, что эта система, как правило, уже су-ществует к моменту внедрения СЭП на базе SET. Платежный шлюз эквайрера обеспечивает хорошо определенный защищенный интер-фейс, отделяющий эту сеть от сети Интернет. Шлюзы будут выпол-нять операции от лица эквайреров, но они могут обеспечиваться и сторонними организациями, например интернет-провайдерами.
Удостоверяющий центр (certificate authority). Спецификация SET предполагает использование асимметричных криптосхем, сле-довательно, каждый элемент системы нуждается в одном или не-скольких сертификатах открытых ключей.
Спецификация SET описывает множество транзакций для вы-полнения операций покупки товара, аутентификации держателя карты, «отката» платежа и др.
На рис. 3.3 показаны транзакции, состав-ляющие типовую операцию приобретения держателем карты товара или услуги у продавца, причем каждая транзакция составлена из па-ры сообщений (запроса и ответа).4 1
і InqRes CapReq ; 5 1 CapRes Рис. 3.3. Последовательность выполнения транзакций при выполнении операции покупки согласно спецификации SET
Шлюз эквайрера
Держатель карты
Продавец PlnitReq AuthReq ^^
< Plnit Res PReq і ^
3 ! ! AuthRes !
і —г, ;
Инициализация (Plnit). Эта транзакция инициализирует систему, включая и описание деталей, таких, как принадлежность карты к той или иной международной платежной системе, включая и загруз-ку сертификатов открытых ключей держателя карты. Спецификация SET не обязывает к тому, чтобы держатель карты имел подписанные сертификаты своих открытых ключей, но рекомендует это, так как сертификат держателя карты логически связывает номер счета, об-служиваемого кредитной картой, с владельцем открытого ключа. Если эквайрер получает запрос для заданного номера кредитной карты, подписанной открытым ключом держателя карты, то тем са-мым он узнает, что запрос исходит от реального держателя карты. Точнее говоря, он теперь знает, что запрос исходит от компьютера, где была инсталлирована и стала доступна ключевая система держа-теля карты. Но это не гарантирует, что компьютером не овладел злоумышленник, узнавший пароль для доступа к ключевой системе.
Покупательский ордер (purchase order) - это собственно запрос держателя карты на покупку какого-либо товара либо услуги. Запрос на самом деле состоит из совокупности двух сообщений: ор-дерной команды (ОГ), которая посылается в открытом виде продав-цу, и покупательской команды (77), которую покупатель передает на платежный шлюз эквайрера. PI зашифровывается с помощью от-крытого ключа эквайрера, так что продавец не может ее прочитать.
Продавец просто хранит это сообщение для дальнейшей передачи эквайреру. PI включает в себя хеш-код 01, так что два сообщения могут восприниматься только в паре.
Заметим, что номер кредитной карты помещается только в PL Это означает, что продавец никогда не получает к нему доступа, предотвращая таким образом злоумышленных пользователей от попыток сбора информации о кредитных картах. PI предполагает ответ на нее, который обычно отправляется после получения подтверждения от эквайрера. Однако продавец может завершить транзакцию с держателем карты до выполнения авторизации. В этом случае он выдает уведомление, что запрос принят, но находится в ожидании авторизации.Авторизация (authorization). В этой транзакции продавец запра-шивает у эквайрера через платежный шлюз авторизацию запроса. Со-общение включает описание покупки и информацию о ее стоимости, а также PI из покупательского ордера, который был сгенерирован дер-жателем карты. Таким образом, эквайрер знает, что и продавец, и дер-жатель карты согласовали вид и стоимость приобретаемого товара. Когда эквайрер получает запрос, он использует существующую банков-скую информационную систему для того, чтобы авторизовать запрос и послать обратно соответствующий ответ.
Справка (inquiiy). Держатель карты может пожелать узнать ход выполнения его запроса. Для этой цели спецификацией SET предусмотрена особая справочная транзакция.
Утверждение (Capture). До начала этой транзакции никакого движения реальных денег еще не происходило. Запрос на утвержде-ние покупки от продавца требует от эквайрера осуществить предва-рительно авторизованный перевод реальных денег на его счет. На практике эта транзакция может быть внедрена как часть транзакции авторизации (этап 3). Однако есть и такие ситуации, в которых продавец может пожелать задержать утверждение транзакции по срав-нению с авторизацией. Например, большинство продавцов, прини-мающих заказы по телефону или по почте, не изменяют состояние счета, обслуживаемого кредитной картой, до момента реального приобретения товара или услуги.
В SET предусмотрен ряд других транзакций, но мы не будем их рассматривать, так как все они реализуют упомянутые выше прин-ципы.
Спецификация SET рассчитана на крупномасштабную реализа-цию СЭП.
Предполагается, что в ней будут участвовать сотни тысяч лиц по всему миру. Потенциально каждый из них мог бы иметь по меньшей мере один сертификат открытого ключа. В то же время на практике криптографические протоколы вынуждают участников системы в некоторых случаях иметь множество сертификатов. На-пример, платежным шлюзам эквайреров необходимы два сертифи-ката: один для подписания сообщений и один для их шифрования. Управление ключами в такой глобальной информационной системе требует развертывания иерархической модели сертификации откры-тых ключей, что показано нарис. 3.4.
Держатели карг Продавцы Шлюзы эквайреров
Рис. 3.4. Иерархическая модель сертификации открытых ключей согласно спецификации SET
На вершине иерархии находится корневой удостоверяющий центр (УЦ), работающий в автономном режиме, так как для него не-обходимы крайне высокие меры безопасности, ибо в случае его компрометации происходит утрата безопасности всей глобальной СЭП. Доступ к его секретному ключу возможен в единственном случае: при введении в СЭП новой международной системы платежей по кредитным картам (что, очевидно, случается крайне редко). Для следующего уровня иерархии - уровня удостоверяющих центров платежных систем - также требуется очень высокая степень стойкости, но они администрируются независимо каждой междуна-родной системой платежей по кредитным картам.
Таким образом, для каждой отдельной платежной системы появ-ляется возможность проводить собственную операционную полити-ку, и в том числе политику безопасности. Можно, например, в рам-ках системы выделять удостоверяющие центры по региональному или государственному признаку. Эти центры образуют следующий уровень иерархии. На самом нижнем уровне находятся те удостове-ряющие центры, которые сертифицируют открытые ключи держате-лей карт, продавцов и платежных шлюзов эквайреров.
Спецификацией SET для держателей карт и продавцов преду-смотрены протоколы запроса сертификатов в режиме реального времени. Важно, чтобы этот процесс был максимально простым, ибо SET ориентируется на то, чтобы держатели карт имели свои собст-венные сертификаты открытых ключей и могли совершать покупки через веб-сервис сети Интернет, используя механизм запроса серти-фикатов, реализованный в ПО веб-браузера.
Конечно, если система позволяет легко создавать сертификаты, она должна давать возможность и легко аннулировать их при необ-ходимости. Для этой цели в SET предусмотрены протоколы обнов-ления и аннулирования сертификатов. Несмотря на то что механизм запроса сертификатов может быть довольно простым, тем не менее он требует от пользователей некоторого понимания общих принци-пов его функционирования. Например, очевидно, что держателю карты следует уведомить кредитно-финансовое учреждение, обслу-живающее его кредитную карту, об утрате самой карты. Менее очевидно, что он также должен уведомить его и о краже своего компь-ютера либо о факте несанкционированного доступа к его ресурсам. Если на компьютере установлена ключевая система, содержащая секретный ключ и сертификат, то это позволит злоумышленнику со-вершать покупки за счет легального владельца карты.