Интегрированные сети ISDN

         

Операторы, используемые протоколом SET



Таблица 4.6.2.3. Операторы, используемые протоколом SET

Нотация

Оператор

Описание

H(t)

хэш

160-битовый хэш группы t

HMAC(t,k)

Ключевой хэш-механизм

160-битовый ключевой хэш группы t, использующий ключ k и алгоритм HMAC-SHA-1

HMAC(t,k) = H(k A

opad) | H((k A



ipad)|t)),

где ipad - байт 0х36, повторенный 64 раза;

opad – байт 0х5С, повторенный 64 раза; а

A - знак операции исключающее ИЛИ.

L(t1,t2)

Связь

Ссылка, указатель или связь t2 с t1; эквивалентно группе {t1, H(t2)}

Нотация операторов цифровой подписи

S(s,t)

Подписанное сообщение

Подпись объекта s для группы t, включая открытый текст t. Алгоритмом цифровой подписи для SET является RSA с дайджестом SHA-1. Соответствует SignedData PKCS #7.

Нотация операторов двойной цифровой подписи

SO(s,t)

Только подпись

Подпись объекта s для группы t, не включая открытый текст t. SO соответствует внешней подписи PKCS #7. Алгоритмом цифровой подписи для SET является RSA с дайджестом SHA-1.

Нотация операторов шифрования

E(r,t)

Асимметричное шифрование

(цифровой конверт)

Сначала шифруется t с новым симметричным ключом k, затем ключ вкладывается в цифровой конверт PKCS #7 для объекта r. Производится шифрование OAEP(k) с использованием общедоступного ключа объекта r, взятого из сертификата группы r. Для симметричного шифрования в SET по умолчанию используется алгоритм DES. Соответствует EnvelopedData.

EH(r,t)

Шифрование целостности

Процедура подобна E за исключением того, что цифровой конверт PKCS#7 содержит OAEP({k,H(t)}) для гарантии целостности, когда подпись не доступна. Программа вычисляет повторно хэш t и проверяет соответствие H(t) в цифровой конверте.

EX(r,t,p)

Дополнительное шифрование

Процедура подобна E за исключением того, что t и p являются частями составного сообщения. t – группа, которая должна быть соединена с p и подвергнута обычному симметричному шифрованию, а p – параметр или часть, которая должна быть подвергнута дополнительной обработке. t связано с p. OAEP({k,p})

вкладывается в цифровой конверт PKCS#7 для объекта r.

EXH(r,t,p)

Дополнительное шифрование с обеспечением целостности

Процедура подобна EX за исключением того, что это делается с OAEP({k,H(t), p}) в цифровом конверте PKCS#7 и с требованием проверки H(t), как и в случае EH

EK(k,t)

Симметричное шифрование посредством ключа k

Симметричное шифрование группы t с помощью секретного ключа k. Соответствует формату EncryptedData

Нотация операторов инкапсуляции

Enc(s,r,t)

Простая инкапсуляция с подписью

Подписанное и затем зашифрованное сообщение. Соответствует SignedData в EnvelopedData

EncK(k,s,t)

Простая инкапсуляция с подписью и предоставленным ключом

Подписанное сообщение, зашифрованное с помощью секретного ключа. Соответствует EncryptedData.

EncX(s,r,t,p)

Дополнительная инкапсуляция с подписью

Составное сообщение, первая часть которого зашифрована симметричным алгоритмом. Вторая часть сообщения преобразуется с привлечением алгоритма OAEP

EncB(s,r,t,b)

Простая инкапсуляция с подписью с загрузкой

Подписанное зашифрованное сообщение с загрузкой (baggage)

EncBX(s,r,t,p,b)

Дополнительная инкапсуляция с подписью и загрузкой

Подписанное, Е-шифрованное составное сообщение с загрузкой

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


Банк в этом случае может быть уверен, что согласие получено именно на это, а не на какое-то другое сообщение. В то же время банк не получает доступа к тексту предложения.
В протоколе SET двойные подписи используются для установления связи между сообщением-заказом, посланным продавцу, и платежными инструкциями, содержащими информацию о счетах клиента, посланными получателю платежа (обычно это банк продавца).
Важным принципом при анализе работы программ SET является идемпотентность – реакция алгоритма на повторное выполнение одних и тех же сообщений. Обычно SET используется поверх протоколов HTTP или SMTP, которые, в свою очередь, работают на основе транспортного протокола TCP. Протокол TCP сам по себе гарантирует доставку сообщения. Но в SET из-за высокой степени финансовой ответственности вводится дополнительный контроль доставки уже на прикладном уровне. Любой механизм гарантированной доставки предполагает повторную посылку сообщения при отсутствии отклика от получателя. Следует иметь в виду, что практически невозможно разделить потерю сообщения и отклика на это сообщение. Именно по этой причине программа получателя должна быть готова к обработке повторных сообщений, так как задержка при транспортировке в Интернет может спровоцировать повторную посылку запроса. Повторные запросы должны иметь тождественные идентификаторы (XID и PRPID). Повторная посылка запросов и их обработка не должны влиять на конечный результат. Но не все виды запросов требуют такой обработки. Информационные запросы в отличие от запросов-заказов не нуждаются в запоминании продавцом (для выяснения того, являются ли они повторными). На такие запросы посылаются отклики каждый раз в соответствии со статусом системы. То есть на один и тот же запрос в разное время может быть получен разный отклик. Если приложение SET детектирует атаку типа “шторма запросов”, оно может не реагировать на эти запросы.

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


Его длина составляет 20 байт.

BrandID представляет собой поле, используемое протокольными сообщениями управления платежом и сертификации. Оно содержит имя платежной системы (Brand) и опционное название продукта в рамках данной платежной системы. Запись имеет формат brand:product.
Безопасность системы SET зависит от подлинности сертификатов, используемых системой. Система производит иерархическую верификацию всех сертификатов. Цепочка сертификатов завершается корневым сертификатом (Root CA), общим для всей системы. Общедоступный ключ Root CA (корневого сертификационного центра; X.509v3) распространяется в виде сертификата программным обеспечением SET. Для верификации цепи сертификатов необходимо иметь общедоступный корневой ключ.

Cert-PE представляет собой сертификат, сформированный узлом сертификации платежного центра (PCA) и связывает расчетный центр с общедоступным ключом шифрования, присылаемым в сообщении запроса сертификата CertReq.
Отправитель гарантирует корректность формата сообщения, который должен соответствовать типу сообщения. Если какая-то часть сообщения подписана отправителем, сообщение должно содержать сертификаты CRL и BrandCRLIdentifiers.
Для обеспечения совместимости и дальнейшего расширения возможностей протокола используются стандарты PKCS и Cryptographic Message Syntax (стандарт на криптографический синтаксис сообщений), которые определяют и механизмы криптографического вложения. Форматы PKCS используются для вложения данных в сообщения SET. Данный протокол использует следующие методы инкапсуляции PKCS #7.
  • SignedData для вложения подписанной информации

  • EnvelopedData для инкапсуляции зашифрованных данных

  • EncryptedData для инкапсуляции зашифрованных данных c использованием симметричного алгоритма

  • DigestedData для инкапсуляции хэшированных или связанных данных

  • Тип SignedData из PKCS #7 проиллюстрирован на Рисунок 4.6.2.5, где отображен процесс цифровой подписи. В пределах SignedData может присутствовать несколько полей Signerinfo, но подписывать SignedData может не более двух субъектов.


    Содержание раздела