Управление сертификацией

Сертифікація

Метод двойной подписи

Одной из инноваций, представленных в SET, является процедура двойной подписи. Эта процедура позволяет связывать элементы двух сообщений, каждое из которых отсылается своему адресату с одной сигнатурой во избежание лишнего обмена данными. При помощи такой процедуры каждый получатель может прочитать сообщение, адресованное лично ему и проверить целостность остальных сообщений, не читая их. Например: предположим, что покупатель одновременно посылает (через платежный шлюз) продавцу ордер заказа, a банку ‑ платежную инструкцию. Конечно, покупатель предпочтет, чтобы его платежи инструкции выполнились только после того, как продавец примет ордер заказа.

Пусть m1 - сообщение, адресованное продавцу, a m2 - сообщение для платежного шлюза. Покупатель объединяет дайджесты сообщений для создания нового сообщения m3.

m3 = H(m1)||H(m2).

Затем покупатель применяет хеш-функцию H() к новому сообщению m3. Соответственно сообщение, отправляемое продавцу, состоит из следующих элементов:

m1, H(m2), {m2, H(m2)}PK_G, {H(m3)}SK_C,

где PK_G ‑ открытый ключ платежного шлюза,

SK_C ‑ закрытый ключ покупателя.

Продавец может извлечь сообщение, которое адресовано лично ему, расшифровать H(m3) открытым ключом клиента и заново вычислить дайджест полученного сообщения. Продавец объединяет вычисленный дайджест с дайджестом другого сообщения, которое покупатель отправил шлюзу, если продавец согласен с целостностью сообщения. Сообщение отсылается в шлюз в виде:

{m2, H(m2)}PK_G, {H(m3)}SK_C, H(m1).

Шлюз может выделить H(m2) и, присоединив H(m1), проверить, что величина H(m3) - та же, что и полученная при помощи открытого ключа клиента. Это означает, что продавец согласен с предложением клиента, так как именно продавец передал предложение клиента в платежный шлюз.

Таким образом, платеж не выполняется до тех пор, пока продавец не акцептует предложение покупателя, поскольку продажа эффективна, только если банк утвердит платежную инструкцию. В то же время платежный шлюз не имеет доступа к ордеру заказа (m1), а платежная инструкция (m2) остается тайной для продавца.

Рассмотрим процедуры сертификации владельца карты и продавца. Важно отметить, что данная сертификация отличается по смыслу от сертификации компонентов SET. Назначение последней - проверить соответствие реализации SET спецификациям, что является задачей компании Tenth Mountain Systems, Inc., дочерней компании SAIC, которая выступает в роли SET Compliance Certification Authority (SCCA)[4].

Общая схема сертификации приведена на рис. 5. На схеме представлены девять элементов, начиная с корневого центра сертификации (ЦС) и заканчивая участниками SET-транзакции.

На вершине структуры сертификации находится корневой ЦС, проверяющий аутентичность участников транзакции и контролирующий доставку электронных сертификатов. Для выполнения этой задачи была выбрана компания CertCo & Digital Trust Company. В ее задачи входит выпуск корневого ключа для криптоалгоритмов с открытым ключом (длиной 2048 бит), предназначенного для создания сертификатов для аутентификации всех остальных пользователей. CertCo ‑ дочерняя компания BankersTrast (в 1998 году объединилась с Deutsche Bank), основана в декабре 1996 года. Предполагается, что CertCo не будет являться единственным хранителем ключа. Ключ будет разделен на фрагменты, которые будут храниться у главных эмитентов платежных карт.

На следующем уровне иерархии находятся брендовые ЦС, включающие различные организации по управлению банковскими картами (главным образом Visa и MasterCard), а также кредитными картами, такими, как American Express. Эти центры могут делегировать свои полномочия в выбранной зоне геополитическим ЦС, чья функция заключается в аккредитации локальных центров. Отметим, что для всех этих ЦС длина ключа для криптоалгоритмов с открытым ключом равна 1024 битам.

Рис. 5.Иерархическая структура управления сертификатами

