Таблица 4.6.2.62. Коды завершения операции
meanonglessRatio |
PurchAmt=0; отношение не может быть вычислено |
orderRejected |
Продавец не может обработать заказ |
orderReceived |
Процессы авторизации отсутствуют |
orderNotReceived |
Информационный запрос получен до заказа |
authorizationPerformed |
См. AuthStatus |
capturePerformed |
См. CapStatus |
creditPerformed |
См. CreditStatus |
Владелец карты обрабатывает полученный отклик PRes следующим образом.
Шаг |
Действие |
1 |
Извлекается отклик из входного сообщения |
2 |
Чтобы проверить подпись продавца, производится обращение к Received Signed Data, |
3 |
На основе Trans.LID-C ищется запись транзакции. Если запись не найдена: Посылается сообщение Error c ErrorCode равным unknownLID Прерывается обработка PRes |
4 |
Сравнить значения TransIDs.XID с XID из записи транзакции. Если равенства нет: Посылается сообщение Error c ErrorCode равным unknownXID Прерывается обработка PRes |
5 |
Сравнить значения RRPID из сообщения и записи транзакции. Если совпадения нет: Посылается сообщение Error c ErrorCode равным unknownRRPID Прерывается обработка PRes |
6 |
Сравнить значения Chall-C из сообщения и записи транзакции. Если совпадения нет: Посылается сообщение Error c ErrorCode равным challengeMismatch Прерывается обработка PRes |
7 |
Запомнить BrandCRLIdentifier и проверить, что перечисленные CRL содержаться в кэше. Если это не так, и перечисленные CRL относятся к элементам, чьи сертификаты использовались для верификации подписи, сообщение игнорируется, так как подпись может быть некорректной. |
8 |
Для каждого PResPayload из PresPayloadSeq выполняются следующие действия: Если CompletionCode указывает на реализацию кредита, для каждой информационной структуры в CreditSeq представить пользователю CreditAmount (PurchAmount*CredRatio) и дату кредита вместе с полученным объемом платежа (PurchAmount*CapRatio). В противном случае, если CompletionCode указывает на завершение процесса платежа, представить пользователю CapCode вместе с вычисленным Capture Amount (PurchaseAmount*CapRatio). В противном случае, если CompletionCode указывает на завершение процесса авторизации, представить пользователю AuthCode вместе с вычисленным Authorization Amount (PurchaseAmount*AuthRatio). В противном случае сообщить результат транзакции на основе CompletionCode. Если присутствует AcqCardMsg, дешифровать и представить владельцу карты. Если там имеется URL, программа может выдать содержимое соответствующей WEB-страницы. Здесь может потребоваться обработка, зависящая от вида платежной системы. |
Таблица 4.4.13.1 Команды SNMP
Команда SNMP |
Тип PDU |
Назначение |
GET-request |
0 |
Получить значение указанной переменной или информацию о состоянии сетевого элемента; |
GET_next_request |
1 |
Получить значение переменной, не зная точного ее имени (следующий логический идентификатор на дереве MIB); |
SET-request |
2 |
Присвоить переменной соответствующее значение. Используется для описания действия, которое должно быть выполнено; |
GET response |
3 |
Отклик на GET-request, GET_next_request и SET-request. Содержит также информацию о состоянии (коды ошибок и другие данные); |
TRAP |
4 |
Отклик сетевого объекта на событие или на изменение состояния. |
GetBulkRequest |
5 |
Запрос пересылки больших объемов данных, например, таблиц. |
InformRequest |
6 |
Менеджер обращает внимание партнера на определенную информацию в MIB. |
SNMPv3-Trap |
7 |
Отклик на событие (расширение по отношению v1 и v2). |
Report |
8 |
Отчет (функция пока не задана). |
Таблица 7.10. Краткое описание сообщений об ошибках
WinSock-код |
Berkeley-эквивалент |
Код ошибки |
Значение |
WSAEINTR | EINTR | 10004 | Как в стандартном C |
WSAEBADF | EBADF | 10009 | Как в стандартном C |
WSAEACCES | EACCES | 10013 | Как в стандартном C |
WSAEFAULT | EFAULT | 10014 | Как в стандартном C |
WSAEINVAL | EINVAL | 10022 | Как в стандартном C |
WSAEMFILE | EMFILE | 10024 | Как в стандартном C |
WSAEWOULDBLOCK | EWOULDBLOCK | 10035 | Как в BSD |
WSAEINPROGRESS | EINPROGRESS | 10036 | Эта ошибка возникает, если какая-либо процедура WinSock вызвана во время исполнения блокирующей операции. |
WSAEALREADY | EALREADY | 10037 | Как в BSD |
WSAENOTSOCK | ENOTSOCK | 10038 | Как в BSD |
WSAEDESTADDRREQ | EDESTADDRREQ | 10039 | Как в BSD |
WSAEMSGSIZE | EMSGSIZE | 10040 | Как в BSD |
WSAEPROTOTYPE | EPROTOTYPE | 10041 | Как в BSD |
WSAENOPROTOOPT | ENOPROTOOPT | 10042 | Как в BSD |
WSAEPROTONOSUPPORT | EPROTONOSUPPORT | 10043 | Как в BSD |
WSAESOCKTNOSUPPORT | ESOCKTNOSUPPORT | 10044 | Как в BSD |
WSAEOPNOTSUPP | EOPNOTSUPP | 10045 | Как в BSD |
WSAEPFNOSUPPORT | EPFNOSUPPORT | 10046 | Как в BSD |
WSAEAFNOSUPPORT | EAFNOSUPPORT | 10047 | Как в BSD |
WSAEADDRINUSE | EADDRINUSE | 10048 | Как в BSD |
WSAEADDRNOTAVAIL | EADDRNOTAVAIL | 10049 | Как в BSD |
WSAENETDOWN | ENETDOWN | 10050 | Как в BSD. Ошибка возникает в любое время, когда приложение WinSock обнаруживает ошибку на нижележащем уровне. |
WSAENETUNREACH | ENETUNREACH | 10051 | Как в BSD |
WSAENETRESET | ENETRESET | 10052 | Как в BSD |
WSAECONNABORTED | ECONNABORTED | 10053 | Как в BSD |
WSAECONNRESET | ECONNRESET | 10054 | Как в BSD |
WSAENOBUFS | ENOBUFS | 10055 | Как в BSD |
WSAEISCONN | EISCONN | 10056 | Как в BSD |
WSAENOTCONN | ENOTCONN | 10057 | Как в BSD |
WSAESHUTDOWN | ESHUTDOWN | 10058 | Как в BSD |
WSAETOOMANYREFS | ETOOMANYREFS | 10059 | Как в BSD |
WSAETIMEDOUT | ETIMEDOUT | 10060 | Как в BSD |
WSAECONNREFUSED | ECONNREFUSED | 10061 | Как в BSD |
WSAELOOP | ELOOP | 10062 | Как в BSD |
WSAENAMETOOLONG | ENAMETOOLONG | 10063 | Как в BSD |
WSAEHOSTDOWN | EHOSTDOWN | 10064 | Как в BSD |
WSAEHOSTUNREACH | EHOSTUNREACH | 10065 | Как в BSD |
WSASYSNOTREADY | 10091 | Выдается WSAStartup, указывает, что сетевая субсистема использоваться не может. | |
WSAVERNOTSUPPORTED | 10092 | Выдается WSAStartup, указывая на то, что WinSock DLL не может поддерживать это приложение. | |
WSANOTINITIALISED | 10093 | Выдается любой процедурой кроме WSAStartup, указывая на то, что успешное исполнение WSAStartup не было осуществлено. | |
WSAEDISCON | 10094 | Выдается recv, WSARecv, чтобы отметить начало разрыва связи удаленным партнером | |
WSA_OPERATION_ABORTED | TBD | Совмещенные по времени процедуры прерваны из-за закрытия соединения, или выполнения команды SIO_FLUSH в WSAIoctl | |
WSAHOST_NOT_FOUND | HOST_NOT_FOUND | 11001 | Как в BSD |
WSATRY_AGAIN | TRY_AGAIN | 11002 | Как в BSD |
WSANO_RECOVERY | NO_RECOVERY | 11003 | Как в BSD |
WSANO_DATA | NO_DATA | 11004 | Как в BSD |
WSP | WinSock Service Provider | для транспортных услуг сервис-провайдера; |
WPU | WinSock Provider Upcall | для входа в WinSock DLL сервис-провайдера; |
WSC | WinSock Configuration | для входа в WinSock DLL инсталляционных приложений; |
NSP | Name Space Provider | для работы с сервером имен. |
0 | протокол слоя |
1 | базовый протокол (или стек, если стек состоит из одного протокола) |
>1 | стек протоколов. |
FD_CONNECT | Канал до удаленной ЭВМ или для мультикастинг-сессии сформирован |
FD_ACCEPT | Удаленная ЭВМ выставила запрос на соединение; |
FD_READ | Получены данные и их можно считать; |
FD_WRITE | В буферах сервис-провайдера появилось свободное место и можно послать очередную порцию информации; |
FD_OOB | Для чтения доступна высокоприоритетная информация; |
FD_CLOSE | Удаленная ЭВМ закрывает канал; |
FD_QOS | Произошло изменение оговоренного значения QOS (качества услуг); |
FD_GROOUP_QOS | Произошло изменение оговоренного значения QOS для данной группы соединителей. |
int32 | TokenRate; | /* В байтах/сек */ |
int32 | TokenBucketSize; | /* В байтах */ |
int32 | PeakBandwidth; | /* В байтах/сек */ |
int32 | Latency; | /* В микросекундах */ |
int32 | DelayVariation; | /* В микросекундах */ |
int32 | CostOfCall; | /* Зарезервировано для будущего использования, должно быть = 0 */ |
int32 | NetworkAvailability | /* только для чтения: 1, если есть доступ, 0, если нет */ |
FLOWSPEC | SendingFlowspec; | /* Спецификация потока для данных */ |
/* Посылка */ | ||
FLOWSPEC | ReceivingFlowspec; | /* Спецификация потока для данных */ |
/* Прием */ | ||
WSABUF | ProviderSpecific; | /* Дополнительный провайдер */ |
/* Специфические параметры */ |
LevelOfGuarantee | Согласуемый уровень сервиса. Определены четыре уровня: гарантированный, предсказуемый, контролируемая загрузка и лучшее, что возможно. Предсказуемый уровень сервиса может дать наилучший результат при использовании определенного ресурса сети, в то время как гарантированный уровень соответствует необходимому уровню услуг конкретного приложения. Провайдеры могут предоставлять один, оба или ни одного их этих двух видов услуг. |
GuaranteedService | Провайдер, поддерживающий гарантированный уровень сервиса, использует алгоритм очередей, в котором поток изолируется от влияния других потоков, и гарантирует, на сколько возможно, пропускную способность. Если отправитель шлет данные с большей скоростью, сеть может задержать или даже ликвидировать “лишнюю” часть потока. Если поток находится в пределах допустимого, то гарантируется и задержка отклика. Этот вид сервиса предусмотрен для приложений реального времени. |
PredictiveService | Провайдер, поддерживающий предсказуемый уровень сервиса, гарантирует пропускную способность, по крайней мере равную TokenRate, на время соединения. Если отправитель шлет данные с большей скоростью, сеть может задержать или даже ликвидировать “лишнюю” часть потока. Значение задержки не гарантируется. Этот вид сервиса предназначен для приложений, способных адаптироваться к вариациям качества услуг, например, передача видео изображения. |
ControlledLoadService | Этот уровень сервиса предполагает, что система сетевых устройств, которыми пользуется приложение, обеспечит условия работы, близкие к тем, которые достижимы при незагруженных каналах, для используемой транспортной среды. Приложения, использующие этот уровень сервиса, могут ожидать что: 1. Большая часть передаваемых пакетов будет успешно доставлена (процент потерь определяется частотой ошибок транспортной среды). 2. Задержка доставки не будет заметно превышать минимальное время распространения сигнала в используемой транспортной среде. |
BestEffortService | Провайдеры, поддерживающие уровень сервиса “лучшее что возможно”, рассматривают спецификацию потока, как руководство к действию. И пытаются сделать все возможное, чтобы поддержать запрашиваемый уровень сервиса (без каких-либо твердых гарантий). |
TokenRate/TokenBucketSize | Модель “блоков символов” (Token bucket model) используется для задания верхнего предела скорости обмена. Величина value -1 в этом случае означает, что не существует никаких ограничений на скорость обмена. Значение TokenRate (частота символов) выражается в байтах в сек, а TokenBucketSize в байтах. Блок имеет определенный объем (TokenBucketSize), который заполняется с определенной скоростью (TokenRate). Если в блоке достаточно места, приложение может посылать данные, что приводит к уменьшению свободного места. Если же свободного места нет, приложение должно прервать обмен и ждать. Если приложение в течение определенного времени слало данные со скоростью меньше чем TokenRate, оно может затем на некоторое время превысить эту скорость. |
PeakBandwidth | Значение этого поля (выражается в байтах в сек) ограничивает максимальную скорость пересылки пакетов приложением. Промежуточные системы могут использовать эту величину для оптимизации использования имеющихся ресурсов. |
Latency | Характеризует максимально приемлемую задержку между посылкой бита отправителем и его получением адресатом (в миллисекундах). |
DelayVariation | Значение этого поля в миллисекундах характеризует разницу между максимальной и минимальной задержкой доставки пакетов. Этот параметр используется приложением для расчета объема входного буфера. |
CostOfCall | Зарезервировано на будущее и должно равняться нулю. |
NetworkAvailability | Это поле, доступное провайдерам только в режиме чтения, используется для сообщения приложению о доступности транспортной среды (например, знакомая многим ситуация потери спутника антенной). |
DWORD | Internal; | // Зарезервировано |
DWORD | InternalHigh; | // Зарезервировано |
DWORD | Offset; | // Зарезервировано |
DWORD | OffsetHigh; | // Зарезервировано |
WSAEVENT | hEvent; |
Internal и InternalHigh | Резервное поле, которое используется объектом, вовлеченным в совмещенные операции ввода/вывода. Для IFS-провайдеров это поле используется базовой операционной системой (IFS - Installable File System - инсталлируемая файловая система). |
Offset и OffsetHigh | Поле зарезервировано для сервис-провайдеров. |
hEvent | Если совмещенные операции ввода/вывода запущены в отсутствии программ завершения (lpCompletionRoutine равно NULL), тогда это поле должно содержать дескриптор (указатель) объекта WSAEVENT. В противном случае (lpCompletionRoutine не равно NULL) клиент может использовать это поле как сочтет нужным. |
Таблица 4.4.13.2. Номера и назначения используемых портов
Назначение |
Порт |
Пояснение |
SNMP |
161/TCP |
Simple Network Management Protocol |
SNMP |
162/TCP |
Trap |
SMUX |
199/TCP |
SNMP Unix Multiplexer |
SMUX |
199/UDP |
SNMP Unix Multiplexer |
synoptics-relay |
391/TCP |
SynOptics SNMP Relay Port |
synoptics-relay |
391/UDP |
SynOptics SNMP Relay Port |
agentx |
705/TCP |
AgentX |
snmp-tcp-port |
1993/TCP |
cisco SNMP TCP port |
snmp-tcp-port |
1993/UDP |
cisco SNMP TCP port |
Таблица 4.6.2.2. Нотация протокола SET
Понятие |
Нотация |
Описание |
|
Группа (tuple) |
{A,B,C} |
Группа из нуля или более информационных элементов. Представляет документы или сообщения, обозначается идентификаторами, содержащими алфавитно-цифровые символы |
|
Компонент |
T={A,B,C} |
Группе может быть присвоено имя. В этом случае T.A, T.B и T.C обозначают компоненты Т. |
|
Упорядоченное объединение |
A|B|C |
Служит для обозначения упорядоченного объединения элементов A,B и C |
|
Опционное значение |
[A] |
Значение A является опционным |
Допускается любое вложение этих скобок |
Выбор |
<A,B,C> |
Обозначает, что должно присутствовать одно из значений A,B или C |
|
Опционный выбор |
[<A,B,C>] |
То же, что и предыдущее, но сам выбор опционен |
|
Кратное использование |
{A+} |
Группа содержит один или более элементов A |
|
{A*} |
Группа содержит нуль или более элементов A |
||
{[A]+} |
Означает, что группа содержит: один или более элементов A в упорядоченном массиве, где каждое вхождение A является опционным (этот элемент может отсутствовать) |
||
Исключающее ИЛИ |
A |
Обозначает операцию исключающее ИЛИ |
Таблица 4.6.2.34. Обязательные расширения сертификата ЕЕ.
Сертификат владельца карты |
Сертификат продавца |
Сертификат расчетного центра |
|||
Расширение Х.509 |
Подпись |
Подпись |
Шифрова-ние ключа |
Подпись |
Шифрова-ние ключа |
AuthorityKeyIdentifier |
Х |
Х |
Х |
Х |
Х |
KeyUsage |
Х |
Х |
Х |
Х |
Х |
PrivateKeyUsagePeriod |
Х |
Х |
Х |
||
CertificatePolicies |
Х |
Х |
Х |
Х |
Х |
SubjectAltName |
O |
O |
O |
O |
O |
BasicConstraints |
Х |
Х |
Х |
Х |
Х |
IssuerAltName |
O |
O |
O |
O |
O |
Частное расширение |
|||||
HashedRootKey |
|||||
CertificateType |
Х |
Х |
Х |
Х |
Х |
MerchantData |
Х |
Х |
|||
CardCertRequired |
Х |
||||
Tunneling |
Х |
||||
SETExtensions |
Х |
Х – обязательный
O - опционный
Таблица 4.6.2.35. Обязательные расширения сертификатов СА
СА |
Корневой центр сертификации |
||||
Расширение Х.509 |
Цифровая подпись |
Подпись серти-фиката |
Шифрова-ние ключа |
Подпись CRL |
Подпись сертификата & CRL |
AuthorityKeyIdentifier |
Х |
Х |
Х |
Х |
Х |
KeyUsage |
Х |
Х |
Х |
Х |
Х |
PrivateKeyUsagePeriod |
Х |
Х |
Х |
||
CertificatePolicies |
Х |
Х |
Х |
Х |
Х |
SubjectAltName |
O |
O |
O |
O |
O |
BasicConstraints |
Х |
Х |
Х |
Х |
Х |
IssuerAltName |
O |
O |
O |
O |
O |
Частное расширение |
|||||
HashedRootKey |
Х |
||||
CertificateType |
Х |
Х |
Х |
Х |
Х |
MerchantData |
|||||
CardCertRequired |
|||||
Tunneling |
Х |
||||
SETExtensions |
Каждый центр сертификации (за исключением MCA и CCA) поддерживает CRL и производит их рассылку. BCI (BrandCRLIdentifier), определенный SET, содержит список всех CRL в пределах данной платежной системы (Brand). Как только СА выпустит новый список CRL, соответствующий BCI актуализируется. Получение конечным пользователем BCI гарантирует, что устаревшие или скомпрометированные сертификаты не будут использованы. В CRL записываются серийные номера устаревших сертификатов. СА идентифицируется в CRL по своему уникальному имени, CRL подписывается рассылающим СА. Длина списка CRL со временем растет. Каждый СА CRL содержит в себе следующую информацию:
Номер CRL. Номера монотонно возрастают.
Список серийных номеров устаревших сертификатов.
Даты, когда конкретные сертификаты были признаны устаревшими.
Даты, когда был сформирован CRL и когда завершается срок его действия (замещается новым CRL).
Уникальное имя СА, который поддерживает данный CRL.
Эмитент и серийный номер сертификата СА, который используется для подписи данного CRL.
В таблице 4.6.2.36 определен формат полей CRL и ограничения для их значений (X.509).
Таблица 4.6.2.8. Обработка оттисков получателем
Шаг |
Действие |
1 |
Инициализировать буфер для запоминания оттисков |
2 |
Для каждого из них: Для сертификата, который имеет отношение к обрабатываемому сообщению-отклику и ко всей цепочке сертификатов, проверить соответствует ли оттиск (хэш) сертификата одному из полученных в сообщении-запросе. Если соответствие найдено, сертификат в кэше удаленной системы существует и его не нужно включать в отклик. Если соответствия нет или список пуст, то включить сертификат в сообщение отклик. Для CRL, который имеет отношение к обрабатываемому сообщению-отклику и ко всей цепочке сертификатов, проверить, соответствует ли оттиск (хэш) одному из оттисков, полученных в сообщении-запросе. Если соответствие имеется, то CRL в кэше удаленной системы существует и его не следует помещать в отклик. Если соответствия нет или список пуст, то данное CRL включается в отклик. Для BCI, который имеет отношение к обрабатываемому сообщению-отклику и ко всей цепочке сертификатов, проверить, соответствует ли CRL-оттиск (хэш) одному из оттисков, полученных в сообщении-запросе. Если соответствия нет или список пуст, то данное CRL включается в отклик. |
3 |
Присылается результат работы шага 2 со списком сертификатов, CRL и BCI, которые следует послать в отклике. |
Простая инкапсуляция с оператором подписи Enc(s,r,t) представляет данные, которые были сначала подписаны, а затем зашифрованы. Этот случай соответствует варианту PKCS#7 SignedData, инкапсулированных в EnvelopedData. Процедура выполняется следующим образом.
Шаг |
Действие |
1 |
Используя оператор подписи и секретный ключ объекта s, подписать содержимое группы t |
2 |
Добавить результат шага 1 в группу t |
3 |
Используя оператор асимметричного шифрования и общедоступный ключ получателя r, зашифровать результат шага 2 |
4 |
Послать результат работы шага 3 |
Другие варианты инкапсуляции осуществляются сходным образом.
Асимметричный оператор шифрования E(r,t) соответствует EnvelopedData PKCS#7 для группы t, зашифрованной для объекта r. Этот оператор включает в себя быстрое симметричное шифрование основного объема данных, а также асимметричное шифрование секретного ключа предшествующего шифрования с привлечением общедоступного ключа получателя. Протоколом шифрования по умолчанию для SET является DES, а для асимметричного шифрования – RSA. Последовательность операций при асимметричном шифровании представлена в таблице 4.6.2.9.
Таблица 7.8. Опции соединителей
Опция |
Тип |
Назначение |
Значение по умолчанию |
SO_GROUP_ID |
GROUP |
Идентификатор группы, к которой принадлежит соединитель. |
NULL |
SO_GROUP_PRIORITY |
int |
Относительный приоритет соединителей, принадлежащих к группе. |
0 |
SO_MAX_MSG_SIZE |
int |
Максимальный размер сообщения для соединителей, ориентированных на сообщения. Не имеет смысла для соединителей типа stream. |
Зависит от реализации |
SO_PROTOCOL_INFO |
struct WSAPROTOCOL_INFO |
Описание протокольной информации. |
Зависит от протокола |
PVD_CONFIG |
char FAR * |
Информационная структура, содержащая данные о сервис провайдере. |
Зависит от реализации |
Сводная таблица кодов операций для процедуры ioctl приведена ниже (таблица 7.9). Оператор WSAIoctl поддерживает также все операции, специфицированные для процедуры iocltsocket.
Таблица 7.2. Опции соединителей для оператора setsockopt.
Опция |
Тип |
Назначение |
SO_BROADCAST |
булев |
Позволяет передачу широковещательных сообщений |
SO_DEBUG |
булев |
Осуществляет запись отладочных данных. |
SO_DONTLINGER |
булев |
Разрешает закрытие без ожидания при наличии не отосланной информации. Эта опция эквивалентна SO_LINGER с l_onoff=0. |
SO_DONTROUTE |
булев |
Запрет маршрутизации - отправка непосредственно интерфейсу. |
SO_KEEPALIVE |
булев |
Посылка сообщения keepalive (“еще жив”) |
SO_LINGER |
структура |
Задержка закрытия в случае наличия не отосланной информации. |
SO_OOBINLINE |
булев |
Принимает информацию, приходящуюю по независимым каналам, в общем потоке данных |
SO_RCVBUF |
целый |
Определяет размер входного буфера |
SO_REUSEADDR |
булев |
Позволяет соединителю использовать адрес, который уже задействован |
SO_SNDBUF |
целый |
Определяет размер выходного буфера |
TCP_NODELAY |
булев |
Запрещает использование алгоритма Нагля (TCP). |
Программа getsockopt(s, int level, int optname, char far*optval, int FAR* optlen) позволяет получить значение опции для любого типа соединителей. Значения параметров обращения аналогичны setsockopt. Ниже представлена таблица (7.3) поддерживаемых опций.
В среде Windows существуют аналоги (асинхронные) многих из приведенных выше операторов. Имена этих операторов имеют префикс WSA (Windows Socket Asynchronous). Асинхронными они названы по той причине, что их выполнение сопряжено с определенным диалогом и ни начало, ни завершение не ограничено какими-либо временными рамками. Список таких операторов представлен в таблицах 7.4 и 7.5 (версия windows socket 2.2).
Таблица 7.3. Опции соединителей для оператора getsockopt
Опция |
Тип |
Назначение |
SO_ACCEPTCONN |
булев |
Соединитель в режиме listen |
SO_BROADCAST |
булев |
Разрешена передача широковещательных сообщений |
SO_DEBUG |
булев |
Отладочный режим разрешен |
SO_DONTLINGER |
булев |
Если равен TRUE, SO_LINGER-опция запрещена |
SO_DONTROUTE |
булев |
Запрет маршрутизации. |
SO_ERROR |
целое |
Выдает статус ошибок |
SO_KEEPALIVE |
булев |
Сообщение keepalive (“еще жив”) послано |
SO_LINGER |
структура |
Возвращает текущие значения опции SO_LINGER |
SO_OOBINLINE |
булев |
Принимает информацию, приходящуюю по независимым каналам, в общем потоке данных |
SO_RCVBUF |
целый |
Сообщает размер входного буфера |
SO_REUSEADDR |
булев |
Соединителю разрешено использовать адрес, который уже задействован |
SO_SNDBUF |
целый |
Сообщает размер выходного буфера |
SO_TYPE |
целый |
Тип соединителя (например, SOCK_STREAM) |
TCP_NODELAY |
булев |
Использование алгоритма Нагля запрещено (tcp). |
Таблица 7.11. Опции Winsock 2.
Опция |
Тип |
Назначение |
Значение по умолчанию |
SO_ACCEPTCONN |
BOOL |
Соединитель в режиме WSPListen. |
FALSE, если WSPListen не была выполнена |
SO_BROADCAST |
BOOL |
Соединитель сконфигурирован для передачи широковещательных сообщений. |
FALSE |
SO_DEBUG |
BOOL |
Разрешен отладочный режим. |
FALSE |
SO_DONTLINGER |
BOOL |
Если истинно, опция SO_LINGER запрещена. |
TRUE |
SO_DONTROUTE |
BOOL |
Маршрутизация запрещена. |
FALSE |
SO_ERROR |
int |
Возвращает статус ошибки и осуществляет сброс. |
0 |
SO_GROUP_ID |
GROUP |
Идентификатор группы, к которой принадлежит соединитель. |
NULL |
SO_GROUP_ PRIORITY | int |
Относительный приоритет для соединителей членов группы. |
0 |
SO_KEEPALIVE |
BOOL |
Послано сообщение “еще жив”. |
FALSE |
SO_LINGER |
struct linger |
Возвращается текущее значение опции LINGER. |
l_onoff = 0 |
SO_MAX_MSG_SIZE |
int |
Максимальный размер сообщения для соединителей, ориентированных на обмен сообщениями. Не имеет смысла для соединителей, ориентированных на потоки данных. |
Зависит от реализации |
SO_OOBINLINE |
BOOL |
Приоритетная информация получена в потоке обычных данных. |
FALSE |
SO_PROTOCOL_INFO |
struct WSAPROTOCOL_INFO |
Описание протокола для заданного соединителя. |
Зависит от протокола |
SO_RCVBUF |
int |
Размер буфера для приема. |
Зависит от реализации |
SO_REUSEADDR |
BOOL |
Адрес, к которому подключен соединитель, может быть использован другими. |
FALSE |
SO_SNDBUF |
int |
Размер буфера для отправки |
Зависит от реализации |
SO_TYPE |
int |
Тип соединителя (т.е. SOCK_STREAM). |
Как было при создании socket |
PVD_CONFIG |
char FAR * |
Структурный объект, содержащий информацию о конфигурации сервис-провайдера. |
Зависит от реализации |
TCP_NODELAY |
BOOL |
Запрещает алгоритм Нагля. |
Зависит от реализации |
В таблице 7.12 приведен список ioctl-кодов команд для соединителей.
Таблица 4.4.16.6. Операции клиента и значения полей заголовка
Имя поля |
Уникаст/Эникаст |
Мультикаст |
|
Запрос |
Отклик |
||
LI |
0 |
0-2 |
0-2 |
VN (номер версии) |
1-4 |
копируется из запроса |
1-4 |
Режим |
3 |
4 |
5 |
Слой |
0 |
1-14 |
1-14 |
Запрос |
0 |
Игнорируется |
Игнорируется |
Точность |
0 |
Игнорируется |
Игнорируется |
Root Delay |
0 |
Игнорируется |
Игнорируется |
Root Dispersion |
0 |
Игнорируется |
Игнорируется |
Reference Identifier |
0 |
Игнорируется |
Игнорируется |
Reference Timestamp |
0 |
Игнорируется |
Игнорируется |
Originate Timestamp |
0 |
(смотри текст) |
Игнорируется |
Receive Timestamp |
0 |
(смотри текст) |
Игнорируется |
Transmit Timestamp |
(смотри текст) |
не равно нулю |
не равно нулю |
Аутентификатор |
опционно |
опционно |
опционно |
6. Операции сервера SNTP
Сервер SNTP может работать в уникастном, эникастном или мультикастном режимах, а также реализовать любую из комбинаций этих режимов. В уникаст и эникаст режимах сервер получает запросы (режим 3), модифицирует определенные поля в заголовке NTP, и посылает отклик (режим 4), возможно используя тот же буфер сообщения, что и в случае запроса. В режиме эникаст сервер прослушивает определенный широковещательный или групповой мультикаст-адрес, определяемый IANA, но использует свой собственный уникастный адрес в поле адреса отправителя отклика. За исключением выбора адреса в отклике работа сервера в эникаст и уникаст режима идентична. Мультикастные сообщения обычно посылаются с интервалом от 64 до 1024 сек, в зависимости от стабильности часов клиента и требуемой точности.
В эникаст и уникаст режимах поля VN и регистрация (Poll) запроса копируются без изменений в отклик. Если поле режим запроса содержит код 3 (клиент), оно делается в отклике равным 4 (сервер); в противном случае в это поле записывается 2 (симметричный пассивный), для того чтобы обеспечить соответствие со спецификацией NTP. Это позволяет клиентам, сконфигурированным для симметричного активного режима (режим 1) успешно работать, даже если конфигурация не является оптимальной.
В мультикастном режиме в поле VN заносится код 4, в поле режим код 5 (широковещательный) и в поле регистрация целая часть значение логарифма по основанию 2 от длительности периода посылки запросов.
Заметим, что крайне желательно чтобы серверы, поддерживающие мультикастинг, поддерживали и уникастный режим. Это необходимо для измерения RTT клиент/сервер, прежде чем осуществлять регулярный обмен в мультикастном режиме.
В уникастном и эникастном режимах сервер может реагировать, а может и игнорировать запросы, если не синхронизован надлежащим образом с помощью радио-часов. Но предпочтительным поведением является присылка отклика в любом случае, так как позволяет убедиться в достижимости сервера. В мультикастном режиме сервер посылает широковещательные сообщения, только если он синхронизован.
Остальные поля заголовка NTP заполняются следующим образом. Если сервер синхронизован и функционирует правильно, в поле LI заносится 0, а в поле слой – 1 (первичный сервер). Если это не так, в поле слой записывается 0, а в поле LI - 3. В поле точность заносится код, характеризующий точность локальных часов. Для всех практических случаев этот код вычисляется, как отрицательное число бит справа от запятой в формате временной метки NTP. Поля Root Delay и Root Dispersion для первичного сервера делаются равными 0. Поле Root Dispersion опционно может быть сделано равным значению, соответствующему максимальной ожидаемой ошибке радио-часов. В поле Reference Identifier заносится идентификатор первичного эталона времени, как это указано в таблице 4.4.16.4.
Поля временных меток заполняются следующим образом. Если сервер не синхронизован или только что включился, все временные метки устанавливаются равными нулю. Если сервер синхронизован, в поле Reference Timestamp записывается время последней коррекции по радио-часам или модему. В уникастном и эникастном режимах в поля Receive Timestamp и Transmit Timestamp заносится время дня, когда было послано сообщение, а в поле Originate Timestamp записывается неизмененная копия поля Transmit Timestamp из запроса.В мультикастном режиме в поля Originate Timestamp и Receive Timestamp заносится 0, а в Transmit Timestamp время дня, когда послано сообщение. В таблице 4.4.16.7 представлены все перечисленные операции.
Таблица 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) |
Дополнительная инкапсуляция с подписью и загрузкой |
Подписанное, Е-шифрованное составное сообщение с загрузкой |
Таблица 4.6.2.15. Описание алгоритма OAEP
Шаг |
Действие |
1 |
Подготовить дополнительные данные, как это описано в формате сообщения |
2 |
Если используется оператор шифрования EH или EXH, вычислить хэш SHA-1 для данных подлежащих DES-шифрованию |
3 |
Сформировать новый случайный ключ для DES-шифрования регулярной части данных |
4 |
Объединить DES-ключ, хэш SHA-1 данных (HD) перед DES-шифрованием (если оно применяется) и любые дополнительные данные, чтобы сформировать действительный блок данных ADB (Actual Data Block). |
5 |
Взять байт, содержащий код 0х03 (тип блока – BT), семь байтов нулей (байты верификации – V) и байт блока содержимого (BC) и положить в ADB, тем самым формируя блок данных (DB). DB= BT|BC|V|ADB |
6 |
Сгенерировать случайную 16-битовую строку E-Salt и вычислить H1(E-Salt). H1 выдает лидирующие байты хэша SHA-1 |
7 |
Вычислить А=DB A H1(E-Salt) |
8 |
Осуществить присвоение B= E-Salt A H2(A). Сформировать PDB, объединив А и В. Н2 предоставляет завершающие байты хэша SHA-1 |
9 |
Присвоить I случайное значение, не равное 0х00 или 0х80 |
10 |
Зашифровать полученный блок R с помощью RSA |
Алгоритм работа OAEP показан на рисунке 4.6.2.9.
В DB присутствуют только информационные элементы типа атомик (в нотации ASN.1). Каждый элемент DB кодируется согласно требованиям DER, но без тэгов и октетов длины. При преобразовании из DER-формата в DB к концу блока данных могут добавляться нули (0х00). При обратном преобразовании такие заполнители удаляются.
Таблица 7.4. Основные операторы winsock
Имя оператора |
Назначение |
WSAAsyncGetHostByAddr |
Аналог оператора gethostbyaddr |
WSAAsyncGetHostByAddr |
Аналог оператора gethostbyaddr |
WSAAsyncGetHostByName |
Аналог оператора gethostbyname |
WSAAsyncGetProtoByName |
Аналог оператора getprotobyname |
WSAAsyncGetProtoByNumber |
Аналог оператора getprotobynumber |
WSAAsyncGetServByName |
Аналог оператора getservbyname |
WSAAsyncGetServByPort |
Аналог оператора getservbyport |
WSAAsyncSelect |
Функциональный аналог оператора select |
WSACancelAsyncRequest |
Прерывает выполнение операторов типа WSAAsyncget*by* |
WSACancelBlockingCall |
Прерывает выполнение блокирующего оператора приложения (API) |
WSACleanup |
Сообщает Windows sockets о завершении работы программы с DLL |
WSAGetLastError |
Выдает сообщение о последней ошибке |
WSAIsBlocking |
Определяет, является ли Winsock DLL блокирующей |
WSASetBlockingHook |
Устанавливает перехват блокирующего вызова |
WSASet LastError |
Фиксирует тип ошибки для последующего вызова WSALastError |
WSAStartup |
Инициализирует следующий уровень Winsock |
WSAUNhookBlockingHook |
Восстанавливает прежнюю блокировку. |
Из этого списка можно выделить две программы WSAStartup и WSACleanup, первая вызывается в начале любой процедуры, вторая - ее завершает. wsastartup может вызываться за время сессии несколько раз, она позволяет указать версию winsock или получить информацию об ее конкретной реализации. При вызове WSAStartup осуществляется диалог с динамической библиотекой WINSOCK.DLL и настройка параметров системы. При аварийном завершении программы нужно корректно окончить работу с WINSOCK.DLL. Следует при этом помнить, что WSACleanup воздействует на все потоки завершаемого процесса (например, в случае Windows 95 или NS). Определенные проблемы может вызвать перенос программ из Unix в Windows, так как там вместо read и write используются операторы recv и send, вместо ioctl - ioctlsocket, а вместо close - closesocket. Некоторые операторы вообще непереносимы: readv, writv, recvmsg и sendmsg и части программы, где они содержатся, необходимо переписать. При обнаружении ошибки Unix присваивает переменной errno соответствующее значение. В winsock для этой цели используется символьная константа SOCKET_ERROR (равная -1), а для уточнения типа ошибки следует вызвать WSAGetLastError. В системах Windows 95 или NT этот оператор обращается к программе Win32 GetLastError, которая возвращает значение ошибки для сессии, вызвавшей эту ошибку.
Таблица 4.6.2.4. Отправление сообщения
Шаг |
Действие |
1 |
Генерация сообщения SET |
2 |
Вложение кода текущей версии в MessageWrapper (цифровой конверт, сейчас 1 или 0) |
3 |
Вложить код даты, включая время. |
4 |
Заполнить MessageID из полей TransID в Message. Если MessageID в Message отсутствует, поле опускается. |
5 |
Вводится RRPID. Если это запрос, генерируется RRPID и запоминается для последующего сравнения с соответствующим кодом отклика. Если посылается отклик, то RRPID копируется из запроса. |
6 |
Вводится SWIdent. Это строка, которая идентифицирует разработчика и версию программного продукта |
7 |
Вкладывается Message |
8 |
Производится DER-кодирование вложенного сообщения |
9 |
Сообщение передается на транспортный уровень |
Процедура обработки входящего сообщения рассмотрена в таблице 4.6.2.5.
Таблица 7.1. Перечень служебных операторов для работы с соединителями (Беркли)
Имя команды |
Назначение |
getdomainname |
Возвращает имя домена |
gethostbyname |
Возвращает IP-адрес для заданного сетевого имени. |
gethostname |
Возвращает имя ЭВМ (обычно имя ее домена). |
gethostadr |
Возвращает IP-адрес ЭВМ. |
getnetaddr |
Возвращает адрес сети. |
getnetname |
Возвращает имя сети. |
getpeername |
Возвращает имя партнера, подключенного к соединителю. |
getportbyname |
Возвращает имя и код протокола для указанного имени (например, ICMP, UDP или TCP) |
getportbynumber |
Возвращает имя протокола для указанного его кода |
getservbyname |
Извлекает из базы данных название протокола и номер порта для указанного имени сетевой услуги |
getservbyport |
Возвращает имя сетевой услуги для заданного номера порта |
getsockname |
Возвращает местный адрес соединителя. |
getsockopt |
Запрашивает информацию о соединителе. |
htonl |
Преобразует порядок байтов 32-разрядного кода из машинного в сетевой. |
htons |
Преобразует порядок байтов 16-разрядного кода из машинного в сетевой. |
inet_addr |
Преобразует символьную строку IP-адреса из десятично-точечного формата в 32-разрядный код с сетевым порядком байтов. |
inet_ntoa |
Преобразует IP-адрес в десятично-точечный формат. |
ioctlsocket |
Управляет параметрами соединителя, связанными с обработкой операций ввода/вывода. |
ntohl |
Преобразует порядок байтов 32-разрядного кода из сетевого в машинный. |
ntohs |
Преобразует порядок байтов 16-разрядных кодов из сетевого в машинный. |
ethostname |
Устанавливает имя ЭВМ. |
setsockopt |
Устанавливает опции соединителя. |
shutdown |
Закрывает один из концов дуплексного канала для местной ЭВМ. |
socketpair |
Генерирует пару соединителей. |
Большинство перечисленных команд имеют развитую систему диагностики, кроме того, во многих реализациях Unix имеется много других полезных команд, описание которых вы можете найти в инструкциях по использованию системы Unix. Рассмотрим некоторые из них.
Программа ioctlsocket(s, long cmd, u_long FAR*argp) служит для получения параметров соединителя (выполнение не зависит от типа протокола и коммуникационной субсистемы).
Аргумент cmd представляет собой код команды, которая будет выполнена для соединителя s, argp - указатель на параметр команды. Возможно применение команд: FIONBIO - разрешает/запрещает режим блокировки соединителя s (команда WSAAsyncSelect ставит соединитель в режим запрета блокировок автоматически). FIONREAD - определяет объем данных, которые могут быть автоматически считаны через соединитель s. SIOCATMARK - задает режим чтения приоритетной информации (для соединителей типа SOCK_STREAM.
Программа setsockopt(s, int level, int optname, const char far*optval, int optlen) устанавливает текущие значения опций для соединителя s. Аргумент level описывает уровень, на котором определена данная опция (например, SOL_SOCKET или IPPROTO_TCP). optname - имя опции, значение которой устанавливается, optval - указатель на буфер, где лежит значение опции, optlen - размер этого буфера. Для опции SO_LINGER - это размер структуры, для остальных - длина целого. При корректном исполнении setsockopt возвращает нуль, в противном случае SOCKET_ERROR. Программа setsockopt поддерживает следующие опции (BSD поддерживает и некоторые другие опции; колонка тип соответствует значению optval, таблица 7.2):
Имя | Ограничения на формат и значения | Описание |
Version (Версия) | Целое | Указывает на версию сертификата |
SerialNumber | Целое | Уникальный порядковый номер, приписываемый СА, сформировавшим сертификат |
Signature.AlgorithmIdentifier | OID и тип | Определяет алгоритм, используемый для генерации подписи сертификата |
Issuer (эмитент) | Имя | Содержит уникальное имя (Distinguished Name) CA, выдавшего сертификат |
Validity.notBefore | Время UTC | Специфицирует время, когда сертификат становится активным |
Validity.notAfter | Время UTC | Специфицирует время, когда сертификат перестает действовать. Если это относится к сертификату владельца карты, то его время действия не может быть дольше пригодности карты. |
Subject | Имя | Содержит уникальное имя объекта владельца ключа |
SubjectPublicKeyInfo.algorithm. AlgorithmIdentifier | OID и тип | Специфицирует алгоритм, который может использоваться с этим ключом. |
SubjectPublicKeyInfo. subjectPublicKey | Строка битов | Содержит общедоступный ключ, представленный в запросе сертификата |
IssuerUniqueID | В SET не используется | |
SubjectUniqueID | В SET не используется | |
Extensions.extnId | Формат OID | Содержит расширение OID, как это определено Х.509 или SET |
Extensions.critical | Булево: 0=ложно 1=истинно | Каждое описание расширения определяет то, какое значение должно принимать это поле |
Extensions.extnValue | Информация расширения |
Country | 2 символа кода страны (ISO 3166) |
BrandID | <Brand Name>:<Product>, где название продукта является опционным. |
Brand Name | Платежная система карты, которая определяется разработчиками платежной системы. |
Product Type | Опционное поле, которое определяет тип продукта в рамках заданной платежной системы. |
Описательное имя | Это описательное имя объекта, ответственного за выпуск сертификата в рамках данного СА. Например: Название финансовой организации Название организации, выполняющей функцию СА Название платежной системы Имя объекта, ответственного за одобрение сертификатов |
Официальное название карты | Это опционное поле содержит официальное название карты. Примерами могут служить, например: Frequent Flayer Program, Affinity Program и т.д. |
Название финансовой организации | Имя финансовой организации, выпускающей расчетные карты |
Уникальный идентификатор владельца карты | Уникальным идентификатором владельца карты в сертификате владельца является хэшированный номер его счета. |
Уникальный идентификатор расчетного центра | Поле содержит BIN, за которым следует серийные номера банка продавца или расчетной системы. Поле форматировано как <BIN:SerialNumber>. Серийный номер позволяет однозначно идентифицировать каждый расчетный центр, ассоциированный с одним и тем же банком продавца (Acquirer). В пределах расчетной системы (Brand) может быть несколько сертификатов для одного BIN. |
K | Равно PANSecret и представляет собой 20-байтовую строку, полученную в результате операции исключающее ИЛИ, выполненной над DER-кодированными значениями CardSecret и Nonce-CCA. |
Text | Представляет собой DER-кодированную копию исходного текста, содержащего PAN и CardExpiry. Text ::= SEQUENCE { pan PAN cardExpiry CardExpiry } PAN ::= NumberString (SIZE(1..19)) CardExpiry ::= NumericString (SIZE(6)) --YYYMM Время истечения действия карты |
ipad | 64 байта, содержащих код 0x36 |
opad | 64 байта, содержащих код 0x5C |
Таблица 4.6.2.1. Поля MessageWrapper
Название поля |
Описание |
Message-Wrapper |
{MessageHeader, Message, [MWExtension]}} |
MessageHeader |
{Version, Revision, Date, [MessageID], [RRPID], SWIdent} |
Version |
Версия SET-сообщения |
Revision |
Подтип SET-сообщения |
Date |
Дата генерации сообщения |
MessageID |
{[LID-C], [LID-M], [XID]} |
RRPID |
Идентификатор, позволяющий объединять в пары запросы и отклики |
SWIdent |
Идентификация программы (поставщик и версия), инициировавшей запрос. Эта информация представляется строкой символов |
Message |
< PInitReq, PInitRes, PReq, PRes, InqReq, InqRes, AuthReq, AuthRes, AuthRevReq, AuthRevRes, CapReq, CapRes, CapRevReq, CapRevRes, CredReq, CredRes, CredRevReq, CredRevRes, PCertReq, PCertRes, BatchAdminReq, BatchAdminRes, CardCInitReq, CardCInitRes, Me-AqCInitReq, Me-AqCInitRes, RegFormReq, RegFormRes, CertReq, CertRes, CertInqReq, CertInqRes, Error> |
LID-C |
Локальный идентификатор, генерируемый системой владельца карты или для его системы |
LID-M |
Локальный идентификатор, генерируемый системой продавца или для его системы |
XID |
Глобальный идентификатор, генерируемый продавцом (или владельцем карты, если нет PInitRes) |
MWExtension |
Расширение сообщения SET. Расширение используется, когда информация в расширении является общей, описывающей сообщения SET, или когда содержимое сообщения зашифровано, а расширение содержит нефинансовую информацию, не требующую конфиденциальности. |
Обработка сообщения начинается с MessageWrapper. Каждое сообщение должно иметь незашифрованный конверт MessageWrapper, который декодируется перед началом обработки самого сообщения. Поля TransID и RRPID используются для ранней диагностики дублированных сообщений.
При декодировании MessageWrapper компонента Message не может обрабатываться, но его тип можно определить по полю тип (DER) сообщения. По завершении декодирования MessageWrapper производится дешифрование и верификация подписи Message. После этого проводится декодирование Message. Обработка этого компонента зависит от его типа.
При описании протокола используется нотация представленная в таблице 4.6.2.2.
Таблица 4.6.2.7. Посылка оттиска
Шаг |
Действие |
1 |
Инициализировать буфер для запоминания оттисков |
2 |
Добавить оттиск (хэш): Для каждого сертификата, который имеется в кэше отправителя и имеет отношение к обрабатываемому сообщению-отклику и для всей цепочки сертификатов добавляется оттиск (хэш), соответствующий этому сертификату. Для каждого CRL, который имеется в кэше отправителя и имеет отношение к обрабатываемому сообщению-отклику и для всей цепочки сертификатов добавляется оттиск (хэш), соответствующий этому CRL. Для каждого BCI, который имеется в кэше отправителя и имеет отношение к обрабатываемому сообщению-отклику и для всей цепочки сертификатов добавляется оттиск (хэш), соответствующий этому BCI. |
3 |
Присылается результат работы шага 2. |
Получатель проверяет то, что отправитель владеет всеми сертификатами, CRL и BCI, необходимыми для завершения обработки сообщения. Получатель может проигнорировать оттиски и послать эту информацию запросившему. Обработка оттисков получателем представлена в таблице 4.6.23.8.
Таблица 4.6.2.5. Прием и обработка входного сообщения
Шаг |
Действие |
1 |
Извлекается цифровой конверт сообщения |
2 |
Проверяется формат и содержимое полей цифрового конверта сообщения: версия, субверсия, дата/время, тип сообщения. Если обнаружена ошибка, возвращается отклик Error с ErrorCode. |
3 |
Используя RRPID, производится сравнение и актуализация контрольного журнала на предмет выявления повторных сообщений |
4 |
Произвести DER-декодирование сообщения |
5 |
Если сообщение содержит SignedData, произвести следующее: Актуализовать системный кэш с учетом полученных CRL. Для каждого полученного сертификата, произвести верификацию цепочки сертификатов Проверить подпись сообщения |
6 |
Если сообщение содержит инкапсулированные данные, выполняется извлечение вложенных данных согласно типу вложенного содержимого, включая шаг 5, если вложенные данные содержат SignedData |
7 |
Извлечь идентификаторы BrandCRLIdentifier, включенные в сообщение и актуализовать системный кэш, проверить, что все CRL, идентифицированные BCI, находятся в системном кэше. В противном случае обработка сообщения прерывается. |
8 |
Обработать сообщение |
9 |
Актуализовать системный журнал с учетом состояния транзакции |
Верификация цепочки сертификатов требует, чтобы последовательно проверялся каждый сертификат, и контролировалось его соответствие выпустившему его центру. Например, держатель карты должен проверить сертификаты продавца, центра сертификации продавца, центра сертификации платежной системы (Brand CA), и корневого центра Root CA. Процесс верификации включает в себя следующие компоненты:
Контроль сертификатов X.509
Контроль сертификатов SET
Обработку CRL (Certificate Revocation List)
Обработку BrandCRLIdentifier (BCI)
На практике предполагается, что процесс верификации будет остановлен на уровне, который был успешно пройден ранее. Все приложения SET помимо самих сертификатов контролируют их дату пригодности. Процедура верификации представлена в таблице 4.6.2.6.
Таблица 4.6.2.9. Процедура асимметричного шифрования
Шаг |
Действие |
1 |
Инициализировать и загрузить информационные поля, зависимые от типа сообщения |
2 |
Преобразовать информационные поля, подлежащие шифрованию, в формат DER |
3 |
Сформировать новый ключ DES |
4 |
Зашифровать результат работы шага 2, используя ключ DES из шага 3. Используется режим DES-CBC. |
5 |
Инициализировать буфер зашифрованных данных с помощью кода типа данных, идентификатора алгоритма и добавить эту информацию к результату шага 4. |
6 |
Инициализировать буфер цифрового конверта, в зависимости от получателя (128 байт) |
7 |
Инициализировать буфер дополнительного шифрования OAEP с использование ключа из шага 3. |
8 |
Применить OAEP для буфера цифрового конверта |
9 |
Зашифровать результат шага 8, используя асимметричный общедоступный ключ объекта r |
10 |
Инициализировать информационный буфер получателя посредством идентификатора алгоритма RSA и добавить туда результат работы шага 9 |
11 |
Инициализировать буфер EnvelopedData PKCS#7 и положить туда результат шага 10 и 5 |
12 |
Прислать результат шага 11 |
Оператор шифрования с гарантией целостности EH(r,t) подобен Е за исключением того, что цифровой конверт PKCS#7 включает в себя хэш группы t. Он предполагает быстрое симметричное шифрование открытого текста сообщения и последующее шифрование секретного ключа с использование общедоступного ключа получателя. Процедура такого шифрования представлена в таблице 4.6.2.10.
Таблица 4.6.2.12. Процедура формирования цифровой подписи
Шаг |
Действие |
1 |
Инициализировать тип SignedData, введя код версии, идентификатор алгоритма и тип содержимого, подлежащего подписанию |
2 |
Преобразовать информацию, подлежащую подписанию в формат DER |
3 |
Использовать результат шага 2 для инициализации компонента content из ContentInfo. |
4 |
Инициализировать тип SignerInfo, введя код версии, идентификаторы алгоритмов вычисления и шифрования дайджеста |
5 |
Вычислить дайджест сообщения, используя SHA-1 для результата шага 3 |
6 |
Инициализировать структуру authenticatedAttributes и занести в структуру атрибуты contentType и messageDigest. Установить компоненты type атрибутов равными идентификаторам этих атрибутов |
7 |
Инициализировать компонент values первого атрибута типа кодом содержимого, подлежащего подписанию, а второго атрибута – значением дайджеста, вычисленного на этапе 5 |
8 |
Закодировать аутентифицированные атрибуты и зашифровать результат, используя секретный ключ отправителя. Поместить результат в SignedData |
9 |
Выбрать соответствующие сертификаты Х.509 и CRL, необходимые для верификации подписи, и включить их в SignedData |
10 |
Если тип сообщения требует двух подписей, повторить шаги с 4 по 9 |
Оператор ключевого хэширования HMAC(t,k) соответствует 160-битовому хэшу HMAC-SHA-1 для группы t при использовании секретного ключа k. Эта функция нужна для сокрытия номера счета в сертификате владельца карты. Секретный ключ известен только владельцу карты и эмитенту. Процедура ключевого хэширования представлена в таблице 4.6.2.13.
Таблица 4.6.2.13. Процедура ключевого хэширования
Шаг |
Действие |
1 |
Установить ipad соответствующим буферу, который содержит 64 байта с кодами 0х36 |
2 |
Установить opad равным буферу, содержащему 64 байта с кодами 0х5С |
3 |
Добавить нули в конец k, чтобы размер строки стал равным 64 байтам. Например, если длина k равна 20 байт, то следует добавить 44 нуля. |
4 |
Осуществить операцию побитового исключающего ИЛИ для результата шага 3 и ipad |
5 |
Добавить данные группы t в 64-байтовый буфер, сформированный на этапе 4 |
6 |
Вычислить хэш SHA-1 для результата шага 5 с привлечением Hash-оператора |
7 |
Осуществить операцию побитового исключающего ИЛИ для результата шага 3 и opad |
8 |
Добавить результат SHA-1 шага 6 к 64-байтовому буферу, заполненному в результате шага 7 |
9 |
Вычислить хэш SHA-1 для результата шага 8 с привлечением Hash-оператора |
10 |
Прислать результат работы шага 9 |
Оператор хэширования H(t) соответствует 160-битовому хэшу SHA-1 для группы t. Этот оператор соответствует параметризованному типу ASN.1 H{}. Он используется только в обработке OAEP.
Оператор DigestedData DD(T) соответствует 160-битовому хэшу SHA-1 группы, вложенной в последовательность PKCS DigestedData. Протокол SET использует параметризованный тип DD{} (detached digests). Каждый тип содержимого типа дайджест в SET имеет имя, уникальный идентификатор объекта. Компонент contentType из ContentInfo делается равным значению этого идентификатора.
Компонент digest из DigestedData является результатом вычисления дайджеста сообщения. Он содержит дайджест сообщения типа SET, идентифицируемый компонентом contentType из contentInfo. Дайджест вычисляется с помощью алгоритма из перечня DigestAlgorithm. Вычисление производится для полного DER-представления, включая тэг, длину в октетах и типа ASN.1. Компонент digestAlgorithm из DigestedData устанавливается равным одному из значений кодов алгоритма. Код digestAlgorithm используется получателем для проверки дайджеста сообщения. Верификация осуществляется путем независимого вычисления дайджеста сообщения и сравнения его значения с компонентом digest из DigestedData. Последовательность действий показана в таблице 4.6.2.14.
Таблица 4.6.2.11. Процедура симметричного шифрования
Шаг |
Действие |
1 |
Инициализировать и загрузить информационные поля, зависимые от типа сообщения |
2 |
Преобразовать информационные поля, подлежащие шифрованию, в формат DER |
3 |
Зашифровать результат работы шага 2, используя ключ k. Применяется алгоритм DES или CDMF в зависимости от того, какой из этих алгоритмов поддерживается получателем сообщения. Для DES используется режим DES-CBC. |
4 |
Инициализировать буфер зашифрованных данных с помощью кода типа данных, идентификатора алгоритма (DES или CDMF) и добавить к этой информации результат шага 3. |
5 |
Прислать результат шага 4 |
Оператор цифровой подписи S(s,t) соответствует PKCS#7 SignedData для группы t, подписанной объектом s. Для SET алгоритмом подписи по умолчанию является RSA с хэшем SHA-1. Обычно для SET подпись делается до шифрования.
Операция цифровой подписи для SignedData всегда производится над данными, представленными в формате DER (ASN.1). Операции подпись SignedData никогда не производятся для произвольных строк октетов (например, для ASCII-строк). По этой причине тип содержимого data не используется никогда. PKCS#7 требует включения в подписываемый текст двух аутентифицированных атрибутов. Такими атрибутами являются contentType и messageDigest, оба они включаются в содержимое, которое подписывается в рамках SET. SignedData имеет формат DER, и содержат октеты тэга и длины атрибутов. Исходные данные для расчета дайджеста сообщения берутся из компонента content последовательности ContentInfo. ContentInfo связывает идентификатор компонента contentType с типом компонента >content. В SET каждый тип содержимого однозначно именуется объектным идентификатором. Так как это значение не защищено от атак подмены, он также включается в authenticateAttributes. Атрибут contentType специфицирует идентификатор объекта, который соответствует значению компонента contentType последовательности ContentInfo. Атрибут messageDigest содержит значение хэшированного компонента content ContentInfo.
Определение последовательности SignerInfos в PKCS#7 допускает любое число подписантов (по одному SignerInfo на каждого). SET PKCS#7 SignedData требует наличия одного подписанта для всех сообщений кроме CertReq и CertInqReq, которые требуют две подписи, когда используются для обновления сертификата. Таким образом, требования SET несколько мягче, чем PKCS#7.
В компоненте SignerInfo из SignerInfos как authenticateAttributes, так и unauthenticateAttributes компоненты специфицируются опционно. В SET компонент unauthenticateAttributes
последовательности SignerInfo всегда отсутствует и никогда не появляется при кодировании SignedData. Компонент же authenticateAttributes всегда присутствует и включается в процесс вычисления дайджеста. Процедура цифровой подписи представлена в таблице 4.6.2.12.
Таблица 4.6.2.14. Процедура вычисления дайджеста сообщения.
Шаг |
Действие |
1 |
Установить B равным адресу группы t, для которой вычисляется дайджест |
2 |
Установить L равным длине группы t |
3 |
Инициализировать 160-битный буфер для хранения хэша SHA-1 |
4 |
Вычислить хэш SHA-1 для буфера, используя B и L |
5 |
Положить результат шага 4 в поле digest DigestedData |
6 |
Положить идентификатор хэш-алгоритма SHA-1 в digestAlgorithm |
7 |
Установить значение версии равным нулю |
Оператор связи L(t1,t2) соответствует последовательности t1 и DigestedData. Компонент связи DigestedData содержит дайджест сообщения для группы t2 и может быть представлен посредством DD(t2). Оператор связи не является симметричным и не может связать t2 с t1.
Целью OAEP является обеспечение гарантии того, что отдельные фрагменты сообщения не будут извлечены из блока PKCS#7. Существуют криптографические методы, которые позволяют определить одни биты сообщения легче, чем другие. OAEP случайным образом перераспределяет биты блока PKCS#7 так, что все биты становятся с этой точки зрения эквивалентными.
Примитивы шифрования E, EH, EX и EXH объединяют RSA-шифрование и алгоритм OAEP (Bellare-Rogaway Optimal Asymmetric Encryption Padding). SET использует OAEP для получения дополнительной защиты информации о счете клиента (владельца карты, продавца или получателя) с помощью цифрового конверта. Реализация алгоритма OAEP продемонстрирована в таблице 4.6.2.15.
Таблица 4.6.2.25. Шаблон регистрационной формы MCA и PCA
Me-AqCInitRes |
S(CA, Me-AqCInitResTBS) |
Me-AqCInitResTBS |
{RRPID, LID-EE, Chall-EE, [LID-CA], Chall-CA, RequestType, RegFormOrReferral, [AcctDataField], [Thumbs]} |
RRPID |
ID пары запрос/отклик |
LID-EE |
Копируется из Me-AqCInitReq |
Chall-EE |
Копируется из Me-AqCInitReq |
LID-CA |
Локальный ID; генерируется СА системой или для нее |
Chall-CA |
СА обращение по поводу пригодности сертификата запрашивающей стороны |
RequestType |
Смотри табл. 4.6.2.24 |
RegFormOrReferral |
Смотри табл. 4.6.2.21 |
AcctDataField |
RegField; дополнительное поле регистрационной формы, которое следует отобразить, для того чтобы получить значение AcctData в CertReq |
CAEThumb |
Оттиск сертификата ключевого обмена СА, который должен использоваться для шифрования CertReq |
BrandCRLIdentifier |
Смотри раздел описания BrandCRLIdentifier ниже. |
Thumbs |
Копируется из Me-AqCInitReq |
Приложение SET (продавца или расчетного центра) обрабатывает Me-AqCInitRes
следующим образом:
Шаг | Действие | |
1 | Получить Me-AqCInitRes из входного сообщения. | |
2 | Верифицировать подпись. Если она некорректна, послать сообщение об ошибке с ErrorCode равным signatureFailure. | |
3 | Из Me-AqCInitResTBS извлекаются и запоминаются RRPID, LID-EE, Chall-EE, CAEThumb, BrandCRLIdentifier, оттиски и TequestType | |
4 | Проверяется, что RRPID совпадает со значением, извлеченным из цифрового конверта сообщения и кодом, посланным в Me-AqCInitReq. Если равенства нет, посылается сообщение об ошибке с ErrorCode равным unknownRRPID. | |
5 | Проверяется, что полученный Chall-EE соответствует посланному в Me-AqCInitReq. Если соответствие отсутствует, посылается сообщение об ошибке с ErrorCode равным challengeMisMatch. | |
6 | Проверяется, что полученный список оттисков соответствует посланному в сообщении Me-AqCInitReq. Если соответствие отсутствует, посылается сообщение об ошибке с ErrorCode равным thumbsMisMatch. | |
7 | Если в Me-AqCInitResTBS включено поле RegFormData то:
Запомнить LID-CA и Chall-CA Отобразить текст общих требований и ввод пользователя, прежде чем приложение SET сформирует CertReq Отобразить видимые поля регистрационной формы и приглашение пользователю для заполнения этих полей Если Me-AqCInitResTBS содержит URL, отобразить логотипы расчетной системы и/или карты Если присутствует поле AcctDataField, отобразить имя и описание, а также приглашение пользователю для заполнения этого поля Заполнить невидимые поля регистрационной формы. Если приложение не может заполнить поле, оно будет оставлено пустым, остальные поля будут заполнены обычным порядком и пересланы в CertReq. | |
8 | После того как продавец или расчетный центр заполнили регистрационную форму и ввели AcctData, (если это требуется) генерируется CertReq. | |
9 | Если в Me-AqCInitResTBS включено поле ReferrelData, то:
Отображается причина Если включено поле ReferralLoc, отображается URL или электронный адрес из ReferralLoc CertReq не генерируется. Протокол продолжит работу с посылки Me-AqCInitReq |
Шаг | Действие |
1 | Если RequestType соответствует новому сертификату подписи или его обновлению, формируется пара ключей (общедоступный/секретный), необходимых для подписи сертификата |
2 | Если запрашивающим субъектом не является владелец карты и, если RequestType соответствует новому сертификату шифрования, формируется пара ключей (общедоступный/секретный), необходимых для сертификата шифрования. |
3 | Если ЕЕ является владельцем карты, генерируется 160-битовый случайный код – CardSecret. |
4 | Генерируется 160-битовый случайный код – EXNonce |
5 | Формируется CertReqTBS: Генерируется RRPID Если ЕЕ получил RegFormRes или Me-AqCInitRes, копируется RequestType из этого сообщения, в противном случае вводится требуемый RequestType. Заполняется поле RequestData Копируется LID-EE (если присутствует) и Chall-CA из предыдущего сообщения. Если его нет, генерируется новый. Генерируется новый Chall-EE3 Копируется LID-CA, (если присутствует) и Chall-CA из предыдущего сообщения. Если ЕЕ является продавец карты или расчетный центр, то: заполняется поле IDData и, если в Me-AqCInitRes включено поле AcctDataField, записывается AccData, введенная ЕЕ Если ЕЕ является продавец, занести PAN, CardExpiry и CardSecret. Сформировать EXNonce Скопировать RegForm ID, который был послан в RegFormRes или Me-AqCInitRes Если RegFieldSeq присутствовал в Me-AqCInitRes или RegFormRes, включить новую или исправленную форму. |
6 |
Если приложение владельца карты выберет алгоритм шифрования CertRes, производится заполнение ID алгоритма и ключа в CaBackKeyData. Если общего алгоритма не найдено, процесс прерывается, о чем уведомляется пользователь. Заносится вновь сформированный общедоступный ключ, PublicKeyS и/или PublicKeyE, предназначенный для сертификации СА. Если ЕЕ является продавец или расчетный центр, а тип запроса соответствует обновлению сертификата шифрования, заполняется EEThumb с оттиском сертификата, подлежащего обновлению. Если тип запроса соответствует обновлению сертификата подписи, оттиск сертификата подписи не требуется, так как CertReq подписан им. Опционно включается список, который содержит оттиски для каждого CRL, сертификата SET, BrandCRLIdentifier и корневого сертификата, резидентно размещенных в кэше. |
7 | Данные, подлежащие дополнительному шифрованию, имеют следующий формат. Если ЕЕ является продавец карты, заполняется PAN, CardExpiry, CardSecretCardNonce и EXNonce в PANData0. Если ЕЕ является продавец или расчетный центр, опционно заполняется AccTData и EXNonce. |
8 | Данные укладываются в конверт с использованием техники EncX: Включить: Обработка а. В качестве подписанных данных CertReqTBS То, как данные подписываются зависит от RequestType. Имеется как минимум одна и допускаются две подписи, т.е. SignerInfo для CertReq. Если тип запроса относится к новому сертификату подписи, подписать данные, используя секретный ключ, соответствующий общедоступному ключу, содержащемуcя в PublicKeyS. Если тип запроса относится к обновлению сертификата подписи, подписать данные, используя секретный ключ, соответствующий общедоступному ключу, содержащемуся в PublicKeyS и, используя секретный ключ, соответствующий обновляемому сертификату. Если тип запроса относится к сертификату шифрования, подписать данные, используя секретный ключ, соответствующий существующему сертификату подписи. Если данные подписаны секретным ключом, который не соответствует сертификату, установить SignerInfo.SerialNumber равным нулю, а SignerInfo.IssuerName=”Null-DN”, т.е. RDNSequence равна кодированному NULL. Тип содержимого SignedData устанавливается равным id-set-content-CertReqTBS. b. Результат шага 6 в качестве данных, подлежащих дополнительному шифрованию Провести дополнительное шифрование, используя СА-сертификат, указанный CAEThumb в CardCInitRes или RegFormRes, если один из них был включен, или Me-AqCInitRes c. CertReqTBEX в качестве данных, подлежащих шифрованию Зашифровать CertReqTBEX и установить тип содержимого EnvelopedData равным id-set-content-CertReqTBEX |
9 | Сформировать цифровой конверт и послать сообщение CertReq центру СА |
Шаг | Действие |
1 | Если RequestType соответствует обновлению сертификата подписи, формируется пара ключей (секретный/общедоступный) для сертификата подписи |
2 | Если RequestType соответствует новому или обновляемому сертификату шифрования, формируется пара ключей (секретный/общедоступный) для сертификата шифрования |
3 | Сгенерируется 160-битное случайное число - EXNonce |
4 | Данные CertReqData формируются следующим образом: Генерируется RRPID Если продавец или расчетный центр получают Me-AqCInitRes, RequestType копируется из этого сообщения, в противном случае это поле заполняется обычным путем. Заполняется поле ReqestDate Копируется LID-EE из предыдущего сообщения. Если такового нет, генерируется новое. Генерируется новое Chall-EE3 Копируется LID-CA (если имеется) и Chall-CA из предыдущего сообщения, если таковое имеется. Заполнить поле IDData Занести RegFormID, полученный из Me-AqCInitRes Занести новую или скорректированную форму RegForm Занести вновь сформированные общедоступные ключи, PublicKeyS и/или PublicKeyE, предназначенные для сертификации СА. Если RequestType соответствует обновлению сертификата шифрования, заполняется EEThumb оттиском сертификата, подлежащего обновлению. Опционно включается список, который содержит оттиски каждого CRL, сертификата SET, BrandCRLIdentifier и корневого сертификата, резидентные в кэше владельца карты. |
5 | Поместить данные в цифровой конверт, используя инкапсуляцию Enc: Включить: Обработка CertReqData в качестве информации, подлежащей подписыванию. То, как подписываются данные, зависит от RequestType. Имеется как минимум одна и допускаются две подписи, т.е. SignerInfo для CertReq. Если тип запроса соответствует новому сертификату подписи, данные подписываются с применением секретного ключа, составляющего пару с общедоступным ключом, который содержится в PublicKeyS. Если тип запроса соответствует обновлению сертификата подписи, данные подписываются с применением секретного ключа, составляющего пару с общедоступным ключом, который содержится в PublicKeyS, а затем посредством секретного ключа, соответствующего обновляемому сертификату. Если тип запроса соответствует сертификату шифрования, данные подписываются с применением секретного ключа, составляющего пару с общедоступным ключом, который соответствует существующему сертификату подписи. Если данные подписаны ключом, который еще не соответствует сертификату, следует установить Signer.Info.SerialNumber равным “Null-DN”. Тип содержимого SignedData делается равным id-set-content-CertReqData. Производится DER-кодирование полученной информации SignedData с целью получения CertReqTBE. Ключ DES в качестве данных, подлежащих дополнительному шифрованию Для Enc-обработки единственной информацией, которая должна быть зашифрована, является симметричный ключ, используемый для шифрования “обычных данных”. Шифруется ключ с применением сертификата, указанного посредством CAEThumb в Mt-AqCInitRes. CertReqTBE в качестве обычных данных, подлежащих шифрованию Шифруется CertReqTBE и устанавливается ContentType равным id-set-Content-CertReqTBE. |
6 | Подготовить цифровой конверт и послать CertReq центру СА |
Таблица 2.4.1 Скорости передачи данных по цифровым каналам
Линия |
Быстродействие Мбит/с |
Число аудио каналов |
DS-0 |
0,064 |
1 |
T-1 |
1,544 |
24 |
T-1C |
3,152 |
48 |
T-2 |
6,312 |
96 |
T-3 |
44,736 |
672 |
Таблица 2.4.2. Скорости передачи данных по оптическим каналам
Линия OC-x |
Быстродействие Мбит/с |
Число аудио каналов |
STM-x |
1 |
51,84 |
672 |
- |
3 |
155,52 |
2016 |
1 |
9 |
466,56 |
6048 |
3 |
12 |
622.08 |
8064 |
4 |
24 |
1244,16 |
16128 |
8 |
48 |
2488,32 |
32256 |
16 |
96 |
4976,64 |
64512 |
32 |
192 |
9953,28 |
129024 |
64 |
Еще одним методом, нацеленным на повышение эффективности преобразования входного аналогового сигнала в код, является дельта-модуляция.
Таблица 4.3.6.1. Сравнение европейской и американской иерархии каналов
Уровень иерархии |
Скорости передачи для иерархий |
||
Американская 1544 Кбит/c |
Европейская 2048 Кбит/c |
Японская 1544 Кбит/c |
|
0 |
64 (DS0) |
64 |
64 |
1 |
1544 (DS1) |
2048 (Е1) |
1544 (DS1) |
2 |
6312 (DS2) |
8448 (Е2) |
6312 (DS2) |
3 |
44736 (DS3) |
34368 (Е3) |
32064 (DSJ3) |
4 |
274176 (Не входит в рекомендации МСЭ-Т) |
139264 (Е4) |
97728 (DSJ4) |
Но добавление выравнивающих бит в PDH делает затруднительным идентификацию и вывод потоков 64 Кбит/с или 2 Мбит/с, замешанных в потоке 140 Мбит/с, без полного демультиплексирования и удаления выравнивающих бит. Если для цифровой телефонии PDH достаточно эффективна, то для передачи данных она оказалась недостаточно гибкой. Именно это обстоятельство определило преимущество систем SONET/SDH. Эти виды иерархических систем позволяют оперировать потоками без необходимости сборки/разборки. Структура кадров позволяет выполнять не только маршрутизацию, но и осуществлять управление сетями любой топологии. Здесь использован чисто синхронный принцип передачи и побайтовое, а не побитовое чередование при мультиплексировании. Первичной скоростью SONET выбрана 50688 Мбит/с (ОС1). Число уровней иерархии значительно расширено (до 48). Кратность уровней иерархии равна номеру уровня.
CCITT выработал следующие рекомендации на эту тему: G.707, G.708 и G.709. CCITT разработал рекомендации для высокоскоростных каналов H:
H0 |
|
384 Кбит/с=4*64 Кбит/с. 3*h0=1,544 Мбит/с |
H1 |
H11 |
1536 Кбит/с |
H12 |
1920 Кбит/с |
|
h4 |
|
~135 Мбит/с |
H21 |
|
~34 Мбит/с |
H22 |
|
~55 Мбит/с. |
На нижних уровнях SDH и SONET в некоторых деталях различаются. Внедрение стандарта SONET ликвидировало многие недостатки каналов T-1 (ограничения на размер максимальной полезной нагрузки, простота стыковки скоростных каналов связи). SONET хорошо согласуется с ATM и FDDI, что создает фундаментальный базис для широкополосных сетей ISDN (B-ISDN). Следует учитывать, что SONET сохраняет совместимость с уже существующими каналами, убирая лишь некоторые присущие им недостатки.
Одним из базовых каналов сегодня является T-1 (1544 Кбит/с для США). Он содержит в себе 24 субканалов DS-0 (digital signal at zero level, 64 Кбит/с, США). Мультиплексирование 24 каналов DS-0 по времени формирует канал DS-1 (24 канала*64 Кбит/с)+8 Кбит/с=1544 Кбит/с, последнее слагаемое связано с заголовками информационных блоков). Этой величине соответствует в Европе 2048 Кбит/с (канал E-1 = 30*ds0). Два канала T-1 образуют канал T-1c, четыре канала T-1 формируют канал T-2, а семь T-2 (28 T-1) образуют T-3. Для оптических систем связи в качестве базового принят канал OC-1, равный по пропускной способности T-3. А кадр STS-1 выбран в качестве основного в системе SONET. Кадр STS-1 имеет 9 строк и 90 столбцов (810 байт). Кадры передаются с частотой 8 кГц, что дает для канала STS-1 51840 Кбит/с = 8000Гц*810байт*8бит. Эта цифра характеризует физическую скорость обмена, включающую в себя передачу служебной информации (заголовков), эффективная информационная пропускная способность равна 50112 Кбит/с. Быстродействие каналов более высокого уровня SONET получается умножением пропускной способности STS-1 (51,84 Мбит/с) на целое число. Так пропускная способность OC-3 будет равна 155,52 Мбит/с, а OC-24 - 1244,16 Мбит/с и т.д. Целью создателей SONET было прямая стыковка оптических каналов различных сервис-провайдеров (вспомним, что непосредственное соединение каналов T-1 и E-1 не возможно). SDH допускает сцепление нескольких контейнеров (в том числе и разных размеров), если в один контейнер данные не помещаются. Допускается объединение нескольких контейнеров равного размера в один большой. Хотя относительный размер заголовка виртуального контейнера невелик (~3,33%), его объем достаточен для передачи достаточно больших объемов служебной информации (до 5,184 Мбит/c).
В SONET предусмотрено четыре варианта соединений: точка-точка, линейная цепочка (add-drop), простое кольцо и сцепленное кольцо (interlocking ring). Линейные варианты используются для ответвлений от основного кольца сети.
Наиболее распространенная топология - самовосстанавливающееся кольцо (см. также FDDI). Такое кольцо состоит из ряда узлов, которые связаны между собой двухсторонними линиями связи, образующими кольцо и обеспечивающими передачу сообщений по и против часовой стрелки. Способность сетей SONET к самовосстановлению определяется не только топологией, но и средствами управления и контроля состояния. При повреждении трафик перенаправляется в обход, локально это приводит к возрастанию информационного потока, по этой причине для самовосстановления сеть должна иметь резерв пропускной способности (как минимум двойной). Но, проектируя сеть, нужно избегать схем, при которых основной и резервный маршрут проходят через одну и ту же точку, так как они могут быть, если не повезет, повреждены одновременно. Резервные пути могут использоваться для низкоприоритетных обменов, которые могут быть заблокированы при самовосстановлении.
Сети SONET (и SDH) имеют 4 архитектурных уровня:
Фотонный (photonic) - нижний уровень иерархии. Этот уровень определяет стандарты на форму и преобразование оптических сигналов, на электронно-оптические связи.
Секционный (section) - предназначен для управление передачей STS-кадров (sonet) между терминалами и повторителями. В его функции входит контроль ошибок.
Линейный (line) - служит для синхронизации и мультиплексирования, осуществляет связь между отдельными узлами сети и терминальным оборудованием, например линейными мультиплексорами, выполняет некоторые функции управления сетью.
Маршрутный (path) - описывает реальные сетевые услуги (T-1 или T-3), предоставляемые пользователю на участке от одного терминального оборудования до другого.
Существующие PDH-сети мультиплексируют каналы, используя каскадную схему, показанную на Рисунок 4.3.6.1.
Таблица 4.6.2.30. Статусные коды для запросов сертификата
Код |
Значение |
Источник |
requestComplete |
Запрос сертификата одобрен |
CA |
invalidLanguage |
В запросе указан неверный язык |
CA |
invalidBIN |
Запрос сертификата отклонен из-за некорректного BIN |
Эмитент или получатель |
sigValidationFail |
Запрос сертификата отклонен по причине некорректной подписи |
CA |
decryptionError |
Запрос сертификата отклонен из-за ошибки дешифрования |
CA |
requestInProgress |
Запрос сертификата обрабатывается |
СА, эмитент или получатель |
rejectedByIssuer |
Запрос сертификата отклонен эмитентом карты |
Эмитент |
requestPended |
Запрос сертификата ждет обработки |
СА, эмитент или получатель |
rejectedByAquirer |
Запрос сертификата отклонен банком продавца (получателем) |
Получатель |
regFormAnswerMalformed |
Запрос сертификата отклонен из-за неверной позиции в регистрационной форме. |
CA |
rejectedByCA |
Запрос сертификата отклонен центром сертификации |
CA |
unableToEncryptCertRes |
Центр сертификации не получил ключа и по этой причине не может зашифровать отклик для владельца карты |
CA |
Конечный пользователь ЕЕ проверяет новый сертификат следующим образом:
Шаг |
Действие |
1 |
Выделить CertRes из входного сообщения. Если CertRes содержит подписанные данные, дешифровать их и проверить подпись CertRes (см. описание методики EncK). Процедура осуществляется для полученных сертификатов CRL и BrandCRLIdentifier. |
2 |
Проверить, что полученные оттиски соответствуют посланным в сообщении CardCInitReq. Если проверка не прошла, возвращается сообщение Error с ErrorCode равным thumbsMismatch. |
3 |
Проверить, что LID-EE и Chall-EE соответствуют значениям, посланным в CertReq. Если проверка не прошла, возвращается сообщение Error с ErrorCode равным challengeMismatch. |
4 |
Если CertStatusCode указывает “Certificate request complete” (с запросом сертификата все в порядке), то: Извлекаются новые сертификаты из сертификатной секции SignedData и проверяются подписи. Проверяется, что полученные CertThumbs соответствуют посланным в CertReq. Если проверка не прошла, возвращается сообщение Error с ErrorCode равным thumbsMismatch. В случае владельца карты извлекается CaMsg, отображается логотип и CardholderMsg из CaMsg и запоминается CardCurrency. Проверяется, что общедоступные ключи в сертификате соответствуют секретным ключам. Если проверка не прошла, возвращается сообщение Error с ErrorCode равным invalidCertificate. В случае владельца карты выполняются следующие дополнительные действия: Для того чтобы получить PANSecret, вычисляется (Nonce-CCAA CardSecret) Вычисляется уникальный идентификатор владельца карты, HMAC-SHA-1{{PAN, cardExpiry}, PANSecret}, т.е. Salted Hash, и проводится верификация того, что полученный результат соответствует значению сертификата. |
5 |
Если CertStatusCode равен “MalFormed Registration Form Items”, это означает, что некоторые позиции регистрационной формы заполнены неверно. Для каждой ошибочной позиции приложение ЕЕ занесет в CertRes номер этой позиции и соответствующее сообщение об ошибке. ЕЕ разрешается повторить ввод для полей с ошибкой и повторно послать CertReq с новым запросом сертификата. |
6 |
Если CertStatusCode установлен равным requestinProgress или requestPended, сертификат может быть доставлен позднее с помощью процедуры CertInqReq |
7 |
Если CertStatusCode указывает какой-либо иной статус, отображается EEMessage. |
Таблица 4.6.2.43. Структура AcqCardMsg
AcqCardMsg |
EncK(AcqBackKeyData, P, AcqCardCodeMsg) AcqBackKeyData предоставляется владельцем карты в PI. Зашифрованное сообщение адресуется владельцу карты. |
AcqBackKeyData |
Копируется из PIHead.AcqBackKeyData (см. табл. 4.6.2.40) |
AcqCardCodeMsg |
{AcqCardCode, AcqCardMsgData} |
AcqCardCode |
Числовой код |
AcqCardMsgData |
{[AcqCardText], [AcqCardURL], [AcqCardPhone]} |
AcqCardText |
Текстовое сообщение, отображаемое владельцу карты |
AcqCardURL |
URL HTML-сообщения, отображаемого владельцу карты |
AcqCardPhone |
Телефонный номер, предоставляемый владельцу карты |
Для AcqCardCode определены следующие значения:
messageOfDay |
Банк продавца хочет, чтобы это сообщение было передано всем |
accountInfo |
Информация о счете должна быть передана назад пользователю |
сallCustomerService |
Предлагает приложению отобразить сообщение, рекомендующее пользователю обратиться в службу обслуживания клиентов |
CapToken предоставляет данные, необходимые расчетному центру для платежной транзакции на фазе авторизации. Структура данных CapToken представлена в таблице 4.6.2.44.
Таблица 4.6.2.64. Структура AuthReq
AuthReq |
EncB(M, P, AuthReqData, PI) |
AuthReqData |
{AuthReqItem, [Mthumbs], CaptureNow, [SaleDetail]} |
PI |
См. табл. 4.6.2.39. |
AuthReqItem |
{AuthTags, [CheckDigests], AuthReqPayload} |
MThumbs |
Оттиски сертификатов, CRL и BrandCRLIdentifiers, хранимые в данный момент в кэше продавца. |
CaptureNow |
Булева переменная, указывающая, что резервирование должно проводиться, если проведена авторизация. |
SaleDetail |
См. табл. 4.6.2.47 |
AuthTags |
{AuthRRTags, TransIDs, [AuthRetNum]} |
CheckDigests |
{HOIData, HOD2} используется расчетным центром для аутентификации PI. Опускается, если PI = AuthToken |
AuthReqPayload |
См. табл. 4.6.2.65 |
AuthRRTags |
RRTags Необходим RRPID, так как для одного PReq может потребоваться более одного цикла авторизации. |
TransIDs |
Копируется из соответствующего поля OIData (см. табл. 4.6.2.59) |
AuthRetNum |
Идентификация запроса авторизации, используемого в пределах финансовой сети. |
HOIData |
DD(OIData) (См. табл. 4.6.2.59) Независимый хэш, вычисляемый продавцом. Расчетный центр сравнивает это значение с копией, сформированной владельцем карты в PI. |
HOD2 |
DD(HODInput) (См. табл. 4.6.2.59) Вычисляется независимо продавцом. Расчетный центр сравнивает это значение с копией, сформированной владельцем карты в PI. |
Структура данных AuthReqPayload представлена в таблице 4.6.2.65.
Таблица 4.6.2.65. Структура AuthReqPayload
AuthReqPayload |
{SubsequentAuthInd, AuthReqAmt, [AVSData], [SpecialProcessing], [CardSuspect], RequestCardTypeInd, [InstallRecurData], [MarketSpecAuthData], MerchData, [ARqExtensions]} |
SubsequentAuthInd |
Булева переменная, указывающая на запросы со стороны продавца дополнительной авторизации из-за раздельной поставки |
AuthReqAmt |
Может отличаться от PurchAmt; политика банка продавца может наложить ограничение на допустимое отличие |
AVSData |
{[StreetAddress], Location} Адрес счета владельца карты: содержимое получается от владельца карты посредством механизмов, выходящих за пределы SET. |
SpecialProcessing |
Числовое поле, указывающее тип запрошенной обработки |
CardSuspect |
Числовое поле, указывающее, что продавец подозревает владельца карты, и на причину подозрения |
RequestCardTypeInd |
Указывает, что тип карты должен быть прислан в поле CardType отклика. Если информация недоступна, присылается значение unavailable(0). |
InstallRecurData |
См. табл. 4.6.2.41. |
MarketSpecAuthData |
< MarketAutoAuth, MarketHotelAuth, MarketTransportAuth > Специфические авторизационные данные рынка |
MerchData |
{[MerchCatCode], [MerchGroup]} |
ARqExtensions |
Данные в расширении авторизационного запроса должны иметь финансовый характер и относиться к процессу авторизации (или последующей оплаты заказа) расчетного центра, финансовой сети или эмитента карты. |
StreetAddress |
Адрес улицы владельца карты |
MarketAutoAuth |
{Duration} |
MarketHotelAuth |
{Duration, [Prestige]} |
MarketTransportAuth |
{} В настоящее время нет авторизационных данных для этого сегмента рынка |
MerchCatCode |
4-байтовый код (определен в ANSI X9.10), описывающий тип бизнеса, продукта или услуги продавца. |
MerchGroup |
Числовой код, идентифицирующий общую категорию продавца |
Duration |
Ожидаемая длительность транзакции (в днях). Эта информация помогает понять, какое время пройдет со времени авторизации до оплаты заказа (capture). |
Prestige |
Числовой тип приоритета, определяется платежной системы карты. |
Шаг | Действие |
1 | Извлечь запрос из транспортного сообщения |
2 | Дешифровать PI |
3 | Сравнить TransIDs из AuthTags и PIHead или AuthToken: Проверить что коды XID идентичны Проверить что коды LID-C идентичны Если LID-M присутствуют в AuthTags и PIHead, сравнить их значения Если хотя бы одна из проверок не прошла, сообщение отбрасывается и возвращается AuthCode = piAuthMismatch |
4 | Если PI является AuthToken: Обработать AuthToken В противном случае, если PI подписаны: Проверить, что платежная система в подписи владельца карты согласуется с платежной системой сертификата шифрования расчетного центра. Если согласия нет, то авторизация отвергается путем отправки AuthCode = CardMerchBrandMismatch. Проверить PANData Запомнить данные из PANData В противном случае, если PI не подписаны: Проверить, что расчетный центр не требует подписи (путем проверки сертификата платежного центра). Если подпись требуется, отвергнуть авторизацию, послав AuthCode = signatureRequired Верифицировать хэш в EXH Запомнить данные из PANToken |
5 | Проверить состояние авторизации PI. Если PI была обработана и не отвергнута или отозвана, отвергнуть авторизацию, послав AuthCode = piPreviouslyUsed |
6 | Обработать PIHead: Проверить, что PiHeadMerchantID соответствует содержимому поля merID в расширении merchantData сертификата подписи, используемом при верификации подписи продавца для сообщения AuthReq. Если соответствия нет, авторизация отвергается и посылается отклик с AuthCode = piAuthMismatch. Это предотвращает атаки подстановки, когда PI разных продавцов меняются местами. Передать TransStain эмитенту через финансовую сеть для верификации или запоминания с последующей верификацией. Проверить хэши OIData, полученные от владельца карты и продавца. Если они не совпадают, прислать AuthCode = piAuthMismatch. Проверить, что HOD от HIHead соответствует HOD2 от AuthReqPayload, при несовпадении прислать сообщение Error c ErrorCode = HODMismatch Обработать PIExtensions. Если обнаружены неподдерживаемые расширения, сообщение отвергается путем посылки сообщения Error c кодом unrecognizedExtension Запомнить данные от PIHead |
7 | Если в AuthReq имеется InstallRecurData, проверить, что InstallRecurData в AuthReqPayload и в PIHead совпадают. Если это не так, отклонить авторизацию с AuthCode = InstallRecurMismatch. |
8 | Запомнить AcqBackInfo в безопасной локальной памяти, если таковая имеется. |
9 | Если captureNow=TRUE и платежная система не поддерживает этот режим, послать AuthCode = captureNotSupported |
10 | Выполнить авторизацию через финансовую сеть платежной карты |
11 | Если captureNow=TRUE, выполнить платеж через существующую финансовую сеть платежной карты |
12 | Продолжить формирование сообщения AuthRes |
Шаг | Действие |
1 | Получить необходимые данные от авторизационного процесса |
2 | Заполнить поле AuthTags из AuthReq. Если это необходимо, занести в поле AuthRetNum, значение, полученное из авторизационного процесса. |
3 | Заполнить текущее значение BrandCRLIdentifier, хранимое расчетным центром, если для текущего BrandCRLIdentifier не получен оттиск или он устарел. |
4 | Если Mthumbs из AuthReq указывает, что продавцу нужен новый Cert-PE шифрования информации для расчетного центра: Вставить Cert-PE в цифровой конверт PKCS#4 Вставить GKThumb в AuthResData, так как сам Cert-PE не защищен подписью |
5 | Заполнить поле PaySysID в TransIDs, если они получены из авторизационного процесса |
6 | Заполнить поле PANToken, если это необходимо для сертификата продавца, |
7 | Заполнить AuthResBaggage (опционно): Опционно заполнить CapToken Опционно заполнить AcqCardMsg, если соответствующие правила платежной системы требуют посылки запроса и получения ключа от владельца карты. Занести в AuthToken значения, полученные в InstallRecurData продавца, если осуществлена дополнительная авторизация (в предыдущем AuthReq SubsequentAuthInd=TRUE). Если ни одна из этих величин не присутствует, AuthResBaggage характеризуется пустой последовательностью. |
8 | Опционно заполнить BatchStatus, как этого требует политика платежной системы карты. |
9 | Если PANToken имеется, реализовать EncBX-инкапсуляцию |
10 | Вставить сообщение в цифровой конверт и отправить владельцу карты |
Шаг | Действие |
1 | Сгенерировать CapResPayload |
Заполнить AuthCode и AuthAmt c привлечением результатов авторизационного процесса Если авторизация отвергнута, вернуть AuthAmt, специфицированный в предыдущем AuthReq. Если флаг CaptureNow был указан в AuthReq, но не был реализован, вернуть в случае успешной авторизации AuthCode = captureNotSupported |
|
3 | Заполнить поле CurrConv в соответствии с запрошенным владельцем карты типом валюты и с учетом текущего курса, если специфицирована валюта, отличная от используемой владельцем карты. |
4 | Заполнить ResponseData: Заполнить поле AuthValCodes следующим образом: записать ApprovalCode, RespReason, AuthCharInd, ValidationCode и LogRefID, если получены из авторизационного процесса. Если RequestCardTypeInd в AuthReq был установлен равным TRUE, занести в поле CardType значение, полученное из авторизационного процесса. Занести в AuthCharInd значение, присланное авторизационным процессом |
Таблица 4.6.2.67. Структура AuthResPayload
AuthResPayload |
{AuthHeader, [CapResPayload], [ARsExtensions]} |
AuthHeader |
{AuthAmt, AuthCode, ResponseData, [BatchStatus], [CurrConv]} |
CapResPayload |
Присылается, если CaptureNow
имеет значение TRUE в AuthReq. См. табл. 4.6.2.71. |
ARsExtensions |
Данные в расширении к авторизационному отклику должны быть финансовыми и существенными для обработки авторизационного отклика. |
AuthAmt |
Копируется из AuthReqPayload.AuthReqAmt |
AuthCode |
Числовой код, индицирующий результат процесса авторизации |
ResponseData |
{[AuthValCodes], [RespReason], [CardType], [AVSResult], [LogRefID]} |
BatchStatus |
См. табл. 4.6.2.53. |
CurrConv |
{CurrConvRate, CardCurr} |
AuthValCodes |
{[ApprovalCode], [AuthCharInd], [ValidationCode], [MarketSpecDataID]} |
RespReason |
Числовой код, который указывает на объект сервиса авторизации и причину отказа (если таковая имеется) |
CardType |
Числовой код, который указывает на тип карты, использованной для транзакции. |
AVSResult |
Числовой код отклика адресной верификационной службы |
LogRefID |
Алфавитно-цифровые данные, ассоциируемые с авторизационной транзакцией (используется для распознавания при отзыве предшествующего запроса) |
CurrConvRate |
Курс обмена валюты. Значение, на которое нужно умножить AuthReqAmt, чтобы получить сумму в валюте владельца карты. |
AuthReqAmt |
Код валюты владельца карты в стандарте ISO 4217 |
ApprovalCode |
Код одобрения, присваиваемый транзакции эмитентом |
AuthCharInd |
Числовое значение, которое указывает условия, при которых выполнена авторизация. |
ValidationCode |
4-байтовый алфавитно-цифровой код, вычисленный, чтобы гарантировать, что необходимые поля авторизационных сообщений присутствуют в соответствующих клиринговых сообщениях. |
MarketSpecDataID |
Числовой код, который указывает тип данных, специфических для рынка, представляемых при авторизации (как это определено финансовой сетью) |
Список возможных значений кода AuthCode приведен ниже
approved | Запрос авторизации удовлетворен |
unspecifiedFailure | Запрос авторизации не может быть обработан по причине, которая отсутствует в приведенном здесь списке. |
declined | Запрос авторизации отклонен |
noReply | Эмитент не откликнулся на запрос авторизации. Это значение часто указывает на временное отсутствие доступа к системе обработки данных эмитента. |
callIssuer | Эмитент запрашивает телефонный вызов от продавца |
amountError | Такое число транзакций не может быть обработано системой (банком продавца, финансовой сетью, эмитентом и т.д.) |
expiredCard | Срок действия карты истек |
invalidTransaction | Запрос не может быть обработан последующей системой (банком продавца, финансовой сетью, эмитентом и т.д.), так как тип транзакции является недопустимым. |
systemError | Запрос не может быть обработан последующей системой (банком продавца, финансовой сетью, эмитентом и т.д.), так как запрос содержит в себе некорректные данные. |
piPreviouslyUsed | Платежная инструкция (PI) в запросе авторизации использовалась для первичной авторизации (отклик, сформированный расчетным центром). |
recurringTooSoon | Минимальное время между авторизациями для рекуррентной транзакции еще не истекло (отклик, сформированный расчетным центром). |
recurringExpired | Дата истечения действия для рекуррентной транзакции наступила (отклик, сформированный расчетным центром) |
piAuthMismatch | Дата в PI от владельца карты не согласуется с данными в OD от продавца. |
installRecurMismatch | InstallRecurData в PI от владельца карты не согласуется с InstallRecurData в OD от продавца. |
captureNotSupported | Расчетный центр не поддерживает платеж (capture). |
signatureRequired | Опция неподписанной PI не поддерживается расчетным центром для данной платежной системы. |
cardMerchBrandMismatch | Платежная система в сертификате подписи владельца карты не согласуется с платежной системой сертификата шифрования расчетного центра. |
Шаг | Действие |
1 | Получить отклик из входного сообщения |
2 | Извлечь запись транзакции и сравнить с AuthTags: Проверить, что XID соответствует транзакции. Если соответствия нет, сообщение отвергается с Error = unknownXID Проверить, что LID-M и, если имеется в записи транзакции, LID-C согласуются с содержимым записи транзакции. Если соответствия нет, сообщение отвергается, а в журнал операций расчетного центра записывается Error = unknownLID. |
3 | Если в сообщение включен BrandCRLIdentifier, запомнить CRL. |
4 | Обработать AuthResPayload |
5 | Проверить, что GKThumb соответствует существующему сертификату шифрования расчетного центра, если GKThumb имеется. Если соответствия нет, актуализовать кэш сертификата с использованием текущего сертификата |
6 | Если BatchStatus присутствует, обработать и запомнить данные. |
7 | Обработать AuthResBaggage: Запомнить CapToken, если это поле присутствует Если имеется AcqCardMsg, запомнить его для отправки владельцу карты Запомнить AuthToken, если имеется, для последующей авторизации. Если в AuthReq SubsequentAuthInd = TRUE, будет возвращено AuthToken |
8 | Если присутствует PANToken, записать его в безопасную локальную память |
9 | Продолжить обработку оплаты заказа и/или отклика на покупку, в зависимости от результатов авторизации и временных рамок продавца для возвращения отклика на покупку. |
Шаг | Действие |
1 | Обработать ARsExtensions, если они имеются. Если неподдерживаемое расширение помечено как критическое, расчетный центр производит запись в журнал Error = unrecognizedExtension, а сообщение игнорируется. |
2 | Обрабатать CapResPayload: Обработать CRsPayExtensions. Если имеется нераспознанное расширение, помеченное как критическое, отвергнуть AuthRes, а расчетный центр делает запись в журнал Error = unrecognizedExtension Обработать CapCode с целью определения результата Обработать SaleDetail в соответствии с политикой платежной системы карты Для успешной оплаты заказа, записать CapCode и CapAmt. Если делался запрос оплаты (capture), будет возвращен CapResPayload |
3 | Если имеется CurrConv, запомнить его для переадресации владельцу карты |
4 | Обработать AuthCode, AuthAmt и ResponseData: Для определения результата обрабатывается AuthCode. Запомнить AuthCode и AuthAmt для получения успешного результата. Запомнить ValidationCode для успешного исхода, если это поле имеется. Запомнить AuthValCode, если имеется. Запомнить AVSResult, если имеется. Запомнить LogRefID, если имеется. |
Таблица 4.6.2.42. Структура AuthToken
AuthTokenData |
{TransIDs, PurchAmt, MerchantID, [AcqBackKeyData], [InstallRecurData], [RecurringCount], PrevAuthDataTime, TotalAuthAmount, AuthTokenOpaque} |
PANToken |
Поля копируются из поля PI-Head, сформированного владельцем карты (см. табл. 4.6.2.40) |
TransIDs |
|
PurchAmt |
|
MerchantID |
|
AcqBackKeyData |
|
InstallRecurData |
|
RecurringCount |
Число реализованных рекуррентных авторизаций |
PrevAuthDateTime |
Дата и время последней авторизации продавца в последовательности рекуррентных авторизаций |
TotalAuthAmount |
Полное число авторизованных в результате всех авторизаций для данного XID |
AuthTokenOpaque |
Невидимые данные, генерируемые расчетным центром |
AuthToken формируется следующим образом:
Шаг | Действие | |
1 | Генерируется AuthTokenTBE как: Если это первая авторизация (выполнена согласно PI) а. Заполняется из PI поля PANToken, TransIDs, PurchAmt, MerchantID и, если имеется в PI, AcqBackInfo и InstallRecurData б. RecurringCount делается равным 1 в. В PrevAuthDateTime записывается текущая дата г. В TotalAuthAmount заносится AuthAmt из авторизационного отклика, который содержит данный AuthToken Если это очередная аутентификация (сгенерирована из предыдущего AuthToken) а. Заполняется из предыдущего AuthToken поля PANToken, TransIDs, PurchAmt, MerchantID и, если имеется, AcqBackInfo и InstallRecurData б. Инкрементируется на 1 RecurringCount в. В PrevAuthDateTime записывается текущая дата г. TotalAuthAmount увеличивается на AuthAmt, взятое из авторизационного отклика, который содержит данный AuthToken Если это полная (reversal) аутентификация (сгенерирована из предыдущего AuthToken) а. Из предыдущего AuthToken заполняются поля PANToken, TransIDs, PurchAmt, MerchantID, PrevAuthDateTime и, если имеется, AcqBackInfo и InstallRecurData б. Если это повторное выполнение всех авторизаций (т.е. AuthNewAmt в AuthRevReq равно нулю), уменьшить RecurringCount на 1 в. Уменьшить TotalAuthAmount на AuthNewAmt из авторизацилнного отклика, который будет содержать маркер AuthToken. | |
2 | Сформировать PANToken (см. табл. 4.6.2.46) | |
3 | С привлечением инкапсуляции EncX уложить данные в цифровой конверт, используя P1=P2=Cert-PE в качестве s и r параметров, AuthTokenTBE (из шага 1) - в качестве параметра t и PANToken - в качестве параметра p. |
Шаг | Действие |
1 | Извлечь AuthToken из EncX-конверта, используя секретный ключ расчетного центра. |
2 | Если это автризационный запрос и AuthToken уже использовался при авторизации, установить AuthCode равным piPreviouslyUsed |
3 | Если это запрос повторной авторизации (reversal request) и AuthToken не использовался при авторизации, установить AuthCode=piAuthMismatch. |
4 | Если это авторизационный запрос и InstallRecurData специфицирована рекурентной информацией: Проверить, что текущая дата относится ко времени раньше даты RecurringExpiry. Если проверка не прошла, установить AuthCode равным recurringExpired. Проверить, что текущая дата позднее, чем PrevAuthDate плюс число дней, специфицированное в RecurringFrequency. Если проверка не прошла, установить AuthCode равным recurringTooSoon. |
5 | Если это автризационный запрос и InstallRecurData специфицирована информацией Installment, реализовать специфические требования платежной системы карты. |
6 | Если на предыдущих шагах AuthCode не был установлен, переадресовать данные от AuthToken авторизационному процессу. |
Таблица 4.6.2.81. Структура BatchAdminReq
BatchAdminReq | Enc(M, P, BatchAdminReqData) |
BatchAdminReqData | {BatchAdminRRTags, [BatchID], [BrandAndBINSeq], [BatchOperation], ReturnBatchSummaryInd, [ReturnTransactionDetail], [BatchStatus], [TransDetails], [BARqExtensions]} |
BatchAdminRRTags | RRTags. Новый идентификатор RRPID и Date (дата) |
BatchID | Идентификатор платежной линии для счета банка продавца |
BrandAndBINSeq | {BrandAndBIN +} |
BatchOperation | Числовая величина, указывающая на операцию, которая должна быть выполнена в рамках платежной линии |
ReturnBatchSummaryInd | Обозначает, что в BatchAdminRes должны быть возвращены итоговые данные. |
ReturnTransactionDetail | {StartingPoint, MaximumItems, ErrorsOnlyInd, [BrandID]} Если специфицирован BrandID, присылаются данные только для позиций, определяемых платежной системой карты. |
BatchStatus | См. табл. 4.6.2.53. |
TransDetails | {NextStartingPoint, TransactionDetailSeq} |
BARqExtensions | Данные в расширении административного сообщения платежной линии должны иметь финансовый характер и быть важными для обработки административных запросов. |
BrandAndBIN | {BrandID, [BIN]} |
StartingPoint | Нуль указывает на то, что следует прислать данные для первой группы позиций, в противном случае NextStartingPoint предшествующего BatchAdminRes |
MaximumItems | Максимальное число позиций, которые следует прислать в этой группе. |
ErrorsOnlyInd | Булево число, индицирующее, следует ли присылать только позиции с состоянием ошибки. |
BrandID | Тип платежной системы (без указания типа продукта). |
NextStartingPoint | Нуль индицирует, что это последняя группа позиций, в противном случае, используется значение, идентифицирующее начальную точку следующей группы позиций. |
TransactionDetailSeq | {TransactionDetail +} |
BIN | Идентификационный номер банка для обработки транзакций продавца. |
TransactionDetail | См. табл. 4.6.2.54 |
Расчетный центр обрабатывает запрос BatchAdminReq следующим образом.
Шаг | Действие | |
1 | Выделить запрос из входного сообщения | |
2 | Проверить подпись. Если проверка не прошла, присылается отклик Error c ErrorCode = signatureFailure. | |
3 | Проверить, что RRPID в BatchAdminReq соответствует RRPID в цифровом конверте сообщения. Если проверка не прошла, присылается отклик Error c ErrorCode = unknownRRPID. | |
4 | Если BatchOperation = open:
Проверить, что BatchID еще не открыт. Если это не так, установить BAStatus = batchAlreadyOpen. Проверить, что BatchID доступен. Если это не так, установить BAStatus = batchIDUnavailable. Если имеется BrandIDSeq: Проверить, что каждый BrandID поддерживается. Если это не так, установить BAStatus = brandNOTSupported. Проверить, что каждый BIN поддерживается. Если это не так, установить BAStatus = unknownBIN. Запомнить платежные системы и BIN, которые можно использовать для данной платежной линии. Открыть платежную линию для использования продавцом и установить BAStatus = success. Продолжить процесс посылкой BatchAdminRes Любые другие поля, присутствующие в сообщении BatchAdminReq будут игнорироваться, когда BatchOperation = open. |
|
5 | Если BatchOperation = purge: Проверить, что BatchID уже открыт. Если это не так, установить BAStatus = unknownbatchID. Если BrandIDSeq присутствует: Проверить, что каждый BatchID относится к данной платежной линии. Если это не так, установить BAStatus = brandBatchMismatch. Проверить, что каждый BIN относится к данной платежной линии. Если это не так, установить BAStatus = unknownBIN. Удалить все транзакции платежной линии, ассоциированные со специфицированной платежной системой и BIN. В противном случае, удалить все транзакции из группы платежей Установить BAStatus = success Продолжить работу посылкой сообщения BatchAdminRes Любые другие поля, присутствующие в сообщении BatchAdminReq, будут игнорироваться, когда BatchOperation = purge. |
|
6 | Если BatchOperation = close:
Проверить, что BatchID уже открыт. Если это не так, установить BAStatus = unknownbatchID. Установить BAStatus = success Продолжить работу посылкой сообщения BatchAdminRes Любые другие поля, присутствующие в сообщении BatchAdminReq будут игнорироваться, когда BatchOperation = close. |
|
7 | Если BatchOperation опущено, а возвращенное значение ReturnBatchSummaryInd = TRUE:
Проверить, что BatchID доступен. Если это не так, установить BAStatus = batchIDUnavailable. Если BrandAndBIN включен: Проверить, что каждый BatchID относится к данной платежной линии. Если это не так, установить BAStatus = brandBatchMismatch. Проверить, что каждый BIN относится к данной платежной линии. Если это не так, установить BAStatus = unknownBIN. Вычислить BatchTotals и заполнить структуры данных BrandBatchDetails для каждого специфицированного значения BrandAndBIN. Вычислить BatchTotals для платежных систем, включенных в BrandAndBIN, или для всех транзакций, если BrandAndBIN отсутствует. Заполнить BatchTotals в структурах данных BatchStatus вычисленными значениями. Если TransmissionStatus и SettlementInfo доступны в клиринговой системе, используемой расчетным центром, занести эту информацию в BatchAdminRes. Если StartingPoint опущено, установить BAStatus = success и продолжить работу посылкой отклика BatchAdminRes, в противном случае перейти к следующему шагу. NextStartingPoint и TransactionDetailSeq игнорируются, если ReturnBatchSummaryInd = TRUE. |
|
8 | Если включено поле StartingPoint:
Если MaximumItem установлен равным 0, аннулировать любую предшествующую информацию для данной платежной линии и установить BAStatus = success и продолжить работу посылкой отклика BatchAdminRes. Проверить, что BatchID доступен. Если это не так, установить BAStatus = batchIDUnavailable. Если StartingPoint не равен нулю, проверить, что StartingPoint равен NextStartingPoint, присланном в предыдущем отклике BatchAdminRes. Если StartingPoint равен нулю, установить указатель на начало списка платежей, в противном случае установить указатель согласно содержимому StartingPoint. Если имеется BrandAndBIN: Проверить, что каждый BatchID имеет отношение к данной платежной линии. Если это не так, установить BAStatus = brandBatchMismatch. Проверить, что каждый BIN имеет отношение к данной платежной линии. Если это не так, установить BAStatus = unknownBIN. Если специфицировано поле MaximumItems, заполнить TransactionDetail вплоть до MaximumItems из текущей позиции и установить NextStartingPoint в позицию, из которой можно получить данные для последующих транзакций. Если система достигла конца списка платежей, установить NextStartingPoint = 0. Выбор позиции ограничивается BrandandBIN и ErrorOnlyInd. f) Установить BAStatus = success и продолжить работу посылкой отклика BatchAdminRes |
|
9 | Если код BatchOperation опущен, а BatchStatus имеется:
Проверить, что BatchID доступен. Если это не так, установить BAStatus = batchIDUnavailable. Если имеется поле BrandBatchDetails: Проверить, что каждый BatchID имеет отношение к данной платежной линии. Если это не так, установить BAStatus = brandBatchMismatch. Проверить, что каждый BIN имеет отношение к данной платежной линии. Если это не так, установить BAStatus = unknownBIN. Вычислить BatchTotals и заполнить информационные структуры BrandBatchDetails для каждого специфицированного BrandAndBIN. Вычислить BatchTotals для платежных систем, включенных в BrandAndBIN или для всех транзакций, если BrandAndBIN отсутствует. Для любого значения BatchTotals, которое не согласуется с приведенным в сообщении BatchAdminReq, занести вычисленные значения в BatchTotals информационной структуры BatchStatus. Если какое-либо итоговое значение не согласовано, установить BAStatus = totalsOutOfBalance и перейти к следующему пункту. Если поле TransactionDetails опущено, установить BAStatus = success и продолжить работу посылкой отклика BatchAdminRes | |
10 | Если код BatchOperation опущен и включено поле TransactionDetails:
Проверить, что BatchID доступен. Если это не так, установить BAStatus = batchIDUnavailable. Если указатель StartingPoint не равен нулю и не согласуется с NextStartingPoint из предыдущего BatchAdminReq, установить BAStatus = unknownStartingPoint. Если NextStartingPoint не равен нулю, запомнить TransactionDetails, скопировать NextStartingPoint в сообщение BatchAdminRes и установить BAStatus = success. Продолжить работу посылкой отклика BatchAdminRes. Проверяется соответствие полученных транзакций с теми, что хранятся в расчетном центре. Если отличие обнаружено, установить BAStatus = totalsOutOfBalance. Продолжить работу посылкой отклика BatchAdminRes. Опционно установить BAStatus = stopItemDetail, чтобы проинформировать продавца о том, что расчетный центр не желает обрабатывать позиции в данной последовательности платежей (batch). Продолжить работу посылкой отклика BatchAdminRes. Установить BAStatus = success и продолжить работу посылкой отклика BatchAdminRes. Последовательность BrandAndBIN игнорируется. |
Шаг | Действие |
1 | Если BAStatus не установлен равным success (успех) или MaximumItems в BatchAdminReq установлен равным 0, аннулировать любую информацию в рамках платежной линии для заданной последовательности запросов BatchAdmin, посланных ранее продавцом. |
2 | Используя сертификат расчетного центра, запустить операцию подписи для BatchAdminResData. |
3 | Зашифровать BatchAdminResTBE, используя сертификат шифрования, поставляемый продавцом, и установить код типа содержимого равным id-set-content-BatchAdminResTBE. |
4 | Вложить сообщение в цифровой конверт и послать владельцу карты. |
Таблица 4.6.2.82. Структура BatchAdminRes
BatchAdminRes |
Enc(P, M, BatchAdminResData) |
BatchAdminResData |
{BatchAdminTags, BatchID, [BAStatus], [BatchStatus], [TransmissionStatus], [SettlementInfo], [TransDetails], [BARsExtensions]} |
BatchAdminTags |
RRTags; копируется из предшествующего BatchAdminReq |
BatchID |
Идентификатор платежной линии между продавцом и его банком. |
BAStatus |
Числовой код, указывающий на состояние открытой платежной линии. |
BatchStatus |
См. табл. 4.6.2.53. |
TransmissionStatus |
Числовое значение, индицирующее состояние передачи данных из расчетного центра системе вышестоящего уровня |
SettlementInfo |
{SettlementAmount, SettlementType, SettlementAccount, SettlementDepositDate} |
TransDetails |
{NextStartingPoint, TransactionDetailSeq} |
BARsExtensions |
Данные расширения административного отклика должны носить финансовый характер и иметь значение для обработки административного запроса по поводу платежной линии. Информация, относящаяся к обработке запроса, должна появляться в расширении BatchAdminResData; информация, относящаяся к состоянию платежной линии, должна содержаться в расширении BatchStatus; информация, относящаяся к информационным деталям позиции в пределах платежной линии должна содержаться в расширении TransactionDetail. |
SettlementAmount |
Занесенная через сеть на счет продавца сумма |
SettlementType |
Числовой код, указывающий тип суммы |
SettlementAccount |
Счет продавца |
SettlementDepositDate |
Дата, когда сумма SettlementAmount будет занесена или снята со счета продавца |
NextStartingPoint |
Нуль индицирует, что это последняя группа позиций, в противном случае, для идентификации начальной точки следующей группы позиций используется скрытое значение |
TransactionDetailSeq |
{TransactionDetail +} |
TransactionDetail |
См. табл. 4.6.2.54.. |
В ниже приведенной таблице представлены стандартизованные значения поля ReimbursementID
unspecified | Неизвестное значение |
standard | Стандартная скорость обмена |
keyEntered | Скорость обмена для транзакций key-entered (ввод с клавиатуры) |
electronic | Скорость обмена для электронных транзакций |
additionalData | Скорость обмена для транзакций, которые включают в себя дополнительные клиринговые данные |
enhancedData | Скорость обмена для транзакций, которые включают в себя усовершенствования (такие как данные дополнительной авторизации). |
marketSpecific | Скорость обмена для транзакций в пределах специфического сегмента рынка (такого как пассажирский транспорт). |
Шаг | Действие |
1 | Извлекается отклик BatchAdminRes из входного сообщения. |
2 | Верифицируется подпись. Если проверка не прошла, присылается сообщение Error с ErrorCode = signatureFailed. |
3 | Проверяется, что RRPID в BatchAdminReq соответствует RRPID в цифровом конверте. Если проверка не прошла, присылается сообщение Error с ErrorCode = unknownRRPID. |
4 | Если BAStatus не равен success, а продавец передает или запрашивает подробности о платежной линии, аннулировать любую информацию, запомненную для данной платежной линии и перезапустить процесс, если детальные данные о платежах по-прежнему нужны. |
5 | Если продавец получает детальные данные о платежной линии, запомнить NextStartingPoint для использования в последующих откликах BatchAdminRes. Значение нуль указывает, что все подробности о платежной линии переданы. |
6 | Если продавец передает детальные данные о платежной линии, проверить, что NextStartingPoint согласуется со значением, посланным в BatchAdminReq. Если согласия нет, послать BatchAdminReq с MaximumItems = 0, чтобы расчетный центр аннулировал детали платежной линии, посланные ранее, после чего повторить посылку этих деталей расчетному центру в последующей серии запросов BatchAdmin. |
7 | Запомнить детали из запроса BatchAdmin и передать их расчетным процедурам продавца. |
Таблица 4.6.2.53. Структура BatchStatus
BatchStatus |
{OpenDateTime, [ClosedWhen], BatchDetails, [BatchExtensions]} |
OpenDateTime |
Дата и время открытия платежной линии |
ClosedWhen |
{CloseStatus, CloseDateTime} |
BatchDetails |
{CloseDateTime, [BrandBatchDetailsSeq]} |
BatchExtensions |
Данные в расширении для сообщения управления платежами должны носить финансовый характер и быть существенными для обработки административного запроса |
CloseStatus |
Цифровой код, указывающий статус закрытия платежной линии |
CloseDateTime |
Дата и время закрытия платежной линии |
BatchTotals |
{TransactionCountCredit, TransactionTotalAmtCredit, TransactionCountDebit, TransactionTotalAmtDebit, [BatchTotalExtensions]} |
BrandBatchDetailsSeq |
{BrandBatchDetails +} |
TransactionCountCredit |
Число транзакций, которые внесли вклад в кредит продавца. |
TransactionTotalAmtCredit |
Полная сумма, внесенная на счет продавца |
TransactionCountDebit |
Число транзакций, которые внесли вклад в дебет продавца |
TransactionTotalAmtDebit |
Полная сумма, снятая со счета продавца |
BatchTotalExtensions |
Данные расширения отклика управления платежами должны носить финансовый характер и быть существенными для обработки административного запроса. Информация, относящаяся к обработке запроса, должна появляться в расширении BatchAdminResData. Информация, имеющая отношение к состоянию платежной линии, должна лежать в расширении BatchStatus. Информация, относящаяся к деталям по конкретной позиции заказа, присутствует в расширении TransactionDetail. |
BrandBatchDetails |
{BrandID, BatchTotals} |
BrandID |
Тип платежной системы карты без типа продукта |
Структура TransactionDetail служит для предоставления детальной информации о платежной линии между расчетным центром и продавцом. Формат этой структуры описан в таблице 4.6.2.54.
Таблица 4.6.2.69. Структура CapPayload
CapPayload |
{CapDate, CapReqAmt, [AuthReqItem], [AuthResPayload], [SaleDetail], [CPayExtensions]} |
CapDate |
Дата платежа - это дата транзакции, которая появится в уведомлении владельца карты. |
CapReqAmt |
Сумма платежа, затребованная продавцом, может отличаться от AuthAmt. Это сумма транзакции (до конвертации валюты), которая появится в уведомлении владельца карты. |
AuthReqItem |
См. табл. 4.6.2.64. Поле необходимо, если соответствующий маркер CapToken отсутствует или система расчетного центра/банка продавца не содержит подходящих данных для авторизационного запроса. |
AuthResPayload |
См. табл. 4.6.2.67. Поле необходимо, если соответствующий маркер CapToken отсутствует или система расчетного центра/банка продавца не содержит подходящих данных для авторизационного отклика. |
SaleDetail |
См. табл. 4.6.2.47. |
CPayExtensions |
Данные в расширении запроса платежа (capture) должны иметь финансовый характер и быть существенными для сообщения capture, посланного расчетному центру, финансовой сети или эмитенту. Данные этого расширения приложимы к индивидуальным позициям платежного запроса. Данные, относящиеся ко всему запросу, помещаются в расширение CapReqData. |
Расчетный центр, получив запрос CapReq, обрабатывает его следующим образом.
Шаг | Действие | |
1 | Извлечь запрос из входного сообщения | |
2 | Обработать CRqExtensions. Если какое-либо неподдерживаемое расширение имеет критический флаг, отбросить сообщение, послав сообщение Error = unrecognizedExtension | |
3 | Для каждого CapItem обработать платеж и сформировать CapResItem с суммой из обрабатываемого платежа и кодом CapCode, соответствующим успеху или неудаче:
Обработать CapPayload Если CapToken присутствует: Проверить CapToken. Если CapToken некорректен, отклонить платеж, возвратив для данной позиции CapCode = invalidCapToken Проверить, что CapToken не был еще обработан. Если проверка не прошла, отклонить платеж, прислав CapCode = invalidCapToken Обработать TokenOpaque В противном случае, если допустимы платежи без CapToken: Если AuthReqItem и AuthResPayload отсутствуют, отклонить платеж, послав CapCode = authDataMissing Сверить AuthReqItem и AuthResPayload с записями транзакции. Если соответствия нет, платеж отвергается путем посылки CapCode = invalidAuthData. В противном случае, если платежи без CapToken не поддерживаются, платеж отклоняется посылкой CapCode = missingCapToken Проверить TransIDs Извлечь запись транзакции Проверить, что XID согласуется с записью транзакции. Если согласия нет, то платеж отклоняется посылкой CapCode = unknownXID Сверить LID-C и, если имеется, LID-M со значениями из записи транзакции. Если совпадения нет, то транзакция терпит неудачу, посылается CapCode = unknownLID f) Обработать платеж для заданной позиции через существующую финансовую сеть карты и записать результат. |
Шаг | Действие |
1 | Обработать CPayExtensions. Если неизвестное расширение помечено как критическое, сообщение отвергается и возвращается сообщение Error unrecognizedExtension |
2 | Запомнить SaleDetail |
3 | Проверить, что BatchID является открытой платежной линией для BrandAndBIN. Если платежная линия неизвестна, отклонить платеж с посылкой CapCode = batchUnknown. Если линия не открыта, отклонить платеж с CapCode = batchClosed |
4 | Проверить, что идентификатор BatchSequenceNum является уникальным в рамках платежной линии. Если идентификатор не уникален, отклонить платеж путем возвращения CapCode = batchUnknown. |
Шаг | Действие |
1 | Получить данные о платеже от платежного процесса |
2 | Скопировать CapRRTags из CapReq |
3 | Заполнить текущее значение BrandCRLIdentifier, имеющееся в расчетном центре, если оттиск для текущего BrandCRLIdentifier не получен или устарел. |
4 | Если MThumbs указывают, что продавцу для шифрования информации нужен новый Cert-PE: Вложить Cert-PE в цифровой конверт PKCS#7 Вложить GKThumb в AuthResData, так как сам Cert-PE не защищен подписью |
5 | Опционно занести в поле BatchSequenceNum состояние текущих платежных линий |
6 | Скопировать BatchID и BatchSequenceNum из SaleDetail в CapResPayload |
7 | Заполнить CapResSeq. Для каждого CapItem в соответствующем CapReq заполнить CapResItem следующим образом: Скопировать TransIDs из соответствующего CapReqItem Скопировать AuthRRPID из соответствующего CapReqItem, если он имеется Заполнить CapResPayload |
8 | Опционно заполнить CRsExtensions |
9 | Вставить сообщение в цифровой конверт и послать продавцу |
Шаг | Действие |
1 | Заполнить CapCode и CapAmt результатами обработки соответствующего CapReqItem |
2 | Скопировать BatchID и BatchSequenceNum из соответствующего CapReqItem |
3 | Опционно заполнить CRsPayExtensions |
Таблица 4.6.2.70. Структура CapRes
CapRes |
Enc(P, M, CapResData) |
CapResData |
{CapRRTags, [BrandCRLIdentifier], [PEThumb], [BatchStatusSeq], CapResItemSeq, [CRsExtensions]} |
CapRRTags |
RRTag>s; копируется из CapReq |
BrandCRLIdentifier |
Список текущих CRL для всех СА в области ответственности платежной системы СА. |
PEThumb |
Оттиск сертификата расчетного центра, предоставляемый, если CapReqData.Mthumbs указывает на то, что продавец в нем нуждается. |
BatchStatusSeq |
{BatchStatus +} |
CapResItemSeq |
{CapResItem +} Заказ соответствует CapReq |
CRsExtensions |
Данные в расширении платежного отклика должны иметь финансовый характер и быть важными для осуществления платежа или последующего возврата денег. |
BatchStatus |
См. табл. 4.6.2.53. |
CapResItem |
{TransIDs, AuthRRPID, CapResPayload} |
TransIDs |
Копируется из соответствующего CapReq |
AuthRRPID |
RRPID, который появился в соответствующем AuthReq или AuthRevReq, копируется из соответствующего CapReq |
CapResPayload |
См. табл. 4.6.2.71. |
Структура данных CapResPayload представлена в таблице 4.6.2.71.
Таблица 4.6.2.71. Структура CapResPayload
CapResPayload |
{CapCode, CapAmt, [BatchID], [BatchSequenceNum], [CRsPayExtensions]} |
CapCode |
Цифровой код, указывающий на состояние платежа |
CapAmt |
Копируется из соответствующего CapReq |
BatchID |
Идентификатор для установления платежной линии между продавцом и его банком. Копируется из соответствующего CapReq |
BatchSequenceNum |
Порядковый номер позиции в текущей последовательности платежей; копируется из соответствующего CapReq |
CRsPayExtensions |
Данные в расширении поля данных платежного отклика должны иметь финансовый характер и быть важными для осуществления платежа ли последующего возврата денег. |
Продавец обрабатывает отклик CapRes следующим образом.
Шаг | Действие | |
1 | Извлекается отклик из входного сообщения | |
2 | Обрабатывается CRsExtensions, если таковые имеются. Если не узнанное расширение помечено как критическое, в рабочий журнал заносится запись Error = unrecognizedExtension, а сообщение CapRes отбрасывается | |
3 | Извлекается запись транзакции и производится сравнение CapRRTags:
Проверяется, что XID соответствует транзакции. Если это не так, сообщение отвергается и посылается отклик Error = unknownXID Проверяется, что LID-M и, если присутствует в записи транзакции, LID-C согласуются с записью транзакции. Если согласия нет, сообщение отвергается и посылается отклик Error = unknownLID |
|
4 | Если в сообщение включен BrandCRLIdentifier, запомнить все CRL. | |
5 | Проверить, что GKThumb согласуется с сертификатом шифрования платежного центра (если GKThumb имеется). Если это не так, актуализовать кэш сертификата с использованием текущего сертификата. | |
6 | Для каждого CapResItem в CapResSeq:
Обрабатывается CRsPayExtensions. Если неузнанное расширение помечено как критическое, в рабочий журнал заносится запись Error = unrecognizedExtension, а сообщение CapRes отбрасывается. Обработать CapCode для получения результата операции Для успешного платежа запомнить CapCode и CapAmt, ассоциированные с AuthRRPID. | |
7 | Если BatchStatusSeq присутствует, обработать и запомнить каждое значение BatchStatus |
success | Платежная позиция обработана расчетным центром успешно |
unspecifiedFailure | Причина неудачи неизвестна |
duplicateRequest | Платежный запрос для данной транзакции уже был обработан (для XID и AuthRRPID) |
authExpired | Авторизационный запрос был обработан слишком давно в прошлом. Это время определяется политикой платежной системы карты. |
authDataMissing | В платежном запросе отсутствует авторизационная информация |
invalidAuthData | Авторизационная информация для данной транзакции некорректна |
capTokenMissing | Для обработки данной позиции необходимо поле CapToken, а его нет |
invalidCapToken | Поле CapToken некорректно для данной транзакции |
batchUnknown | Расчетный центр не знает о существовании платежной линии для данной позиции |
batchClosed | Платежная линия для данной позиции закрыта |
unknownXID | Не распознан идентификатор XID |
unknownLID | Не распознан идентификатор LID |
Шаг | Действие |
1 | Сформировать CapRevOrCredRRTags с новым RRPID и текущей датой. |
2 | Рекомендуется заполнить MThumbs путем вычисления оттисков сертификатов и CRL, имеющихся у продавца. Продавец должен заполнить оттиски в сообщении, которые могут быть затем нужны для верификации подписей и сертификатов, присылаемых расчетным центром. |
3 | Заполнить одну или более позиций в CredRevOrCredReqItems: Скопировать TransIDs из соответствующего CapRes. Скопировать AuthRRPID из самого последнего запроса (settlement), если имеется. Скопировать CapPayload из самого последнего запроса (settlement), (т.е. CapReq, CapRevReq, CredReq или CredRevReq). Заполнить NewBatchID, если кредитная линия транзакции закрыта. Заполнить CapRevOrCredReqData с текущей датой и временем Опционно заполнить CapRevOrReqAmt с новой суммой, которая может отличаться от значений, содержащихся в AuthAmt из CapToken и CapReqAmt из CapPayload. Опционно установить новое значение NewAccountInd, если сделка состоится для нового счета владельца карты, как это специфицировано в PANToken. Опционно заполнить CRvRqItemExtensions |
4 | Опционно заполнить CRvRqExtensions |
Таблица 4.6.2.72. Структура CapRevOrCredReqData
CapRevOrCredReqData |
{CapRevOrCredRRTags, [MThumbs], CapRevOrCredReqItemSeq, [CRvRqExtensions]} |
CapRevOrCredRRTags |
RRTags.
Новый идентификатор RRPID и Date для данной пары. |
MThumbs |
Оттиски сертификатов, CRL и BrandCRLIdentifier, хранящиеся в кэше продавца |
CapRevOrCredReqItemSeq |
{CapRevOrCredReqItem +}
Один или более CapRevOrCredReqItem в виде упорядоченного массива |
CRvRqExtensions |
Данные расширения отзыва платежа или запроса кредита должны иметь финансовый характер и играть важную роль для обработки этих сообщений расчетным центром или эмитентом. |
CapRevOrCredReqItem |
{TransIDs, AuthRRPID, CapPayload, [NewBatchID], CapRevOrCredReqDate, [CapRevOrCredReqAmt], NewAccountInd, [CRvRqItemExtensions]} |
TransIDs |
Копируется из соответствующего CapRes.
Поле необходимо, если соответствующий маркер CapToken отсутствует или не содержит подходящих данных авторизационного запроса |
CapPayload |
См. табл. 4.6.2.69 |
NewBatchID |
Это поле специфицирует новый идентификатор платежной линии; оно используется для запросов отзыва платежа для позиций, реализованных в рамках платежной линии, которая была закрыта. BatchID >в CapPayload идентифицирует исходную платежную линию. |
CapRevOrCredReqDate |
Дата подачи запроса |
CapRevOrCredReqAmt |
В кредитных запросах сумма запрашиваемого кредита, которая может отличаться от AuthAmt в CapToken и CapReqAmt в CapPayload |
NewAccountInd |
Указывает, что новый номер счета специфицирован в PANToken; когда это поле установлено, новый номер счета будет записан поверх информации о старом номере счета в CaptureToken или авторизационных данных, хранимых банком продавца. Использование этого поля является предметом политики платежной системы карты или банка продавца. |
CRvRqItemExtensions |
Данные в расширении поля данных отзыва платежа или запроса кредита должны иметь финансовый характер и быть важными для осуществления отзыва платежа или кредита расчетным центром |
Расчетный центр обрабатывает CapRevOrCredReqData следующим образом.
Шаг | Действие |
1 | Обрабатываются CRvRqxtensions. Если неподдерживаемое расширение помечено как критическое, возвращается отклик Error = unrecognizedExtensions, а обрабатываемое сообщение отбрасывается. |
2 | Обрабатывается каждое CapRevOrCredItem: Обрабатываются CRvRqItemExtensions. Если неподдерживаемое расширение помечено как критическое, возвращается отклик Error = unrecognizedExtensions Извлекается запись транзакции и производятся сравнения с TransIDs в CapRevOrCredItem Проверяется, что XID соответствует предшествующей транзакции. Если это не так, сообщение отбрасывается и посылается сообщение Error = unknownXID. Проверяется соответствие LID-C с записью транзакции. Если соответствия нет, сообщение отбрасывается и посылается отклик Error = unknownLID Проверяется CapPayload на соответствие записи транзакции. Если равенства нет, позиция отбрасывается и возвращается CapRevOrCredCode = capDataMismatch. Если установлен идентификатор NewBatchID, проверить, что BatchID является открытой платежной линией для BrandAndBIN. Если платежная линия закрыта, возвращается код CapRevOrCredCode = batchClosed. Если платежная линия неизвестна, возвращается код CapRevOrCredCode = batchUnknown. Запоминается CapRevOrCredAmt Если установлен NewAccountInd, использовать номер счета в PANToken для работы с расчетной картой в финансовой сети. |
3 | На основе TransIDs в AuthRevTags извлекается запись транзакции. |
Шаг | Действие |
1 | Заполнить поле CapRevOrCredTags |
2 | Заполнить текущий BrandCRLIdentifier, хранимый расчетным центром, если оттиск BrandCRLIdentifier не получен или устарел. |
3 | Если Mthumb указывает, что продавец нуждается в новом Cert-PE при шифровании информации для расчетного центра, то: Ввести Cert-PE в цифровой конверт PKCS#7 Ввести GKThumb в AuthResData, так как сам Cert-PE не защищен подписью |
4 | Опционно ввести BatchStatus в поле BatchStatusSeq для каждой платежной линии, чье состояние запрошено. |
5 | Для каждой позиции в соответствующем CapRevOrCredItems заполнить поле CapRevOrCredResItem следующим образом: Скопировать TransIDs из соответствующего CapRevOrCredReqItem Если доступно, скопировать RRPID из соответствующего CapRevOrCredItem Заполнить CapRevOrCredResPayload следующим образом: Занести в CapRevOrCredCode результат кредита или отзыва платежа Занести в CapRevOrCredActualAmt действительную сумму кредита или отзыва Если имеется, скопировать BatchID и BatchSequanceNum из соответствующего CapRevOrCredReqItem Опционно заполнить CRvRsPayExtensions |
6 | Опционно заполнить CRvRsExtensions |
Таблица 4.6.2.73. Структура CapRevOrCredResData
CapRevOrCredResData |
{CapRevOrCredRRTags, [BrandCRLIdentifier], [PEThumb], [BatchStatusSeq], CapRevOrCredResItemSeq, [CRvRsExtensions] |
CapRevOrCredRRTags |
RRTags; копируется CapRevOrCredRRTags из соответствующего поля CapRevOrCredReqData |
BrandCRLIdentifier |
Список текущих CRL для всех СА в зоне ответственности СА платежной системы. |
PEThumb |
Оттиск сертификата расчетного центра, поставляемого, если CapRevOrCredReq.MThumbs указывает, что продавец в нем нуждается |
BatchStatusSeq |
{BatchStatus +} |
CapRevOrCredResItemSeq |
{CapRevOrCredResItem +} Один или более CapRevOrCredResItem в упорядоченном массиве |
CRvRsExtensions |
Данные в расширении поля данных отклика на запрос отзыва платежа или кредита должны иметь финансовый характер и быть важными для осуществления отзыва платежа или кредита расчетным центром |
BatchStatus |
См. табл. 4.6.2.53. |
CapRevOrCredResItem |
{TransIDs, AuthRRPID, CapRevOrCredResPayload} |
TransIDs |
Копируется из соответствующего CapRevOrCredReqData.AuthReqData.AuthTags |
AuthRRPID |
RRPID, который появляется в соответствующем AuthReq или >AuthRevReq |
CapRevOrCredResPayload |
См. табл. 4.6.2.74 |
Структура данных CapRevOrCredResPayload представлена в таблице 4.6.2.74.
Таблица 4.6.2.74. Структура CapRevOrCredResPayload
CapRevOrCredResPayload |
{CapRevOrCredCode, CapRevOrCredActualAmt, [BatchID], [BatchSequenceNum], [CRvRsPayExtensions]} |
CapRevOrCredCode |
Числовой код, характеризующий состояние отзыва платежа или кредита. |
CapRevOrCredActualAmt |
Копируется из соответствующего CapRevOrCredReqItem. |
BatchID |
Идентификатор платежной линии сделки для банка продавца |
BatchSequenceNum |
Порядковый номер позиции в последовательности платежей |
CRvRsPayExtensions |
Расширение поля данных отклика на запрос отзыва платежа или кредита должны иметь финансовый характер и быть важными для обработки отклика на отзыв платежа или кредит. |
Допустимые значения кода CapRevOrCredCode представлены ниже
success |
Позиция была успешно обработана расчетным центром |
unspecifiedFailure |
Причина неудачи не специфицирована |
duplicateRequest |
Запрос отзыва платежа или кредита для данной транзакции был уже обработан (XID и AuthRRPID) |
originalProcessed |
Запрос платежа для данной позиции был уже обработан |
originalNotFound |
Специфицированная позиция расчетным центром не обнаружена |
capPurged |
Информация о платеже была удалена из памяти транзакций расчетного центра |
missingCapData |
Информация о платеже отсутствует в запросе отзыва платежа или кредита |
missingCapToken |
Необходимый для обработки данной позиции маркер CapToken отсутствует в запросе отзыва платежа или кредита |
invalidCapToken |
Маркер CapToken некорректен |
batchUnknown |
Платежная линия для данной позиции расчетному центру неизвестна |
batchClosed |
Платежная линия для данной позиции уже закрыта |
Обработка продавцом CapRevOrCredResData осуществляется следующим образом.
Шаг |
Действие |
1 |
Обработать CRvRsExtensions. Если какое-то нераспознанное расширение помечено как критическое, сообщение отбрасывается и посылается отклик Error = unrecognizedExtension. |
2 |
Обработать CapRevOrCredTags |
3 |
Извлечь запомненную запись транзакции и обработать TransIDs следующим образом: Проверить, что XID согласуется с данными из записи транзакции. Если согласия нет, сообщение отбрасывается, а в журнал операций записывается Error = unknownXID Проверить, что LID-C и LID-M согласуются с данными записи транзакции. Если согласия нет, сообщение отбрасывается, а в журнал операций записывается Error = unknownLID. |
4 |
Если в сообщение включен BrandCRLIdentifier, запомнить CRL. |
5 |
Проверить, что GKThumb согласуется с существующим сертификатом шифрования расчетного центра, если GKThumb присутствует. Если соответствия нет, актуализовать кэш сертификата с использованием текущего сертификата. |
6 |
Для каждого BatchStatus в batchStatusSeq обработать BatchStatus и запомнить результат |
7 |
Обработать каждый CapRevOrCredResItem в CapRevOrCredResItems следующим образом Обработать CRvRsPayExtensions. Если какое-либо не узнанное расширение помечено как критическое, сообщение отвергается и посылается отклик Error = unrecognizedExtension Извлечь записи транзакции, используя TransIDs. Если не удается найти транзакцию с подходящим TransIDs, отвергнуть сообщение и записать в журнал операций Error = unknownXID Сравнить LID-C и LID-M с данными в сообщении. Если согласия нет, сообщение отбрасывается, а в журнал операций записывается Error = unknownLID. Обработать CapRevOrCredPayload следующим образом: Обработать CapRevOrCredCode для получения результата Если предоставление кредита или отзыв платежа прошел успешно, записать CapCode и CapAmt Обработать BatchID и BatchSequenceNum, если таковые имеются |
Пара сообщений CapRevReq/CapRevRes служит для сокращения или аннулирования суммы предшествующего платежа. Они используются после осуществления оплаты и до того, как записи платежа продавца и его банка устареют. Обмен такими сообщениями носит опционный характер. Сообщение CapRevReq может быть послано когда угодно после запроса платежа, направленного расчетному центру. Структура данных в запросе CapRevReq представлена в таблице 4.6.2.75.
Таблица 4.6.2.75. Структура CapRevReq
CapRevReq |
<EncB(M, P, CapRevData, CapTokenSeq), EncBX(M, P, CapRevData, CapTokenSeq, PANToken)> CapTokenSeq является внешним “багажом”. Если PANToken содержится в сообщении, поле должно соответствовать одной записи в CapRevData.CapRevOrCredReqItemSeq и одному маркеру CapToken в CapTokenSeq |
CapRevData |
CapRevOrCredReqData |
CapTokenSeq |
{[CapToken] +} Один или более CapTokens, при полном соответствии последовательности CapRevOrCredReqItem в CapRevOrCredReqData.CapRevOrCredReqItemSeq. Заметим, что только маркер CapToken может быть опущен; т.е., может быть нулем (NULL) |
PANToken |
См. табл. 4.6.2.46 |
CapToken |
Копируется из соответствующего AuthRes или AuthRevRes |
Структура отклика показана ниже CapRevRes.
CapRevRes |
Enc(P,M, CapRevResData) |
CapRevResData |
CapRevOrCredResData |
Пары сообщений CredReq/CredRes используются для возвращения кредита по оплаченным ранее транзакциям. Они могут применяться вместо CapRevReq/Res, когда записи о конкретной транзакции у продавца и в расчетном центре оказались удаленными или устаревшими. Такая последовательность сообщений используется продавцом, который может послать запрос CredReq в любое время после согласования номера счета с банком продавца. Формирование запроса CredReq осуществляется в следующей последовательности.
Шаг |
Действие |
1 |
Генерируется информация CredReqData |
2 |
Для каждой позиции CapRevOrCred в CapRevOrCredItems заполнить позицию в CapTokSeq следующим образом: Если доступно, записать CapToken для соответствующей транзакции. В противном случае (если недоступно), записать NULL. Результатом этого шага будет CapTokSeq с соответствием один-к-одному между позициями в CredReqData и CapTokSeq |
3 |
Если доступно или необходим новый PAN, заполнить PANToken в дополнительную нишу EncBX-инкапсуляции. Если PANToken имеется, только одна позиция может присутствовать как в CredReqData, так и CapTokSeq |
4 |
Если PANToken имеется, использовать EncBX-инкапсуляцию, в противном случае EncB-инкапсуляцию. |
5 |
Вставить сообщение в цифровой конверт и послать владельцу карты |
Структура запроса CredReq показана в таблице 4.6.2.76.
Таблица 4.6.2.44. Структура CapToken
CapToken |
<Enc(P1, P2, CapTokenData), EncX(P1, P2, CapTokenData, PANToken), {}> P1 и P2 обозначают платежные центры: P1 – отправителя P2 - получателя В данной версии SET P1 и P2 означают один и тот же расчетный центр (т.е. P1=P2) |
CapTokenData |
{AuthRRPID, AuthAmt, TokenOpaque} |
PANToken |
Смотри табл. 4.6.2.46 |
AuthRRPID |
RRPID, который появляется в соответствующем AuthReq или AuthRevReq |
AuthAmt |
Действительное число авторизованных, которое может отличаться от PurchAmt владельца карты |
TokenOpaque |
Невидимые данные, определенные расчетным центром |
Алгоритм формирования CapToken показан ниже:
Шаг |
Действие |
1 |
Если формируется в ходе авторизации, установить AuthAmt в CapTokenData равным AuthAmt в AuthRes. В противном случае, если генерируется во время повторного авторизационного процесса, занести AuthAmt в CapTokenData равным AuthNewAmt для последующей посылки в AuthRevRes |
2 |
Занести в TokenOpaque из CapTokenData частные данные, необходимые для расчетов |
3 |
Если продавец получает PANToken из своего банка, тогда: Занести PANToken из PI Использовать EncX инкапсуляцию с CapTokenData в нормально зашифрованной части и PANToken в дополнительно зашифрованной секции В противном случае: Использовать Enc инкапсуляцию с CapTokenData |
Обработка CapToken производится следующим образом:
Шаг |
Действие |
1 |
Используя секретный ключ расчетного центра, извлечь CapTokenData из упаковки ЕncX или Enc. |
2 |
Если это платежный запрос (capture request) и CapToken уже использовался в таком запросе, установить CapCode в CapResPayload равным dublicateRequest. |
3 |
Если это аннулирование (reversal) платежного запроса, запрос кредита или отзыв кредита и CapToken ранее не использовался в платежных запросах, установить CapRevOrCredCode в поле CapRevOrCredResPayload равным originalNotFound |
4 |
Если это аннулирование платежного запроса, а CapToken уже использовался в подобном запросе, установить CapRevOrCredCode в CapRevOrCredResPayload равным dublicateRequest. |
5 |
Если CapCode или CapRevOrCredCode не были установлены при выполнении предыдущих шагов, переадресовать данные из CapToken процессу платежного запроса. |
PANData содержит информацию, идентифицирующую определенный счет платежной карты. Структура данных PANData представлена в таблице 4.6.2.45.
Таблица 4.6.2.76. Структура CredReq
CredReq | <EncB(M, P, CredReqData, CapTokenSeq), EncBX(M, P, CredReqData, CapTokenSeq, PANToken)> CapTokenSeq является внешним “багажом”. Если PANToken имеется, он должен соответствовать одной записи в CredReqData.CapRevOrCredReqItemSeq и одной CapToken в CapTokenS |
CredReqData | CapRevOrCredReqData ; см. табл. 4.6.2.72. |
CapTokenSeq | {[CapToken] +} Один или более CapTokens в соответствии один-к-одному с CapRevOrCredReqItem последовательностью в CapRevOrCredReqData.CapRevOrCredReqItemSeq. Заметим, что любой маркер CapToken может быть опущен, т.е., может быть NULL |
PANToken | См. табл. 4.6.2.46 |
CapToken | Копируется из соответствующего AuthResили AuthRevRes |
Расчетный центр обрабатывает полученный CredReq следующим образом.
Шаг | Действие | |
1 | Извлекается запрос из входного сообщения | |
2 | Для каждой позиции, для которой продавец получил маркер CapToken:
Проверяется присутствие CapToken. Если CapToken отсутствует, позиция отвергается и присылается CapRevOrReqCode = capTokenMissing Проверяется CapToken | |
3 | Для каждой транзакции в сообщении реализовать кредитную операцию, используя существующую финансовую сеть платежной карты, как это специфицировано в содержимом CapRevOrCredItem. |
Формирование CredRes осуществляется в следующей последовательности.
Шаг | Действие |
1 | Получить отклик из финансовой сети платежной карты |
2 | Сгенерировать CredResData, как это описано в CapRevOrCredResData, используя результаты из финансовой сети платежной карты. Заполнить RRTags, полученные в запросе |
3 | Включить Enc-инкапсуляцию для полученных результатов |
4 | Поместить сообщение в цифровой конверт и отправить владельцу карты |
Формат отклика CredRes представлен ниже.
CredRes | Enc(P, M, CredResData) |
CredResData | CapRevOrCredResData; см. табл. 4.6.2.74. |
Продавец обрабатывает CredRes за два шага:
Получается отклик CredRes из входного сообщения
Обрабатывается CredResData, как это описано в CapRevOrCredResData. Для каждого CapRevOrCredResItem проверяется CapRevOrCredCode, чтобы определить результат и записать успешно проплаченную сумму.
Шаг | Действие |
1 | Сформировать CredRevReqData, как это описано в разделе CapRevOrCredReq |
2 | Для каждой позиции CapRevOrCred в CapRevOrCredItem заполнить позицию в CapTokSeq следующим образом: Если доступен, занести CapToken для соответствующей транзакции В противном случае, если маркер не доступен, записать NULL |
3 | Если доступен или необходим новый PAN, занести PANToken в дополнительную нишу EncBX-инкапсуляции. Если PANToken в наличии, только одна позиция может присутствовать как в CredRevReqData, так и в CapTokSeq. |
4 | Если PANToken присутствует, включить EncBX-инкапсуляцию. В противном случае - EncB-инкапсуляцию. |
5 | Вставить сообщение в цифровой конверт и направить владельцу карты |
Таблица 4.6.2.77. Структура CredRevReq
CredRevReq | <EncB(M, P, CredRevReqData, CapTokenSeq), EncBX(M, P, CredRevReqData, CapTokenSeq, PANToken)> CapTokenSeq является внешним “багажом”. Если PANToken имеется, он должен соответствовать одной записи в CredRevReqData.CredRevReqSeq и однму маркеру CapToken в CapTokenSeq. |
CredRevReqData | CapRevOrCredReqData; см. табл. 4.6.2.72 |
CapTokenSeq | {[CapToken] +} Один или более CapTokens, в соответствии один-к-одному с CredRevReqItem в CapRevOrCredReqData.CapRevOrCredReqItemSeq. Заметим, что любой CapToken может быть опущен, т.е. может быть NULL |
PANToken | См. табл. 4.6.2.46 |
CapToken | Копируется из соответствующего AuthRes или AuthRevRes |
Расчетный центр обрабатывает запрос CredRevReq следующим образом.
Шаг | Действие | |
1 | Выделить запрос из входного сообщения | |
2 | Для каждой позиции, для которой продавец получил CapToken:
Проверить присутствие CapToken. Если CapToken отсутствует, отвергнуть позицию, послав CapRevOrReqCode = capTokenMissing Проверить CapToken | |
3 | Для каждой транзакции в сообщении выполнить отзыв кредита, используя существующую финансовую сеть расчетной карты, как это специфицировано содержимым CapRevOrCredItem |
Формирование отклика CredRevRes осуществляется в следующей последовательности.
Шаг | Действие |
1 | Получить отклик из финансовой сети платежной карты |
2 | Сформировать CredRevResData, как это описано в разделе CredRevOrCredResData, используя результаты из финансовой сети карты. Заполнить RRTags, полученные в запросе. |
3 | Включить для полученного результата Enc-инкапсуляцию |
4 | Вложить отклик в цифровой конверт и отправить владельцу карты |
Отклик CredRevRes имеет достаточно простой формат:
CredRevRes |
Enc(P, M, CredRevResData) |
CredRevResData |
CredRevOrCredResData; См. табл. 4.6.2.74. |
Продавец обрабатывает полученный отклик следующим образом
Шаг | Действие |
1 | Извлекается отклик из входного сообщения |
2 | Обрабатывается CredRevResData, как это описано в разделе о CapRevOrCredResData. Для каждого CapRevOrCredResItem проверяется CapRevOrCredCode, чтобы определить результат и записать сумму успешного платежа. |
Шаг | Действие |
1 | Заполнить PCertTags, как это описано в разделе о RRTags табл. 4.6.2.52. |
2 | Рекомендуется заполнить отклики Mthumbs путем вычисления оттисков сертификатов и CRL, хранящихся у продавца. Продавец должен занести оттиски в сообщение, которое может потребоваться позднее для верификации подписей и сертификатов, предоставленных расчетным центром. Включение этого поля служит оптимизации с целью уменьшения передач сертификатов и CRL в последующих сообщениях из расчетного центра. |
3 | Заполнить BrandIDSeq одним или более BrandIDandBIN, для которого необходимы сертификаты: Заполнить поле BrandID Опционно заполнить поле BIN |
4 | Опционно заполнить поле PCRqExtensions |
5 | Ввести S (см. описание оператора подпись выше) |
6 | Вложить сообщение в цифровой конверт и отправить владельцу карты |
PCertReq | S(M, PCertReqData) |
PCertReqData | {PCertTags, [MThumbs], BrandAndBINSeq, [PCRqExtensions]} |
PCertTags |
RRTags. Новый RRPID для этого PCertReq, MerTermIDs, поставляемый продавцом, и текущая дата |
MThumbs | Оттиски сертификатов расчетного центра, хранящиеся в кэше продавца. |
BrandAndBINSeq |
{BrandAndBIN +} Продавец запрашивает сертификаты расчетного центра для платежных систем карты, если оттиск текущего сертификата отсутствует в MThumbs |
PCRqExtensions | Запрос сертификата расчетного центра не шифруется, поэтому это расширение не должно содержать конфиденциальной информации |
BrandAndBIN | {BrandID, [BIN]} |
BrandID | Платежная система карты (без указания типа). |
BIN | Идентификационный номер банка для обработки транзакции продавца в расчетном центре. |
Таблица 4.6.2.63. Структура InqReq
InqReq |
<InqReqSigned, InqReqData> |
InqReqSigned |
S(C, InqReqData) |
InqReqData |
{TransIDs, RRPID, Chall-C2, [InqRqExtensions]} |
TransIDs |
Копируется из самого последнего: PReq, PRes, InqReq |
RRPID |
Идентификатор пары запрос/отклик |
Chall-C2 |
Новый вызов владельца карты по поводу подписи продавца. |
InqRqExtensions |
Информационный запрос не шифруется, по этой причине расширения не должны содержать конфиденциальной информации. |
Когда продавец получает InqReq, он обрабатывает это сообщение следующим образом:
Шаг |
Действие |
1 |
Извлекается запрос из входного сообщения |
2 |
Если получены данные InqReqData (в противоположность InqReqSigned), проверить, позволяет ли сертификат расчетного центра неподписанные транзакции. Если он этого не допускает, тогда: Прислать сообщение InqRes c CompletionCode = signatureRequired. Прервать обработку InqReq В противном случае перейти к пункту 4. |
3 |
Если получен InqReqSigned, проверить подпись. Если проверка подписи не прошла: Прислать сообщение Error с ErrorCode = signatureFailure Прервать обработку InqReq |
4 |
Сравнить TransIDs со значениями из цифрового конверта сообщения. Если равенства нет: Прислать сообщение Error c ErrorCode = wrapperMsgMismatch Прервать обработку InqReq |
5 |
Искать транзакцию в базе данных, основанную на TransIDs.XID. Если поиск неудачен: Прислать InqRes c CompletionCode = orderNotReceived. Прервать обработку InqReq |
6 |
Если PReq был подписан, проверить, что PReq и InqReq подписаны одним и тем же владельцем карты. Если соответствия нет, то: Прислать сообщение Error c ErrorCode = unknownXID. Прервать обработку InqReq |
7 |
Сформировать PResPayloadSeq |
Авторизация платежей продавца осуществляется согласно схеме, показанной на Рисунок 4.6.2.17.
Таблица 4.6.2.41. Структура InstallRecurData
InstallRecurData |
{InstallRecurDInd, [IRExtensions]} |
InstallRecurDInd |
< InstallTotalTrans, Recurring > |
IRExtensions |
Данные в расширении или рекурсивные данные. Они должны носить финансовый характер и должны иметь отношение к последующим процедурам авторизации продавца и расчетного центра |
InstallTotalTrans |
Владелец карты специфицирует максимально допустимое число авторизаций для последовательных платежей |
Recurring |
{RecurringFrequency, RecurringExpiry} |
RecurringFrequency |
Минимальное число дней между авторизациями (ежемесячная авторизация обозначается 28 днями) |
RecurringExpiry |
Окончательная дата, после которой никакие авторизации не разрешены |
Рекуррентные данные являются компонентом платежной инструкции, которая копируется в авторизационный маркер (token). Эта информация не пересылается эмитенту.
AuthToken представляет данные, необходимые расчетному центру для авторизации последующих транзакций. Расчетный центр, если необходимо, актуализует AuthToken. Данные, содержащиеся там должны быть доступны только расчетному центру. Структура данных AuthToken представлена в таблице 4.6.2.42.