Как показано на рис. 5, конечные сущности имеют два типа сертификатов: сертификат цифровой подписи и сертификат шифрования ключей. Сертификаты цифровой подписи предназначены для проверки цифровой подписи (сигнатуры), а сертификаты шифрования ключей - для шифрования секретного ключа по алгоритму симметричного шифрования. Каждому типу сертификата соответствует пара ключей: ключи подписи и ключи шифрования ключей. Для соответствия законодательству ключи подписи имеют больший размер. Так как владельцы карт не могут иметь другого сертификата, кроме сертификата цифровой подписи, они вынуждены использовать для шифрования и обмена симметричными ключами те ключи, которые присылают им другие участники транзакции.

Напротив, продавец и платежный шлюз имеют оба типа сертификатов. Локальные ЦС владеют третьим типом сертификатов, удостоверяющим их право сертифицировать конечные сущности. Авторитету, сертифицирующему платежный шлюз, необходимо иметь дополнительный сертификат для подписи списка аннулируемых сертификатов. Обычно платежному шлюзу сертификат выдает банк-эквайер. Центры трех верхних уровней иерархии имеют только два сертификата: первый для сертификации нижележащих уровней, второй - для подписи списка аннулированных сертификатов. Хотя протокол определяет процедуру сертификации, процедура аннулирования сертификатов оставлена на усмотрение индивидуальных центров.

Сертификат владельца карты. При сертификации владелец карты получает сертификат цифровой подписи, подписанный ЦС. Этот сертификат гарантирует связь между парой ключей цифровой подписи и такими атрибутами владельца, как имя, номер счета, срок годности карты, ΡIΝ и т.д. Согласно версии 1 спецификации SET требования к сертификации владельца карты определяются политикой банка-эмитента.

Сертификат не содержит имени владельца карты в явном виде, но содержит его зашифрованное значение ‑ псевдоним. Точно так же в сертификате нет каких-либо финансовых атрибутов, вместо этого вычисляется хеш-образ от номера счета, срока годности карты и ΡIΝ:

Hash = Н(счет || срок годности || ΡIΝ),

где || - операция конкатенации.

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

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

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

Если банк-эквайер выступает в роли ЦС, он должен обладать четырьмя сертификатами: сертификатом цифровой подписи, сертификатом шифрования ключей, сертификатом для подписи сертификатов и сертификатом для подписи списка аннулированных сертификатов. В свою очередь банк-эквайер должен быть сертифицирован геополитическим или брендовым ЦС.

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

Сертификаты корневого центра. Сертификат корневого ЦС подписан им самим и доступен всем конечным пользователям SET. При генерации корневого ключа также формируется замещающий ключ (replacement key). Замещающий ключ безопасно хранится до момента его использования. Подписанный корневой сертификат распространяется вместе с дайджестом замещающего ключа. При смене корневого ключа ПО получает сообщение с новым корневым сертификатом, который в свою очередь содержит дайджест нового замещающего ключа. ПО вычисляет дайджест нового замещающего ключа из нового сертификата и сверяет его с дайджестом замещающего ключа из старого сертификата, таким образом, удостоверяясь в корректности нового сертификата. Замещающий ключ обеспечивает непрерывность обслуживания ‑ каждый раз, когда главный ключ находится в стадии обновления, новые сертификаты выпускаются с замещающим ключом в качестве главного ключа. Подлинность нового сертификата проверяется путем сравнения дайджеста нового ключа в новом сертификате с его дайджестом в старом сертификате.

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

Сроки действия сертификатов. Спецификации SET (книга 2) предполагают обновление сертификатов в соответствии с графиком, показанным в таблице 3. Закрытые ключи обновляются ежегодно для всех сущностей, за исключением владельца карты, для которого период обновления составляет 3 года.

Таблица 3. График обновления сертификатов

Сущность	Сертификат подписи	Сертификат шифрования ключей	Сертификат для подписи сертификатов	Сертификат для подписи списка аннулированных сертификатов
Владелец карты	3 года
Продавец	1 год	1 год
Платежный шлюз	1 год	1 год
ЦС владельца карты	1 год	1 год	4 года
ЦС продавца	1 год	1 год	2 года
ЦС платежного шлюза	1 год	1 год	2 года	2 года
Геополитический ЦС			5 лет	2 года
Брендовый ЦС			6 лет	2 года
Корневой ЦС			7 лет	2 года