Рисунок 4.6.2.15а. (продолжение)
Пары сообщений InqReq/InqRes позволяют владельцу карты получать информацию о состоянии транзакции. Запрос InqReq может быть послан в любое время после посылке продавцу PReq. В паре сообщений PReq/PRes владелец карты уведомляет продавца о том, что же он хочет купить. Сообщения AuthRevReq и AuthRevRes используются тогда, когда необходимо возобновить авторизацию. Сообщения CapRevReq и CAPRevRes организуют процесс отмены оплаты покупки, прежде чем сделка будет завершена. Пара CredReq и CredRes сходна с предыдущей парой, но используется после завершения сделки. Сообщения PCertReq/PCertRes обеспечивают для продавца механизм получения сертификата шифрования, который необходим для шифрования сообщения расчетному центру. BatchAdminReq и BatchAdminRes служат продавцу для открытия, закрытия и выяснения статуса транзакции его платежной линии с расчетным центром. Сообщения Error служат для уведомления об ошибках в протоколе или при обработке.
Рисунок 2.4.2. Адаптивный преобразователь голоса в код
Расширение диапазона преобразования достигается умножением шага квантования на величину несколько больше (или меньше) единицы.
При дифференциальном преобразовании на вход кодировщика подается не сам сигнал, а разница между текущим значением сигнала и предыдущим (Рисунок 2.4.3).
Рисунок 2.4.3. ADPCM-преобразователь голоса в код для 32кбит/с
Блок прогнозирования является адаптивным фильтром, который использует предшествующий код для оценки последующего стробирования. На вход кодировщика поступает сигнал, пропорциональный разнице между входным сигналом и предсказанием. Чем точнее предсказание, тем меньше бит нужно, чтобы с нужной точностью закодировать эту разницу. Характер человеческой речи позволяет заметно снизить требования к каналу при использовании адаптивного дифференциального преобразователя.
Для компактных музыкальных дисков (cd) характерна полоса 50Гц - 20 кГц, обычная же речь соответствует полосе 50 Гц - 7 кГц. Только звуки типа Ф или С имеют заметные составляющие в высокочастотной части звукового спектра. Для высококачественной передачи речи используется субдиапазонный ADPCM-преобразователь (Adaptive Differential Pulse Code Modulation). В нем звук сначала стробируется с частотой 16 кГц, производится преобразование в цифровой код с разрешением не менее 14 бит, а затем подается на квадратурный зеркальный фильтр (qmf), который разделяет сигнал на два субдиапазона (50Гц-4кГц и 4кГц-7кГц). Диапазоны этих фильтров перекрываются в области 4кГц. Нижнему диапазону ставится в соответствие 6 бит (48кбит/с), а верхнему 2 бита (16 Кбит/с). Выходы этих фильтров мультиплексируются, формируя 64 кбит/с -поток.
На CD используется 16-битное кодирование с частотой стробирования 44,1 кГц, что создает информационный поток 705 Кбит/c. Для стерео сигнала этот поток может удвоиться. Практически это не так - сигналы в стереоканалах сильно коррелированны, и можно кодировать и передавать лишь их разницу, на практике высокочастотные сигналы каналов суммируются, для различия каналов передается код их относительной интенсивности. Исследования показывают, что для акустического восприятия тонкие спектральные детали важны лишь в окрестности 2 кГц. Для передачи звуковой информации с учетом этих факторов был разработан стандарт MUSICAM (Masking pattern Universal Sub-band Integrated Coding and Multiplexing), который согласуется с ISO MPEG (Moving Picture Expert Group; стандарт ISO 11172). musicam развивает идеологию деления звукового диапазона на субдиапазоны, здесь 20кГц делится на 32 равных интервалов. Логарифмическая чувствительность человеческого уха и эффект маскирования позволяет уменьшить число разрядов кодирования. Эффект маскирования связан с тем, что в присутствии больших звуковых амплитуд человеческое ухо нечувствительно к малым амплитудам близких частот. Причем чем ближе частота к частоте маскирующего сигнала, тем сильнее этот эффект (см. Рисунок 2.4.4). Сплошной линией на рисунке показана нормальная зависимость порога чувствительности уха, а пунктиром - зависимость порога чувствительности в присутствии 500-герцного тона с амплитудой в 110 дБ.
Рисунок 6.2. Алгоритм атаки с использованием десинхронизации. Префикс А указывает на то, что сегмент послан атакующей ЭВМ; С - клиентом; s - сервером. Отправка атакующих кадров выделена малиновым цветом.
Определенные услуги хакеру может оказать внутренний протокол маршрутизации rip. Этот протокол служит для рассылки информации о маршрутах в локальной сети и не требует контроля доступа, что всегда благоприятствует злоумышленникам. Хакер может разослать маршрутную информацию, которая убедит окружающие узлы в том, что наикратчайший путь во внешний мир проходит через ЭВМ хакера Х. Тогда все пакеты, адресованные за пределы локальной сети, будут сначала попадать в ЭВМ Х.
Протокол управляющих сообщений ICMP носит вспомогательный характер (вспомним популярную утилиту ping, использующую этот протокол). Пакеты ICMP также не требуют проверки доступа (именно благодаря этому протокол пригоден для работы в масштабах Интернет). По одной этой причине протокол привлекателен для хакеров. Известны случаи, когда с его помощью люди с разных континентов бесплатно обменивались сообщениями. Пригоден протокол и для блокировки обслуживания. Для блокировки обслуживания используются icmp-сообщения “time exceeded” (превышено время) или “destination unreachable” (адресат недоступен). Первое сообщение означает, что предел указанный в поле TTL заголовка пакета превышен. Такое может произойти из-за зацикливания пакетов или, когда адресат расположен очень далеко. Сообщение “destination unreachable” имеет несколько значений. Но все они означают, что нет способа благополучно доставить пакет адресату. Оба сообщения вынуждают адресата немедленно прервать соединение. Для реализации своих коварных планов хакеру достаточно послать одно из этих сообщений одному или обоим участникам обмена.
Протокол ICMP может использоваться и для перехвата пакетов. ICMP-сообщение “redirect” обычно используется внешними портами (gateway) сети в случаях, когда какая-то ЭВМ по ошибке полагает, что адресат находится вне локальной сети и направляет пакеты, адресованные ему, через внешний порт.
Хакер может послать ICMP-сообщение “redirect” и вынудить другую ЭВМ посылать пакеты через узел, указанный хакером. У данного метода (также как и предыдущего с использованием RIP) имеется определенное ограничение – хакер и жертва должны находиться в пределах общей локальной сети.
Ещё одним объектом атак может стать DNS (domain name service) локальной сети. Например, администратор узла durak.dura.com может принять решение разрешить только местные соединения. Это может быть специфицировано с помощью записи “allow *.dura.com”, а не обязательно через указание IP-адресов. Тем более, что в сети может использоваться большое число блоков IP-адресов. Когда соединение установлено ЭВМ durak обращается к DNS для того, чтобы преобразовать IP-адрес отправителя в имя, которое затем служит для проверки условия, заданного администратором. Если хакер имеет доступ к местному DNS-серверу, он может заставить DNSоткликаться на его IP-адрес любым именем ЭВМ или домена. Зная об установленных администратором ограничениях, хакер может сделать так, что на запрос с его IP-адресом DNS будет откликаться именем “trustme.dura.com” (что удовлетворяет установленному ограничению). Такая атака может быть легко предотвращена путем повторного DNS-запроса с именем ЭВМ, присланным при первом запросе. Если IP-адрес, полученный при втором запросе, не совпадет с использованным в качестве параметра в первом, это означает, что DNS подверглась атаке.
Для атаки DNS извне достаточно узнать номер используемого UDP порта и ISN. О способах определения ISN говорилось выше. Задача упрощается в тех случаях, когда начальным значением ISN является нуль. Номер же используемого в данный момент UDP-порта при определенном везении можно найти путем подбора, ведь здесь нет никакой аутентификации или ограничений на число попыток. DNS один из самых привлекательных объектов для атак, так как через посредство AXFR-запросов можно получить информацию об узлах, которые используют определенные версии ОС с известными слабостями, упрощающими вторжение.
Точкой уязвимости могут быть загружаемые через сеть рабочие станции или Х-терминалы. Процедура загрузки предполагает использование протоколов RARP, TFTP и BOOTP. Все они практически не имеют сколько-нибудь серьезной защиты. Наиболее уязвим протокол RARP. Здесь желательно позаботиться о том, чтобы номер порта udp выбирался ЭВМ, осуществляющей загрузку случайным образом. В противном случае хакер может легко перехватит процедуру обмена и загрузить нужную ему конфигурацию программного обеспечения, обеспечив себе широкие ворота для проникновения. bootp предлагает дополнительные возможности защиты в виде 4-байтного случайного кода идентификатора процедуры (transaction ID). Это заметно мешает хакеру прервать процедуру и инициировать новую сессию загрузки (rebooting). Должны быть предприняты все меры, чтобы начатая процедура загрузки была своевременно завершена. Пребывание системы в промежуточном состоянии заметно облегчает разнообразные атаки.
Некоторые другие виды атак описаны в разделе, посвященном протоколу http. Многие из перечисленных выше проблем решаются при использовании прокси серверов типа firewall.
Но даже Firewall не может предотвратить атак со стороны хакеров, работающих внутри локальной сети. Здесь к их услугам огромный арсенал. Это, прежде всего, использование сетевого интерфейса для приема всех пакетов, следующих по сегменту (6-ой режим работы интерфейса), а также программные продукты типа tcpdump или Etherfind. Такой режим легко позволяет перехватывать незашифрованные пароли, определять используемые номера портов или ISN. К счастью такой комфорт для хакера предоставляется в пределах его логического сегмента, что стимулирует, кроме всего прочего, использование мостов, переключателей и локальных маршрутизаторов, которые ограничивают зону, где хакер может осуществлять перехваты. По этой же причине рекомендуется авторизованным администраторам работать с консоли, а не удаленного терминала. Следует иметь в виду, что обнаружить такого “шалуна” не так просто, ведь он может во многих случаях указывать в посылаемых пакетах не свой IP- и MAC-адрес.
Еще одним инструментом взлома может оказаться протокол ARP. Хакер может послать большое число широковещательных запросов, содержащих несуществующий IP-адрес. ЭВМ при получении такого запроса должна его обработать и может попытаться его переадресовать какому-то серверу. Всё это уже само по себе нежелательно, так как порождает большой паразитный трафик. Помимо этого хакер может попытаться послать широковещательный отклик, сообщая свой MAC-адрес в качестве адреса места назначения. Это может при определенных условиях предоставить возможность перехвата трафика между ЭВМ, пославшей первичный запрос, и истинным узлом назначения. Таким образом, постоянный мониторинг широковещательных запросов следует считать одной из составных частей системы безопасности локальной сети (см. также Robert T. Morris, A Weakness in the 4.2bsd Unix TCP/IP Software, Computer Science Technical Report N 117, at&t Bell laboratories), тем более что такой мониторинг не пораждает дополнительного трафика.
Определенную пользу с точки зрения безопасности может принести программы типа wrapper, которая позволяет отфильтровать нежелательные запросы и решить проблему аутентификации. Новые возможности в этой сфере предоставит новая версия протокола IPv6. Некоторые проблемы могут быть решены путем шифрования содержимого пакетов.
Применение сетей расширяется со скоростью 20% в месяц. Внешний трафик мультинациональных организаций увеличивается со скоростью 30% в год, а только за 1996 год сетевые воры украли ценной информации на сумму более 10 млн. долларов США (www.cuviello.com/_potrfolio/_semaphore).
Число зарегистрированных попыток нелегального проникновения в информационные системы растет экспоненциально, достигнув темпа прироста 60% в год. Но нужно принимать во внимание, что существенная часть таких попыток остается незамеченной или незарегистрированной. Адекватны этому и темпы роста расходов крупных фирм на средства и системы информационной безопасности.
Следует, впрочем иметь в виду, что чем лучше сеть (или ЭВМ) защищена от хакеров, тем менее удобно в ней работать.
Поэтому администратор сети всегда должен выбирать меньшее из зол, нельзя же делать лечение более опасным, чем сама болезнь.
Хакер, пытающийся нелегально проникнуть в ЭВМ, обычно начинает с использования процедуры Finger, чтобы определить имена реальных пользователей сети или ЭВМ (имя одного пользователя обычно известно - это root). Администратор сети-жертвы может заблокировать работу Finger. Но именно этот протокол наряду с SMTP используется системами Whois, X.500 и FRED при поиске людей в сети Интернет. Заблокировав Finger, администратор усложняет общение с внешними сетями.
Есть все же правила, следовать которым должен любой администратор. Среди них жесткое требование к выбору паролей и регулярной их смене является наиважнейшим. Известно, что 80% всех проблем, связанных с нелегальным проникновением в сеть, вызваны плохими паролями.
Пароль должен содержать не менее 5-7 символов. Желательно, чтобы он включал в себя строчные и прописные символы, а также цифры. Любые имена, фамилии, общеизвестные географические названия, названия улиц, номер страхового полиса, кредитной карточки, домашний номер телефона (записанные обычным образом или задом на перед), последовательности клавишей типа qwerty или абвгд и т.д. совершенно непригодны в качестве паролей, так как их подбор, например, с помощью программы satan занимает не более 5 минут. Наиболее важные части системы могут быть защищены двойным паролем, но даже это не дает полной гарантии. Во-первых, имеется возможность перехвата ваших пакетов (например, с помощью программы tcpdump или ее аналога), когда вы вводите свой пароль с удаленного терминала. Во-вторых, существуют программы типа "троянского коня", которые, будучи засланы в многопользовательскую систему, перехватывают весь ввод с терминалов, записывают их в виртуальные файлы и спустя какое-то время пересылаются "хозяину коня". На этом арсенал орудий взлома не исчерпывается. Одним словом, если у вас имеется информация, доступ к которой не желателен, не храните ее в ЭВМ, подключенной к Интернет (или любой другой аналогичной сети).
Следует иметь в виду, что "шалуны" могут быть и среди ваших коллег или друзей. Никогда ни при каких обстоятельствах не следует передавать свой пароль кому бы то ни было. Если это в вашей власти, помогите просящему получить к ЭВМ легальный доступ, но не передавайте пароль. В моей практике был случай, когда один программист из ИТЭФ передал свой пароль своему другу. Этот друг ради баловства через узел ИТЭФ заслал троянского коня в амстердамский телекоммуникационный узел. Факт засылки стал известен (для обнаружения используется программный пакет cops) и администратор сети прислал нам в институт оповещение об этом досадном инциденте. Были приняты административные меры к человеку, передавшему свой пароль (он был лишен определенных привилегий и доступа к ряду ЭВМ). Вряд ли какой-либо администратор мечтает о славе пособника сетевым террористам.
Безопасность сети определяется ее администратором. Именно он должен позаботиться о распределении ответственности между пользователями и администраторами ЭВМ и субсетей, именно он определяет конфигурацию программного обеспечения узла, вырабатывает меры на случай вторжения или повреждения системы. Администратор сети формулирует требования к сетевым паролям и контролирует их выполнение, определяет время жизни паролей (рекомендуемое время замены паролей равно 3-6 месяцам, новый пароль должен радикально отличаться от старого).
В тех случаях, когда ЭВМ помимо терминальных входов имеет доступ через модемы, используются, кроме того, так называемые “телефонные пароли” (dialup passwords). В этом случае во время процедуры logon помимо имени-идентификатора и пароля вводится также и телефонный пароль. Этот пароль является общим для всех пользователей на данной машине. Управляет этой процедурой исполняемый файл /etc/dpasswd. Программа имеет ряд опций. Сами пароли хранятся в закодированном виде в файле /etc/d_passwd. Если идентификация пользователя по названным выше трем параметром не увенчалась успехом, пользователю будет предложено повторить процедуру без указания того, какой из параметров введен неверно.
Для того чтобы контролировать, кто, когда и сколько времени провел в вашей ЭВМ, имеется файл-дневник (log-файл), где производятся соответствующие записи (например, /etc/wtmp). В таблице 6.1 размещены ссылки на различные log-файлы.
Рисунок 6.5.1. Алгоритм работы SSL
Ниже представлено несколько вариантов обмена сообщениями в рамках протокола диалога SSL. В этих примерах представлены два участника диалога: клиент (С) и сервер (S). Если что-то помещено в фигурные скобки, например, "{нечто}key", это означает, что “нечто” зашифровано с помощью ключа "key".
6.5.2.2.1. При отсутствии идентификатора сессии
Client-hello |
C ® S: |
challenge, cipher_specs |
server-hello |
S ® C: |
connection-id,server_certificate,cipher_specs |
client-master-key |
C ® S: |
{master_key}server_public_key |
client-finish |
C ® S: |
{connection-id}client_write_key |
server-verify |
S ® C: |
{challenge}server_write_key |
server-finish |
S ® C: |
{new_session_id}server_write_key |
6.5.2.2.2. Идентификатор сессии найден клиентом и сервером
сlient-hello |
C ® S: |
challenge, session_id, cipher_specs |
server-hello |
S ® C: |
connection-id, session_id_hit |
client-finish |
C ® S: |
{connection-id}client_write_key |
server-verify |
S ® C: |
{challenge}server_write_key |
server-finish |
S ® C: |
{session_id}server_write_key |
6.5.2.2.3. Использован идентификатор сессии и аутентификация клиента
сlient-hello |
C ® S: |
challenge, session_id, cipher_specs |
server-hello |
S ® C: |
connection-id, session_id_hit |
client-finish |
C ® S: |
{connection-id}client_write_key |
server-verify |
S ® C: |
{challenge}server_write_key |
request-certificate |
S ® C: |
{auth_type,challenge'}server_write_key |
client-certificate |
C ® S: |
{cert_type,client_cert, response_data}client_write_key |
server-finish |
S ® C: |
{session_id}server_write_key |
В последнем обмене, response_data является функцией auth_type.
6.5.2.3. Ошибки
Обработка ошибок в протоколе соединений SSL весьма проста. Когда ошибка детектирована, обнаруживший его посылает своему партнеру сообщение. Ошибки, которые являются неустранимыми, требуют от клиента и сервера разрыва соединения. Серверы и клиент должны "забыть" все идентификаторы сессии, сопряженные с разорванным соединением.
Протокол диалога SSL определяет следующие ошибки:
NO-CIPHER-ERROR
Эта ошибка присылается клиентом серверу, когда он не может найти шифр или размер ключа, который поддерживается также и сервером. Эта ошибка неустранима.
NO-CERTIFICATE-ERROR
Когда послано сообщение REQUEST-CERTIFICATE, эта ошибка может быть прислана, если клиент не имеет сертификата. Эта ошибка устранима.
BAD-CERTIFICATE-ERROR
Такой отклик присылается, когда сертификат по какой-то причине считается принимающей стороной плохим. Плохой означает, что, либо некорректна подпись сертификата, либо некорректно его значение (например, имя в сертификате не соответствует ожидаемому). Эта ошибка устранима (только для аутентификации клиента).
UNSUPPORTED-CERTIFICATE-TYPE-ERROR
Этот отклик присылается, когда клиент/сервер получает тип сертификата, который он не поддерживает. Эта ошибка устранима (только для аутентификации клиента).
6.5.2.4. Сообщения протокола диалога SSL
Сообщения протокола диалога SSL инкапсулируются в рекорды протокола SSL и состоят из двух частей: однобайтового кода типа сообщения, и некоторых данных. Клиент и сервер обмениваются сообщениями, пока обе стороны не пошлют сообщения finished, указывающие, что они удовлетворены диалогом SSL (Handshake Protocol).
После того как каждый из партеров определил пару ключей сессии, тела сообщений кодируются с помощью этих ключей. Для клиента это происходит, после того как он верифицировал идентификатор сессии, сформировал новый ключ сессии и послал его серверу. Для сервера это происходит, после того как идентификатор сессии признан корректным, или сервер получил сообщение клиента с ключом сессии. Для сообщений SSLHP (SSL Handshake Protocol) используется следующая нотация:
char MSG-EXAMPLE
char FIELD1
char FIELD2
char THING-MSB
char THING-LSB
char THING-DATA[(MSB<<8)|LSB];
...
Эта нотация определяет данные в протокольном сообщении, включая код типа сообщения. Порядок передачи соответствует порядку перечисления.
Для записи "THING-DATA", значения MSB и LSB в действительности равны THING-MSB и THING-LSB (соответственно) и определяют число байт данных, имеющихся в сообщении.
Например, если THING-MSB был равен нулю, а THING- LSB был равен 8, тогда массив THING-DATA будет иметь 8 байт.
Длина кодов характеризуется целым числом без знака, и когда MSB и LSB объединяются, результат также является целым числом без знака. Если не указано обратного, длины полей измеряются в байтах.
6.5.2.5. Протокольные сообщения клиента
Существует несколько сообщений, которые могут быть сформированы только клиентом. Эти сообщения ни при каких обстоятельствах не могут быть посланы сервером. Клиент, получив такое сообщение, закрывает соединение с сервером и присылает приложению уведомление об ошибке.
CLIENT-HELLO (Фаза 1; посылается открыто)
char MSG-CLIENT-HELLO
char CLIENT-VERSION-MSB
char CLIENT-VERSION-LSB
char CIPHER-SPECS-LENGTH-MSB
char CIPHER-SPECS-LENGTH-LSB
char SESSION-ID-LENGTH-MSB
char SESSION-ID-LENGTH-LSB
char CHALLENGE-LENGTH-MSB
char CHALLENGE-LENGTH-LSB
char CIPHER-SPECS-DATA[(MSB<<8)|LSB]
char SESSION-ID-DATA[(MSB<<8)|LSB]
char CHALLENGE-DATA[(MSB<<8)|LSB]
Когда клиент впервые подключается к серверу, он должен послать сообщение CLIENT-HELLO. Сервер ожидает это сообщение от клиента первым. Любое другое сообщение от клиента в данных обстоятельствах рассматривается как ошибка.
Клиент посылает серверу свою версию SSL, спецификацию шифров, некоторые данные вызова (challenge data), и данные идентификатора сессии. Данные идентификатора сессии посылаются клиентом только в том случае, когда в его кэше имеется идентификатор сессии, а значение SESSION-ID-LENGTH не равно нулю. Когда идентификатора сессии нет, то значение SESSION-ID-LENGTH должно быть равно нулю. Данные вызова используются для аутентификации сервера. После того как клиент и сервер согласовали пару ключей сессии, сервер присылает сообщение SERVER-VERIFY с зашифрованной формой CHALLENGE-DATA.
Заметим также, что сервер не пошлет сообщения SERVER-HELLO пока не получит сообщения CLIENT-HELLO. Это делается так, чтобы сервер мог в первом сообщении клиенту определить состояние идентификатора сессии клиента (т.e.
улучшить эффективность протокола и уменьшить объем обменов).
Сервер рассматривает сообщение CLIENT-HELLO и проверяет, поддерживает ли он версию программы клиента и хотя бы одну позицию в спецификации шифров клиента. Сервер может опционно отредактировать спецификацию шифров, удалив записи, которые он решил не поддерживать. Отредактированная версия будет прислана в сообщении SERVER-HELLO, если идентификатор сессии не находится в кэше сервера.
Значение CIPHER-SPECS-LENGTH должно быть больше нуля и кратно 3. Код SESSION-ID-LENGTH должен быть равен нулю или 16. Значение CHALLENGE-LENGTH должно быть больше чем ?
16 и ? 32.
Это сообщение должно быть первым, посланным клиентом серверу. После его посылки клиент ждет сообщения SERVER-HELLO. Любое другое сообщение, присланное сервером (кроме ERROR) не допустимо.
CLIENT-MASTER-KEY (Фаза 1; посылается вначале открыто)
char MSG-CLIENT-MASTER-KEY
char CIPHER-KIND[3]
char CLEAR-KEY-LENGTH-MSB
char CLEAR-KEY-LENGTH-LSB
char ENCRYPTED-KEY-LENGTH-MSB
char ENCRYPTED-KEY-LENGTH-LSB
char KEY-ARG-LENGTH-MSB
char KEY-ARG-LENGTH-LSB
char CLEAR-KEY-DATA[MSB<<8|LSB]
char ENCRYPTED-KEY-DATA[MSB<<8|LSB]
char KEY-ARG-DATA[MSB<<8|LSB]
Клиент посылает это сообщение, когда он определил мастерный ключ для работы с сервером. Заметим, что когда идентификатор сессии согласован, это сообщение не посылается.
Поле CIPHER-KIND указывает, какой шифр выбран из спецификации CIPHER-SPECS сервера.
Данные CLEAR-KEY-DATA содержат открытую часть MASTER-KEY. CLEAR-KEY-DATA комбинируются с SECRET-KEY-DATA, чтобы образовать MASTER-KEY, при этом SECRET-KEY-DATA составляет младшие байты MASTER-KEY. ENCRYPTED-KEY-DATA содержит секретные части MASTER-KEY, зашифрованные с использованием общедоступного ключа сервера. Шифруемые блоки формируются с использованием блоков типа 2 PKCS#1 [5]. Информационная часть блока имеет следующий формат:
char SECRET-KEY-DATA[SECRET-LENGTH]
SECRET-LENGTH равно числу байт каждого из ключей сессии. SECRET-LENGTH плюс CLEAR-KEY-LENGTH равно числу байт в ключе шифра (как это определено CIPHER-KIND).
Если после дешифрования SECRET- LENGTH окажется неравным ожидаемому значению, регистрируется ошибка. Ошибкой считается и ситуация, когда CLEAR-KEY-LENGTH не равно нулю и CIPHER-KIND является не экспортным шифром.
Если алгоритм ключа требует аргумента (например, вектора инициализации DES-CBC), тогда поле KEY-ARG-LENGTH будет ненулевым и KEY-ARG-DATA будет содержать соответствующую информацию. Для алгоритмов SSL_CK_RC2_128_CBC_WITH_MD5, SSL_CK_RC2_128_CBC_EXPORT40_WITH_MD5, SSL_CK_IDEA_128_CBC_WITH_MD5, SSL_CK_DES_64_CBC_WITH_MD5 и SSL_CK_DES_192_EDE3_CBC_WITH_MD5 должны присутствовать данные KEY-ARG с длиной 8 байт.
Вычисление ключей сессии клиента и сервера является функцией CIPHER-CHOICE:
SSL_CK_RC4_128_WITH_MD5
SSL_CK_RC4_128_EXPORT40_WITH_MD5
SSL_CK_RC2_128_CBC_WITH_MD5
SSL_CK_RC2_128_CBC_EXPORT40_WITH_MD5
SSL_CK_IDEA_128_CBC_WITH_MD5
KEY-MATERIAL-0 = MD5[ MASTER-KEY, "0", CHALLENGE, CONNECTION-ID ]
KEY-MATERIAL-1 = MD5[ MASTER-KEY, "1", CHALLENGE, CONNECTION-ID ]
CLIENT-READ-KEY = KEY-MATERIAL-0[0-15]
CLIENT-WRITE-KEY = KEY-MATERIAL-1[0-15]
Где KEY-MATERIAL-0[0-15] означает первые 16 байт данных KEY-MATERIAL-0, с KEY-MATERIAL-0[0], образующим старший байт CLIENT-READ-KEY.
Данные передаются хэш-функции MD5, начиная с MASTER-KEY, далее следует "0" или "1", затем вызов (CHALLENGE) и, наконец, CONNECTION-ID.
Заметим, что "0" означает ASCII символ нуль (0x30), а не значение нуль. "1" означает ASCII символ 1 (0x31). MD5 выдает 128 бит выходных данных, которые используются в качестве ключа алгоритма шифрования (старший байт хэша MD5 становится старшим байтом ключевого материала).
SSL_CK_DES_64_CBC_WITH_MD5
KEY-MATERIAL-0 = MD5[ MASTER-KEY, CHALLENGE, CONNECTION-ID ]
CLIENT-READ-KEY = KEY-MATERIAL-0[0-7]
CLIENT-WRITE-KEY = KEY-MATERIAL-0[8-15]
Для DES-CBC, 16-байтовый ключевой материал формируется с помощью MD5. Первые 8 байт дайджеста MD5 используются в качестве CLIENT-READ-KEY, в то время как оставшиеся 8 байт используются в качестве CLIENT-WRITE-KEY.
Вектор инициализации берется из KEY-ARG-DATA.
SSL_CK_DES_192_EDE3_CBC_WITH_MD5
KEY-MATERIAL-0 = MD5[ MASTER-KEY, "0", CHALLENGE, CONNECTION-ID ]
KEY-MATERIAL-1 = MD5[ MASTER-KEY, "1", CHALLENGE, CONNECTION-ID ]
KEY-MATERIAL-2 = MD5[ MASTER-KEY, "2", CHALLENGE, CONNECTION-ID ]
CLIENT-READ-KEY-0 = KEY-MATERIAL-0[0-7]
CLIENT-READ-KEY-1 = KEY-MATERIAL-0[8-15]
CLIENT-READ-KEY-2 = KEY-MATERIAL-1[0-7]
CLIENT-WRITE-KEY-0 = KEY-MATERIAL-1[8-15]
CLIENT-WRITE-KEY-1 = KEY-MATERIAL-2[0-7]
CLIENT-WRITE-KEY-2 = KEY-MATERIAL-2[8-15]
Данные передаются хэш-функции MD5 в указанном порядке, слева направо: первым поступает MASTER-KEY, затем "0", "1" или "2", далее CHALLENGE и, наконец, CONNECTION-ID (идентификатор сессии).
Заметим, что "0" означает ascii символ нуль (0x30), а не код нуль. "1" означает ascii символ 1 (0x31). "2" означает ascii символ 2 (0x32).
Всего генерируется 6 ключей, 3 ключа читающей стороны для шифра DES-EDE3 и 3 - для пишущей стороны для функции DES-EDE3. Вектор инициализации формируется в KEY-ARG-DATA.
Вспомним, что MASTER-KEY передан серверу в сообщении CLIENT-MASTER-KEY. CHALLENGE выдается серверу клиентом в сообщении CLIENT-HELLO. CONNECTION-ID передается клиенту от сервера в сообщении SERVER-HELLO. Это делает получаемые в результате ключи, зависящими от исходной и текущей сессии. Заметим, что мастерный ключ никогда не используется для шифрования данных, и следовательно не может быть легко раскрыт.
Сообщение CLIENT-MASTER-KEY должно быть послано после сообщения CLIENT-HELLO и до сообщения CLIENT-FINISHED. Сообщение CLIENT-MASTER-KEY должно быть послано, если сообщение SERVER-HELLO содержит значение SESSION-ID-HIT равное 0.
CLIENT-CERTIFICATE (Фаза 2; посылается шифрованным)
char MSG-CLIENT-CERTIFICATE
char CERTIFICATE-TYPE
char CERTIFICATE-LENGTH-MSB
char CERTIFICATE-LENGTH-LSB
char RESPONSE-LENGTH-MSB
char RESPONSE-LENGTH-LSB
char CERTIFICATE-DATA[MSB<<8|LSB]
char RESPONSE-DATA[MSB<<8|LSB]
Это сообщение посылается клиентом SSL в ответ на сообщение сервера REQUEST-CERTIFICATE. CERTIFICATE-DATA содержит данные, определенные значением CERTIFICATE-TYPE. Сообщение об ошибке ERROR посылается с кодом NO-CERTIFICATE-ERROR, если данный запрос не может быть обработан корректно (например, получатель сообщения не имеет зарегистрированного сертификата). CERTIFICATE-TYPE является одним из:
SSL_X509_CERTIFICATE
CERTIFICATE-DATA содержит подписанный сертификат X.509 (1988) [3].
RESPONSE-DATA несет в себе аутентификационные данные отклика. Эти данные зависят от значения AUTHENTICATION-TYPE, посланного сервером.
Когда код AUTHENTICATION-TYPE равен SSL_AT_MD5_WITH_RSA_ENCRYPTION, тогда RESPONSE-DATA содержит цифровую подпись следующих компонентов (в указанном порядке):
KEY-MATERIAL-0
KEY-MATERIAL-1 (только если определено типом шифра)
KEY-MATERIAL-2 (только если определено типом шифра)
CERTIFICATE-CHALLENGE-DATA (из сообщения REQUEST-CERTIFICATE)
Сертификат, подписанный сервером (из сообщения SERVER-HELLO).
Цифровая подпись формируется с привлечением MD5, полученный хэш шифруется с использованием общедоступного ключа клиента, формат подписи согласуется со стандартом PKCS#1 [5]. Сервер аутентифицирует клиента путем верификации его цифровой подписи. Допускается добавление нового типа AUTHENTICATION-TYPE или идентификатора алгоритма цифровой подписи.
Это сообщение должно быть послано клиентом только в ответ на сообщение REQUEST-CERTIFICATE сервера.
CLIENT-FINISHED (Фаза 2; посылается шифрованным)
char MSG-CLIENT-FINISHED
char CONNECTION-ID[N-1]
Клиент посылает это сообщение, после успешной обработки соответствующего сообщения сервера. Заметим, что клиент должен быть готов к приему сообщений от сервера, пока не получит сообщение SERVER-FINISHED. Данные CONNECTION-ID представляют собой исходный идентификатор соединения сервера, посланный в его сообщении SERVER-HELLO и зашифрованный посредством согласованного ключа сессии.
"N" равно числу байт в посланном сообщении, таким образом "N-1" равно числу байт в сообщении за вычетом одного байта заголовка.
Для версии протокола 2, клиент должен посылать это сообщение после получения сообщения SERVER-HELLO. Если в сообщении SERVER-HELLO флаг SESSION-ID-HIT не равен нулю, тогда сообщение CLIENT-FINISHED посылается немедленно, в противном случае сообщение CLIENT-FINISHED посылается после сообщения CLIENT-MASTER-KEY.
6.5.2.6. Протокольные сообщения сервера
Существует несколько сообщений, которые генерируются только серверами.
SERVER-HELLO (Фаза 1; посылается открыто)
char MSG-SERVER-HELLO
char SESSION-ID-HIT
char CERTIFICATE-TYPE
char SERVER-VERSION-MSB
char SERVER-VERSION-LSB
char CERTIFICATE-LENGTH-MSB
char CERTIFICATE-LENGTH-LSB
char CIPHER-SPECS-LENGTH-MSB
char CIPHER-SPECS-LENGTH-LSB
char CONNECTION-ID-LENGTH-MSB
char CONNECTION-ID-LENGTH-LSB
char CERTIFICATE-DATA[MSB<<8|LSB]
char CIPHER-SPECS-DATA[MSB<<8|LSB]
char CONNECTION-ID-DATA[MSB<<8|LSB]
Сервер посылает это сообщение после получения CLIENT-HELLO. Сервер возвращает флаг SESSION-ID-HIT, указывающий, известен ли серверу полученный идентификатор сессии (т.e. хранится ли он в кэше сервера). Флаг SESSION-ID-HIT будет не равен нулю, если клиент посылает серверу идентификатор сессии (в сообщении CLIENT-HELLO с SESSION-ID-LENGTH != 0), а сервер обнаружит этот идентификатор в своем кэше. Если флаг SESSION-ID-HIT не равен нулю, то поля CERTIFICATE-TYPE, CERTIFICATE-LENGTH и CIPHER-SPECS-LENGTH будут содержать код нуль.
Значение CERTIFICATE-TYPE, если оно не равно нулю, должно содержать одну из перечисленных выше величин (см. информацию о сообщении CLIENT-CERTIFICATE).
Когда флаг SESSION-ID-HIT равен нулю, сервер укладывает свой сертификат, спецификацию шифров и идентификатор соединения и посылает их клиенту. Используя эту информацию, клиент может сформировать ключ сессии и послать его серверу в сообщении CLIENT-MASTER-KEY.
Когда флаг SESSION-ID-HIT не равен нулю, как сервер так и клиент вычисляют новую пару ключей сессии, базируясь на мастерном ключе MASTER-KEY, который они получили при создании идентификатора SESSION-ID.
SERVER-READ-KEY и SERVER-WRITE- KEY получаются из исходных ключей MASTER-KEY тем же способом, что CLIENT-READ-KEY и CLIENT-WRITE-KEY:
SERVER-READ-KEY = CLIENT-WRITE-KEY
SERVER-WRITE-KEY = CLIENT-READ-KEY
Заметим, что когда ключи получены и установлен флаг SESSION-ID-HIT, а сервер обнаружил идентификатор сессии клиента в своем кэше, тогда данные KEY-ARG-DATA используются с момента, когда определен идентификатор SESSION-ID. Это делается, потому что клиент не посылает новых данных KEY-ARG-DATA (напомним, что данные KEY-ARG-DATA посланы в сообщении CLIENT-MASTER-KEY).
CONNECTION-ID-DATA представляет собой строку случайных байт, используемых сервером и клиентом в разных местах протокола. Сообщение CLIENT-FINISHED содержит зашифрованную версию CONNECTION-ID-DATA. Длина CONNECTION-ID должна лежать между 16 и 32 байтами, включительно.
CIPHER-SPECS-DATA определяет тип шифра и длину ключа (в битах), которые поддерживает принимающая сторона. Каждая спецификация SESSION-CIPHER-SPEC имеет длину 3 байта и выглядит как:
char CIPHER-KIND-0
char CIPHER-KIND-1
char CIPHER-KIND-2
Где CIPHER-KIND равен одному из:
SSL_CK_RC4_128_WITH_MD5
SSL_CK_RC4_128_EXPORT40_WITH_MD5
SSL_CK_RC2_128_CBC_WITH_MD5
SSL_CK_RC2_128_CBC_EXPORT40_WITH_MD5
SSL_CK_IDEA_128_CBC_WITH_MD5
SSL_CK_DES_64_CBC_WITH_MD5
SSL_CK_DES_192_EDE3_CBC_WITH_MD5
Этот список не является исчерпывающим и может быть расширен в будущем. Конфигурации этих средств безопасности стандартизованы (см. табл. 6.5.1).
6.4.8 Алгоритм шифрования SAFER
Алгоритм шифрования SAFER (Secure And Fast Encryption Routine; http://fn2.freenet.edmonton.ab.ca/~jsavard/co0403.html) не использует разбивку исходного текста на блоки (как это делается в DES или IDEA). Здесь исходный текст пропускается через S-матрицы, которые заменяются на обратные версии при дешифровании. В SAFER используется 8 циклов. Первый шаг цикла заключается в использовании первого субключа для преобразования 8 байт исходного текста. То, как используется субключ, зависит от номера байта в группе. Так для 1-го, 4-го, 5-го и 8-го для этого служит операция XOR, а для 2-го, 3-го, 6-го и 7-го байтов применяется операция сложения.
Затем при обработке текста в S-матрице байты, для которых было применено исключающее ИЛИ, поступают на обычную матрицу, для остальных применяется инвертированная. s-матрицы представляют собой таблицы байтов, которые получаются по формуле 45N mod 257, где N –номер кода в таблице (после чего выделяются 8 младших разрядов).
1 45 226 147 190 69 21 174
120 3 135 164 184 56 207 63
8 103 9 148 235 38 168 107
189 24 52 27 187 191 114 247
64 53 72 156 81 47 59 85
227 192 159 216 211 243 141 177
255 167 62 220 134 119 215 166
17 251 244 186 146 145 100 131
241 51 239 218 44 181 178 43
136 209 153 203 140 132 29 20
129 151 113 202 95 163 139 87
60 130 196 82 92 28 232 160
4 180 133 74 246 19 84 182
223 12 26 142 222 224 57 252
32 155 36 78 169 152 158 171
242 96 208 108 234 250 199 217
0 212 31 110 67 188 236 83
137 254 122 93 73 201 50 194
249 154 248 109 22 219 89 150
68 233 205 230 70 66 143 10
193 204 185 101 176 210 198 172
30 65 98 41 46 14 116 80
2 90 195 37 123 138 42 91
240 6 13 71 111 112 157 126
16 206 18 39 213 76 79 214
121 48 104 54 117 125 228 237
128 106 144 55 162 94 118 170
197 127 61 175 165 229 25 97
253 77 124 183 11 238 173 75
34 245 231 115 35 33 200 5
225 102 221 179 88 105 99 86
15 161 49 149 23 7 58 40
Обратная матрица при этом имеет вид.
128 0 176 9 96 239 185 253
16 18 159 228 105 186 173 248
192 56 194 101 79 6 148 252
25 222 106 27 93 78 168 130
112 237 232 236 114 179 21 195
255 171 182 71 68 1 172 37
201 250 142 65 26 33 203 211
13 110 254 38 88 218 50 15
32 169 157 132 152 5 156 187
34 140 99 231 197 225 115 198
175 36 91 135 102 39 247 87
244 150 177 183 92 139 213 84
121 223 170 246 62 163 241 17
202 245 209 23 123 147 131 188
189 82 30 235 174 204 214 53
8 200 138 180 226 205 191 217
208 80 89 63 77 98 52 10
72 136 181 86 76 46 107 158
210 61 60 3 19 251 151 81
117 74 145 113 35 190 118 42
95 249 212 85 11 220 55 49
22 116 215 119 167 230 7 219
164 47 70 243 97 69 103 227
12 162 59 28 133 24 4 29
41 160 143 178 90 216 166 126
238 141 83 75 161 154 193 14
122 73 165 44 129 196 199 54
43 127 67 149 51 242 108 104
109 240 2 40 206 221 155 234
94 153 124 20 134 207 229 66
184 64 120 45 58 233 100 31
146 144 125 57 111 224 137 48
После обработки с помощью S-матрицы используется второй субключ, который воздействует на блок преобразуемых данных. В этом случае используется другая последовательность операций: ADD, XOR, XOR, ADD, ADD, XOR, XOR, ADD (сравните с порядком операций, указанным в первом абзаце главы). Далее байты группируются: второй байт заменяется суммой первого байта и второго, первый – суммой нового значения второго байта и первого, четвертый – суммой третьего и четвертого, третий – суммой нового значения четвертого и третьего и т.д. вплоть до 8 байта включительно (см. Рисунок 6.4.8.1). При суммировании в результате операции учитываются только младшие 8 бит. По завершении этой процедуры байты выкладываются в следующем порядке (цифры означают старое положений байтов):
3 5 7 2 4 6 8
amtExp10). Значение может быть как положительным, так и отрицательным.
Для того чтобы представить сумму US $2.87 в поле PurchAmt, в поля currency, amount и amtExp10 заносятся коды 840, 250 и –2.
Поля Date
Даты в SET обычно указываются в форме строк, характеризующих календарную дату и время UTC в формате:
YYYYMMDDHHMM[SS[.f]f]f]]]Z
где Z литерал буквы Z в верхнем регистре. Таким образом, строка должна состоять из четырех цифр, характеризующих год, по две цифры, определяющие месяц, день, час (24-часовое представление) и минуту. После минут опционно могут присутствовать две цифры секунд. Если поле секунд присутствует, далее могут опционно быть прописаны доли секунды. Запись может иметь, например, форму:
20011003102853.33Z,
что означает 2001 год, 03 октября, 10 часов 28 минут 53,33 секунды. Полночь отмечается датой, следующего дня.
Рисунок 4.6.2.17. Авторизация платежей
Процесс авторизации проходит через три состояния. Во время обработки заказа от владельца карты продавец авторизует транзакцию. Программа продавца формирует и цифровым образом подписывает авторизационный запрос, который включает в себя сумму платежа, подлежащую авторизации, идентификатор транзакции из OI и некоторые другие данные. Запрос затем шифруется с использованием нового случайного симметричного ключа, который в свою очередь шифруется общедоступным ключом расчетного центра. Это тот самый ключ, который использовал владелец карты для шифрования цифрового конверта с платежными инструкциями. Запрос авторизации и платежные инструкции владельца карты передаются в расчетный центр.
Когда расчетный центр получает авторизационный запрос, он дешифрует цифровой конверт запроса и извлекает из него симметричный ключ. Этот ключ используется для дешифрования текста запроса. Далее верифицируется сертификат подписи продавца срок его действия, а также цифровая подпись.
После этого расчетный центр дешифрует цифровой конверт платежных инструкций (PI), откуда извлекается симметричный ключ и информация о счете клиента. Ключ используется для дешифрования PI. Используя общедоступный ключ владельца карты и дайджест OI (включенный в PI), проверяется цифровую подпись, чтобы убедиться, что PI не модифицированы и что они подписаны с использованием секретного ключа владельца карты.
Расчетный центр проверяет, что идентификатор транзакции, полученный от продавца, соответствует идентификатору, присланному в PI. При успешном завершении этих проверок расчетный центр формирует и отсылает через финансовую сеть авторизационный запрос эмитенту карты.
При получении отклика авторизации от эмитента расчетный центр генерирует и подписывает цифровым образом авторизационный отклик, который содержит отклик эмитента и копию сертификата подписи расчетного центра. Этот отклик может также включать в себя платежный маркер (capture token) с данными, которые будут нужны расчетному центру для обработки платежного запроса.
Платежный маркер вставляется в отклик только в случае, если этого требует банк продавца (Получатель).
Отклик шифруется с помощью вновь сформированного секретного симметричного ключа, который в свою очередь шифруется общедоступным ключом продавца. После шифрования отклик посылается продавцу.
Когда программа продавца получает авторизационный отклик из расчетного центра (РЦ), она дешифрует цифровой конверт и извлекает оттуда симметричный ключ, посредством которого дешифруется текст отклика. Продавец верифицирует сертификат подписи расчетного центра, а посредством общедоступного ключа РЦ и его цифровую подпись.
Продавец запоминает авторизационный отклик и платежный маркер для последующего использования при обработке платежных запросов. Далее продавец может осуществлять доставку товаров или услуг, оговоренных в заказе.
Обмен AuthReq/AuthRes возможен как для исключительно авторизованных транзакций, так и транзакций оплаты. Пара запрос/отклик автортизации предоставляет механизм авторизации сделки. В запросе авторизации продавец посылает подписанные и зашифрованные данные о покупке, а также инструкцию PI, полученную от владельца карты. Так как каждая из секций содержит хэш OD и количества (Amount), расчетный центр может проверить то, что владелец карты и продавец договорились о заказе и сумме, которые следует авторизовать. Так как PI включает данные платежной карты, необходимые для авторизации, расчетный центр может выполнить авторизацию, используя существующую финансовую сеть платежной карты.
Когда продавец заранее знает, что заказ будет выполняться по частям (несколько поставок), он осуществит несколько шагов AuthReq (по одному для каждой части). Продавец устанавливает в первом AuthReq значение SubsequentAuthInd равным TRUE, что представляет собой указание на авторизацию выполнения первой части заказа. Расчетный центр пришлет в отклике AuthRes значение AuthToken. Продавец будет вынужден выполнить дополнительные запросы AuthReq для реализации последующих этапов выполнения заказа.
В каждое последующее сообщение AuthReq продавец должен включать значение AuthToken из предшествующего отклика расчетного центра. В последнем AuthReq продавец установит значение SubsequentAuthInd равным FALSE. Когда продавец обнаруживает, что заказ будет выполняться поэтапно после отправки AuthReq, он должен послать AuthRevReq, чтобы согласовать число дополнительных авторизаций, и установить SubsequentAuthInd = TRUE, для получения AuthToken в последующих откликах AuthRes. Алгоритм формирования AuthReq представлен ниже.
Шаг | Действие |
1 | Сгенерировать AuthTags (см. табл. ниже) |
2 | Сгенерировать HOD2 путем хэширования OD, PurchAmt, ODSalt, ODExtensions и, если имеется, InstallRecurData. Расчетный центр сравнит его значение с полученным в PI. |
3 | Сгенерировать AuthReqPayload (см. табл. ниже) |
4 | Опционно для одновременной авторизации и резервирования заказа: Установить CaptureNow = TRUE Сгенерировать SaleDetail (см. табл. 4.6.2.47) Опционно занести в поле BatchID значение открытой в настоящее время платежной линии (серия платежей для данного клиента) для BrandAndBIN. Это значение должно быть ассоциировано с текущей транзакцией и BatchSequenceNumber (номер платежа). Может так случиться, что банк продавца не может выполнить одновременно авторизацию и платеж для данного заказа даже при CaptureNow=TRUE. В этом случае AuthCode=captureNotSupported укажет на то, что производится только авторизация. Продавец может послать позднее запрос CapReq, чтобы выполнить платеж для данного заказа. |
5 | Включить CheckDigest с вычисленными продавцом H(OIData) и HOD2. H(PIData) копируется продавцом из PReq. Это поле опускается, если запрос AuthReq представляет последовательную авторизацию, базирующуюся на присланном из расчетного центра коде AuthToken. |
6 | Рекомендуется заполнить MThumbs путем вычисления оттисков сертификатов и CRL, хранимых продавцом. Продавец должен внести в сообщение оттиски, которые могут потребоваться позднее для верификации подписи и сертификатов расчетного центра. |
7 | Осуществить EncB-инкапсуляцию |
8 | Включить сертификаты подписи и шифрования отправителя и всей цепи сертификации вплоть до сертификата платежной системы. |
9 | Поместить сообщение в цифровой конверт и отправить адресату |
Шаг | Действие |
1 | Заполнить поле AuthRRTags (см. табл. 4.6.2.52) |
2 | Заполнить поле TransIDs. Если это последовательная авторизация и определено PaySysID, занести его значение в поле PaySysID. |
3 | Если это многоэтапный платеж и банк продавца задал для авторизации значение AuthRetNum, скопировать AuthRetNum из предыдущего AuthRes |
Шаг | Действие |
1 | Если планируется обработка последовательных авторизаций для покупки и это не последняя авторизация, установить SubsequentAuthInd равным TRUE, в противном случае FALSE. |
2 | Если продавец и владелец карты договорились о рекуррентных или поэтапных платежах, заполнить поле InstallRecurData |
3 | Установить AuthReqAmt равным числу авторизаций |
4 | Опционно присвоить CardSuspect соответствущее значение, если продавец имеет какие-то подозрения относительно владельца карты. |
5 | Если при некотором платеже необходимы данные MerchData, добавить их в сообщение. |
6 | Сформировать MarketSpecAuthData, если это диктуется платежной системой карты или типом покупки. |
7 | Если политика платежной системы карты требует наличия AVSData, записать в это поле информацию, предоставленную владельцем карты. |
8 | Если политика платежной системы карты требует наличия SpecialProcessing, сгенерировать его значение. |
9 | Если продавец требует информацию о типе платежной карты, установить RequestCardTypeInd = TRUE. |
6.6 Безопасное ядро (SSH)
Администрирование сетей обычно производится с консоли. Это удобный и наиболее безопасный метод. Но время от времени возникают ситуации, когда администратор вынужден выполнять те или иные системные операции с удаленного терминала. Если терминальный обмен не зашифрован, он может быть перехвачен с помощью любой машины (например, используя программу tcpdump), подключенной к тому же логическому сегменту или, в более общем случае, к тому же каналу. Именно по этой причине целесообразно выделять почтовый сервер, DNS, сервер новостей и маршрутизаторы в отдельный сетевой сегмент, к которому не подключены “посторонние” машины. Для того чтобы предотвратить перехват сессии авторизации и последующей работы оператора, в Финляндии разработана специальная программа “безопасное ядро” SSH (Secure Shell). Эта общедоступная программа пригодна для любых удаленных сессий, включая те, которые используют протокол HTTP. SSH использует для шифрования как открытого ключа так и симметричной схемы. При этом производится аутентификация ЭВМ и формирование коммуникационного канала с шифрованием передаваемых данных. В отличие от SSL здесь не требуется приобретать сертификат сервера или клиента для обеспечения высокой степени безопасности. Благодаря тому, что программа разработана в Европе, пользователь даже за пределами США получает высокий уровень защиты (нет экспортных лицензионных ограничений). SSH заменяет для приложений, где требуется безопасность, такие программы как telnet, rlogin, rsh и rcp. Эта программа для ЭВМ, на которых установлена, шифрует также и сессии X Windows. Привлекательность программы заключается в том, что помимо перечисленных возможностей она применима для шифрования практически любой TCP/IP сессии, например, FTP или HTTP. Это реализуется путем запуска специальной прокси-программы на вашей локальной ЭВМ. Прокси-программа шифрует запрос и организует туннель до нужного сервера. Это позволяет использовать редактор HTML, графический WEB-броузер и другие программные продукты, которые сами по себе не поддерживают криптографической защиты. Шифрованная связь поддерживается с WEB-сервером, который не имеет соответствующего сертификата.
Для формирования SSH-прокси на удаленном WEB-сервере сначала нужно зарезервировать не используемый порт на локальной машине, например, 5678. После этого следует использовать программу SSH для того, чтобы установить связь, например, с каким-то WEB-сервером. При этом для создания прокси следует применить опцию –L:
SSH –L5678:www.pod.potol.com:80 www.pod.potol.com
Аргумент, следующий после флага опции -L имеет формат:
<локальный порт>:<удаленная ЭВМ>:<удаленный порт>.
Таким образом, мы требуем, чтобы прокси прослушивала локальный порт 5678 и переадресовывала весь обмен в зашифрованном виде в порт 80 узла www.pod.potol.com. После выполнения данной команды следует, например, запустить WEB-броузер на вашей ЭВМ и потребовать установления связи с http://localhost:5678/. Практически будет установлена связь с http://www.pod.potol.com, но весь диалог в этом варианте уже будет зашифрован. По завершении работы с броузером следует выполнить команду logout на удаленной ЭВМ. Общедоступную версию SSH можно найти по адресу: www.cs.hut.fi/ssh. Информацию о коммерческих версиях для Windows и Macintosh можно найти на сервере: www.datafellows.com/f-secure.
Рисунок 6.4.8.1. Блок-схема реализации цикла алгоритма SAFER
После этого процедуры группирования и суммирования и перемешивания байтов повторяются.
Дешифровка в рамках алгоритма SAFER реализуется для каждой из процедур (путем замены их на обратные), примененной при шифровании независимо.
В качестве первого 64-битного субключа используется основной ключ шифрования. Для генерации последующих ключей используется циклический сдвиг влево на 3 бита. Полученные результаты объединяются с определенной константой (специфичной для каждого цикла) с помощью операции исключающее ИЛИ (XOR). Для первого субключа эта константа равна нулю. Далее используются константы, приведенные ниже:
16733B1E8E70BD86
477E2456F1778846
B1BAA3B7100AC537
C95A28AC64A5ECAB
C66795580DF89AF6
66DC053DD38AC3D8
6AE9364943BFEBD4
9B68A0655D57921F
715CBB22C1BE7BBC
63945F2A61B83432
FDFB1740E6511D41
8F29DD0480DEE731
7F01A2F739DA6F23
FE3AD01CD1303E12
CD0FE0A8AF82592C
7DADB2EFC287CE75
1302904F2E723385
8DCFA981E2C4272F
7A9F52E115382BFC
42C708E409555E8C
BrandCRLIdentifier
BrandCRLIdentifier (BCI) представляет собой структуру, определенную SET и используемую для идентификации всех рабочих CRL заданной области ответственности сертификационного центра платежной системы. BrandCRLIdentifier содержит в себе следующую информацию:
Номер BCI (увеличивается для каждого нового BCI)
Название платежной системы
Время пригодности BCI
Список номеров CRL (из расширения номера CRL)
Эмитент и серийный номер сертификата СА платежной системы, который используется для подписи BCI (включается в расширение)
Подпись BCI производится с привлечением секретного ключа, соответствующего сертификату CRLSign. BCI пересылаются владельцам карт и продавцам в виде сообщений-откликов.
Рисунок 4.6.2.14. Диаграмма обмена для протокола покупки
На Рисунок 4.6.2.15 показаны все возможные сообщения, которые могут иметь место при обработке транзакции (опционные сообщения отмечены курсивом). Следует заметить, что приведенный порядок обмена является рекомендуемым, и допускается его изменение.
Рисунок 4.6.2.4. Диаграмма реализации протокола SET
Начальным состоянием покупателя является shopping. Когда решение о покупке принято, программой клиента посылается запрос PReq и система переходит в состояние заказано. Запрос PReq включает в себя инструкцию OI (Order Instruction) и платежную инструкцию PI. Отклик PRes держателю карты может быть прислан немедленно или с некоторой задержкой. Полученная в отклике информация зависит от состояния протокольной машины (принят заказ, транзакция авторизована и т.д.).
Продавец посылает запрос авторизации платежному серверу, но флаг CaptureNow не устанавливается равным “истинно”, так как запрос оплаты (capture request) будет обработан позже. В состоянии авторизовано допускается частичный пересмотр условий сделки, при этом система может вернуться в состояние заказано или остаться в состоянии авторизовано. Продавец теперь имеет платежное обязательство от эмитента карты, но он должен обработать запрос покупки, для того чтобы получить соответствующую оплату. Запрос CapReq переводит транзакцию в состояние приобретено (Captured – сделка оплачена) и заказ обрабатывается.
Если поступит запрос отмены сделки, система возвращается в состояние авторизовано. Далее владелец карты может запросить кредит. В этом случае обрабатывается запрос кредита, переводя транзакцию из состояния покупка осуществлена (sale processed) в состояние кредит выдан (credit issued).
Запрос покупки (Sale Request) используется, когда продавец знает, что заказанный товар на складе и может быть поставлен немедленно при наличии авторизации. Этот запрос используется также в случае заказа товара или услуг, доставляемых через Интернет. Когда расчетный центр (Payment Gateway) обрабатывает запрос, происходит переход транзакции в состояние покупка осуществлена. С финансовой точки зрения состояния sale processed (обработана) и captured (оплачена) являются эквивалентными. В случае необходимости возврата денег клиенту, запрос кредита (CredReq) переводит систему в состояние кредит получен.
Следует учитывать, что реализации некоторых компаний не поддерживают частичный возврат денег (сумма из запроса AuthRevReq копируется в сообщение AuthRevRes).
Когда продавец не может выполнить заказ в полном объеме сразу, он поставляет имеющиеся в наличии товары, а нехватающие заказывает дополнительно. Продавец может предложить клиенту различные схемы оплаты, например, осуществить оплату заказа в несколько этапов, или в случае предоставления Интернет услуг оплата может происходить на регулярной основе раз в месяц без участия самого держателя кредитной карты.
Протокол SET позволяет расчетному центру (Payment Gateway) определять, будет ли продавец получать номер счета владельца карты. Если эмитент карты решает не выдавать эту информацию, продавцу должен быть предоставлен какой-то другой механизм для возвращения сдачи в рамках текущей транзакции. Для этих целей в рамках транзакции предусмотрено несколько полей:
XID |
20-байтовое число, которое однозначно идентифицирует транзакцию (включает в себя все аутентификационные и клиринговые сообщения). |
RRPID | 20-байтовое число, которое однозначно идентифицирует запрос. |
locallD-M | 1-20 байтовый локальный идентификатор, присваиваемый транзакции программой продавца |
paySysID | 1-64 байтовый идентификатор транзакции |
MerOrderNum | 1-25 байтовый номер заказа продавца |
Держатель карты (Cardholder) |
Авторизованный владелец платежной карты, предоставленной ему эмитентом и предназначенной для выполнения платежей за покупки и услуги. |
Продавец (Merchant) | Субъект или фирма, предлагающие товары, информацию или услуги, получающие от этого прибыль в виде платежей. |
Эмитент (Issuer) | Финансовая организация, которая осуществляет выпуск платежных карт для клиентов и поддерживает функционирование их счетов. Эмитент гарантирует осуществление платежа для авторизованной транзакции. |
Получатель (Acquirer) | Финансовая организация, которая поддерживает продавцов, осуществляя операции с платежными картами. Получатель осуществляет сбор финансовых данных, имеющих отношение к транзакции, для получения авторизации платежа, который выполняет эмитент. |
Расчетный центр (Payment Gateway) |
Система, которая предоставляет коммерческие услуги продавцам через посредство получателя, и обеспечивает интерфейс получателю для авторизации и реализации транзакции. Расчетный центр обычно управляется получателем. |
Платежная система (Brand) | Система или компания, предоставляющая платежные средства (например, карты VISA, MasterCard и т.д.) |
Сертификационный центр (Certificate Authority –CA) | Агент одной или нескольких систем платежных карт, который осуществляет создание и рассылку сертификатов для продавцов, покупателей и расчетных центров. Участники транзакции могут иметь единый сертификационный центр, но могут работать и с разными центрами. Основная задача СА – гарантия того, что данное сообщение, ключ и т.д. посланы определенным субъектом, а не самозванцем. |
Рисунок 4.6.2.7. EncryptedData
Тип DigestedData из PKCS #7 проиллюстрирован на Рисунок 4.6.2.8.
Рисунок 4.6.2.6. EnvelopedData
В пределах EnvelopedData допускается наличие нескольких EnvelopedData и только одно RecepientInfo.
Тип EncryptedData из PKCS #7 проиллюстрирован на Рисунок 4.6.2.7.
Рисунок 7.3. Формат информационной структуры msg_struc
Взаимодействие операторов winsock для систем, не ориентированных на соединение, показано на рисунке 7.4. Здесь также как и в случае, ориентированном на соединение, сервер вызывает socket и bind, после чего обращается к процедуре recvfrom (вместо read или recv). Программа-клиент в данной схеме обращается к оператору bind и совсем не использует оператор connect (ведь предварительного соединения не нужно). Для передачи запросов и приема откликов здесь служат операторы sendto и recvfrom, соответственно.
Рисунок 4.4.16.1. Формат представления временной метки
Заметим что с некоторого времени в 1968 (2,147,483,648 секунда) старший бит (бит 0 целочисленной части) стал равным 1 и 64-битовое поле переполнится в 2036 году. Если NTP или SNTP будут использоваться в 2036 г, будут необходимы некоторые внешние по отношению к данному протоколу меры для определения того относительно 1900 или 2036 года отсчитана приведенная дата (это справедливо и для других дат, кратных 136 годам).
Так как формат временных меток NTP использовался в течение последних 17 лет, остается возможность того, что он будет использоваться еще 40 лет. Так как временных меток NTP до 1968 не существует, можно считать приемлемым, что при бите 0 равном 1, UTC-время лежит в диапазоне 1968-2036 с началом отсчета 0 час. 0 мин. 0 сек. 1 января 1900 г. Если же бит 0 равен нулю, время лежит в диапазоне 2036-2104 г., а UTC-время отсчитывается от 6 час. 28 мин. 16 сек. 7 февраля 2036. Заметим, что при этом вычислении 2000 год не считался високосным.
4. Формат сообщений NTP
Протоколы NTP и SNTP используют в качестве транспортного протокол UDP. При этом работает UDP-порт 123 (NTP), который проставляется как в поле порта отправителя, так и получателя UDP-заголовка.
Ниже приводится описание формата сообщений NTP/SNTP v.4, которые размещаются после UDP-заголовка. Этот формат идентичен описанному в RFC-1305, за исключением содержимого поля идентификатора эталона (reference identifier). Поля заголовка представлены на Рисунок 4.4.16.2:
Рисунок .2. Формат SMDS-пакета
Адреса места назначения и отправителя состоят из 4-битного кода, за которым следует телефонный номер, содержащий до 15 десятичных чисел. Каждая цифра кодируется посредством четырех бит. Телефонный номер содержит код страны, код зоны и номер клиента-подписчика, что делает сеть SMDS международной. Длина поля данные является переменной. Когда пакет попадает в сеть SMDS, первый маршрутизатор проверяет, соответствует ли адрес отправителя номеру входной линии. При несоответствии пакет отбрасывается.
Существенной особенностью SMDS является возможность мультикастинга. Пользователь может составить список номеров и присвоить ему специфический адрес. Отправка пакета по этому адресу вызовет его переадресацию всем клиентам, чьи адреса присутствуют в списке. Это воспроизведение на сетевом уровне возможности почтового списка рассылки.
Другой особенностью адресации в SMDS является возможность использования списков доступа (screening) для входящих и исходящих пакетов. Кроме того, такая функция позволяет эффективно строить корпоративные сети типа Интранет. Поле данных может содержать в себе кадр Ethernet или пакет Token Ring, что также повышает эффективность и надежность работы сети, упрощая задачу интерфейсного оборудования.
Работа в условиях всплесков загрузки осуществляется следующим образом. Маршрутизатор в каждом из интерфейсов содержит счетчик, который инкрементируется с постоянной частотой (например, раз в 10 мксек). Когда на вход маршрутизатора приходит пакет, осуществляется сравнение длины пакета в байтах с содержимым этого счетчика. Если содержимое счетчика больше, пакет немедленно пересылается, а содержимое счетчика уменьшается на длину пакета. Если длина пакета больше содержимого счетчика, такой пакет отбрасывается. В результате при данной частоте приращения счетчика в среднем допускается передача 100000 байт/сек. Но импульсная загрузка может существенно превышать это значение.
Рисунок 4.4.13.2 Формат snmp-сообщений, вкладываемых в UDP-дейтограммы
Поле версия содержит значение, равное номеру версии snmp минус один. Поле пароль (community – определяет группу доступа) содержит последовательность символов, которая является пропуском при взаимодействии менеджера и объекта управления. Обычно это поле содержит 6-байтовую строку public, что означает общедоступность. Для запросов GET, GET-next и SET значение идентификатора запроса устанавливается менеджером и возвращается объектом управления в отклике GET, что позволяет связывать в пары запросы и отклики. Поле фирма (enterprise) = sysobjectid объекта. Поле статус ошибки характеризуется целым числом, присланным объектом управления:
Рисунок 7.2 Формат списка указателей для функций readv и writev
Команды send(s, msg_buf, buflen, flags) и recv имеют аналогичный формат, но среди параметров обращения содержат переменную flags, которая служит для целей диагностики и управления передачей данных (например, пересылка информации с высоким приоритетом (MSG_OOB - Message Out Of Band), что используется, в частности, при передаче звуковых сообщений). При работе с операторами send или recv надо быть уверенным, что принимающая сторона знает, что ей следует делать с этими приоритетными сообщениями. Другой возможный флаг, определяемый константой MSG_PEEK, позволяет анализировать запросы из входной очереди транспортного уровня. Обычно после считывания данных из входной очереди, они уничтожаются. Когда MSG_PEEK=1, данные из входной очереди не стираются. Этот флаг используется, например, программой FTP. При успешном выполнении команды будет возвращено число переданных байтов, в противном случае -1.
Все перечисленные выше операторы рассчитаны на использование в рамках протоколов, ориентированных на установление соединения (TCP), где не требуется указание адреса места назначения. В протоколах типа UDP (не ориентированных на соединение) для передачи информации используются операторы sendto, recvfrom или sendmsg:
R=sendto(s, msg_buf, buflen, flags, adr_struc, adr_struc_len)
или recvfrom(s, msg_buf, buflen, flags, adr_struc, adr_struc_len),
где s - дескриптор соединителя, msg_buf - указатель на буфер, где лежит сообщение, buflen - длина этого буфера (длина сообщения), adr_struc - адресная структура, содержащая исчерпывающую информацию об адресате, adr_struc_len - длина этой структуры. Оператор recvfrom принимает все данные, приходящие на его порт. Приняв дейтограмму, recvfrom записывает также адрес, откуда эта дейтограмма получена. Сервер может посылать по этому адресу дейтограмму-отклик. Вызов оператора sendmsg имеет форму:
R=sendmsg(s, msg_struc, flags) [или recvmsg(s, msg_struc, flags)],
где s - дескриптор соединителя, msg_struc - информационная структура, формат которой показан ниже на рисунке 7.3. Применение структур делает программирование пересылки сообщений более гибким. Следует учитывать, что для обменов, не ориентированных на соединение, соединитель как бы состоит лишь из одной половины (IP-адрес и номер порта). “Соединители”, созданные для обмена (UDP) однажды, далее могут жить своей жизнью. Они могут принимать пакеты от других аналогичных “соединителей” и сами посылать им дейтограммы (кавычки здесь связаны с тем, что это не реальный соединитель и никакого соединения здесь не осуществляется).
Рисунок 4.4.13.3. Формат заголовка SNMP-запроса
Поле Флаг=0x30 является признаком ASN.1-заголовка. Коды Ln - представляют собой длины полей, начинающиеся с байта, который следует за кодом длины, вплоть до конца сообщения-запроса (n - номер поля длины), если не оговорено другое. Так L1 – длина пакета-запроса, начиная с T1 и до конца пакета, а L3 – длина поля пароля. Субполя Tn - поля типа следующего за ними субполя запроса. Так T1=2 означает, что поле характеризуется целым числом, а T2=4 указывает на то, что далее следует пароль (поле community, в приведенном примере = public). Цифры под рисунками означают типовые значения субполей. Код 0xA - является признаком GET-запроса, за ним следует поле кода PDU (=0-4, см. табл. 4.4.13.1) Блок субполей идентификатора запроса служит для тех же целей, что и другие идентификаторы - для определения пары запрос-отклик. Собственно идентификатор запроса может занимать один или два байта, что определяется значением Lиз. СО – статус ошибки (СО=0 - ошибки нет); ТМ - тип MIB-переменной (в приведенном примере = 0x2B); ИО - индекс ошибки. Цифровой код MIB-переменной отображается последовательностью цифровых субполей, характеризующих переменную, например: переменная 1.3.6.1.2.1.5 (в символьном выражении iso.org.dod.internet.mgmt.mib.icmp) характеризуется последовательностью кодов 0x2B 0x06 0x01 0x02 0x01 0x05 0x00.
SNMP-протокол служит примером системы управления, где для достижения нужного результата выдается не команда, а осуществляется обмен информацией, решение же принимается "на месте" в соответствии с полученными данными.
Рисунок 4.4.16.2. Формат заголовка SNTP-пакета
Поле LI (Leap Indicator) содержит два бита кода предупреждения о добавлении/удалении секунды в последней минуте текущего дня. Значения кодов поля LI приведены в таблице 4.4.16.1:
Рисунок 4.2.1.2.2. Формат заголовка SPX-II
Управление сетями Novell осуществляется с помощью стандартного протокола SNMP (Simple Network Management Protocol) и управляющей базы данных MIB.
Рисунок 4.2.1.2.1. Формат заголовка SPX-пакета
Поле управления соединением определяет, является ли данный пакет системным или прикладным. Это поле содержит однобитовые флаги, используемые spx и spx ii для управления потоком данных в виртуальном канале.
0x01 XHD |
Зарезервировано SPX II для расширения заголовков; |
0x02 RES1 |
Назначение поля не определено, должно быть равно нулю; |
0x04 NEG |
SPX II (SIZ) согласует размер запроса/отклика, для spx должно быть равно нулю; |
0x08 SPX2 |
Тип пакета SPX II, для spx должно быть равно нулю; |
0x10 EOM |
Устанавливается клиентом spx для индикации конца сообщения (end-of-message); |
0x20 ATN |
(attention) зарезервировано для специальных запросов (не поддерживается SPX); |
0x40 ACK |
Устанавливается для запроса подтверждения получения данного пакета. Запросы и отклики обрабатываются на уровне SPX (приложение не должно модифицировать этот код); |
0x80 SYS |
Устанавливается, если данный пакет является системным и служит для подтверждения. Приложения не используют пакеты этого типа. |
Поле тип потока данных характеризует тип данных, помещенных в пакет. Значения этого поля перечислены ниже:
0x00-0x07 |
определяется клиентом и может использоваться в приложениях; |
0x80-0xfb |
зарезервированы на будущее; |
0xfc |
spx ii, упорядоченное освобождение запроса; |
0xfd |
spx ii, упорядоченное освобождение подтверждения; |
0xfe |
указывает на окончание связи (end-of-connection). При закрытии канала spx-драйвер посылает клиенту пакет, где в поле тип потока записан данный код; |
0xff |
подтверждение получения сообщения об окончании связи (end-of-connection-acknowledgment). Этим кодом помечается пакет, подтверждающий закрытие канала, в прикладную программу такой пакет не передается |
Поля идентификатора отправителя и получателя содержат коды, определяющие участников информационного обмена, присваиваются SPX-драйвером в момент установления связи. В запросах на соединение это поле содержит код 0xffff.
Данное поле служит для обеспечения демультиплексирования пакетов, поступающих на один и тот же соединитель (socket). Поле последовательный номер определяет число пакетов пересланных в одном направлении. Каждый из партнеров обмена имеет свой счетчик, который сбрасывается в ноль после достижения 0xffff, после чего счет может продолжаться. Для приложения это поле, также как и последующие два, неприкосновенно. spx-пакеты подтверждения содержат в этом поле порядковый номер последнего посланного пакета. Поле номер подтверждения характеризует последовательный номер следующего пакета, который spx ожидает получить. Любой пакет с порядковым номером меньше, чем задано в поле номера подтверждения, доставлен благополучно и не требует ретрансмиссии. Поле число буферов служит для указания числа доступных на станции буферов (буфера нумеруются, начиная с 0, один буфер способен принять один пакет) и используется для организации управления потоком данных между приложениями. Код этого поля информирует партнера о наибольшем порядковом номере пакета, который может быть послан. Протокол spx посылает пакеты до тех пор, пока локальный последовательный номер не станет равным числу-указателю на удаленной ЭВМ.
SPX-протокол не посылает следующий пакет до тех пор, пока не получит подтверждение получения предшествующего. Хотя в протоколе SPX предусмотрен алгоритм скользящих окон (как и в TCP), практически он в настоящее время не используется, что вполне оправдано для локальных сетей. Следует заметить, что для достаточно больших LAN, где пакет проходит через несколько переключателей или маршрутизаторов, пренебрежение техникой окон становится непозволительной роскошью. На случай непредвиденных обрывов связи в spx имеется алгоритм “сторожевая собака”. Этот алгоритм реализуется специальной программой, которая активируется лишь в случае, когда в течение определенного времени в канале отсутствует трафик в любом из направлений (машина все сделала, а оператор заснул). В этом случае программа посылает специальные пакеты и, если определенное число попыток “достучаться” до партнера не увенчается успехом, сессия прерывается.
Если партнер не присылает отклик за оговоренное время (RTT), производится повторная посылка пакета, при этом RTT увеличивается на 50%. Значение RTT не должно превысить величины max_retry_delay, которая по умолчанию равна 5 секундам. Если связь не восстановилась, отправитель пытается найти другой маршрут до адресата. Если маршрут найден, счетчик попыток сбрасывается в ноль и процедура отправки запускается вновь. Допустимое число попыток может лежать в диапазоне 1-255 (по умолчанию - 10). При отсутствии успеха сессия прерывается.
Значение RTT определяется по времени отклика ближайшего маршрутизатора, которое удваивается, а к полученной величине добавляется некоторая константа. Для каждой из сессий RTT определяется независимо. Многие временные константы задаются администратором сети.
Протокол spx позволяет осуществить от 100 до 2000 соединений одновременно (по умолчанию это число равно 1000). Конфигурационные параметры SPX-протокола (и сети) хранятся в файлах shell.cfg и net.cfg.
В 1992 году была разработана новая версия SPX - SPX II. Главное усовершенствование протокола связано с применением пакетов большего размера. Раньше длинные spx-пакеты фрагментировались и пересылались по частям, учитывая, что очередной пакет может быть послан лишь после получения подтверждения, нетрудно понять крайнюю неэффективность такой схемы. Стандарт spx позволяет обмен пакетами с размером, ограниченным только используемой сетевой средой. Так в Ethernet пакет SPX II может иметь длину 1518 байт. Кроме того, SPX II допускает использование технологии окон, то есть можно послать несколько кадров, не дожидаясь получения подтверждения на каждый из уже посланных. Размер окна устанавливается в соответствии с кодом, содержащимся в поле число-указатель (число буферов/пакетов). При необходимости администратор может задать размер окна раз и навсегда. Формат пакетов SPX II несколько отличается от SPX. В SPX II увеличено число допустимых кодов для поля управления соединением, введено дополнительное поле в заголовок подтверждения (два байта, имя поля “расширенное подтверждение”).Новое поле добавлено после поля число буферов. Алгоритм установление связи в SPX II отличатся от варианта spx тем, что необходимо согласовать размер пересылаемых пакетов.
ЭВМ Б проигнорирует сообщения от А, так как они имеют неправильные (навязанные хакером) номера, а ЭВМ А проигнорирует сообщения от Б, так как ожидает, что они будут пронумерованы по-новому. Теперь хакер знает, какие номера нужны А и Б (непосредственно же А и Б взаимодействовать не могут, так как не знают правильных номеров) и может перехватывать, модифицировать или посылать сообщения по своему усмотрению как А, так и Б.
Но десинхронизация может быть реализована и в ходе сессии. Если послать флаг RST в середине сессии, соединение будет закрыто, о чем будет оповещено приложение и пользователь. Для того чтобы вызвать десинхронизацию в середине сессии, не закрывая соединения, достаточно поменять порядковые номера в сообщениях. Протокол telnet имеет механизм, который позволяет решить такую задачу. В рамках протокола можно посылать команды nop (“Ничего не делать”, согласитесь – хорошие команды!). Эти команды не производят никакого эффекта, но увеличивают ожидаемое значение порядкового номера сегмента. Послав некоторое количество таких команд, ЭВМ хакера вызовет десинхронизацию. Теперь только хакер знает правильные значения порядковых номеров пакетов и может начать свою подрывную работу.
Одним из наиболее эффективных методов обнаружения таких атак помимо процента сегментов ACK является сравнение потоков ACK для сервера и клиента. Полной гарантией безопасности в такой ситуации может стать только шифрование на прикладном уровне, например по схеме kerberos. В случае использования почты хороший результат может дать электронная подпись (например, PGP).
Атака на раннем этапе установления соединения может осуществляться следующим образом. Соединение при этом разрушается и вместо него формируется новое с другим значением ISN. Хакер прослушивает виртуальный канал и ждет сообщения SYN+ACK от сервера клиенту (вторая фаза установления соединения). При получении такого сообщения хакер посылает серверу RST-кадр, а затем SYN-пакет с теми же параметрами (TCP-порт), но с другим значением ISN (далее и на рис 6.2 этот кадр обозначается a_ack_0; префикс А указывает на принадлежность атакующей машине хакера). Сервер, получив RST, закроет прежнее соединение и, получив SYN, сформирует новое для того же порта, но с новым значением ISN. После чего пошлет клиенту кадр SYN+ACK. Детектировав это пакет хакер посылает серверу кадр ACK. При этом сервер переходит в состояние established. Клиент перешел в это состояние при получении от сервера первого кадра SYN+ACK. На Рисунок 6.2 не показан обмен пакетами ACK, вызванными получением некорректных значений ISN. Как сервер так и клиент находятся в несинхронизованном состоянии established. Обмен здесь полностью контролируется атакующей ЭВМ
Рисунок 4.3.6.2 Иерархия мультиплексирования SDH
На Рисунок 4.3.6.2 отображена иерархия мультиплексирования потоков информации в SDH. На рисунке не показана возможность вложения контейнера VC-11 в TU-12. SDH-сигнал состоит из STM-1 кадров (synchronous transport module уровень 1; Рисунок 4.3.6.3). Этот сигнал обеспечивает интерфейс для обмена со скоростью 155.52 Мбит/c, что является базовым блоком, из которого строятся интерфейсы с более высоким быстродействием. Для более высоких скоростей может быть использовано n STM-1 кадров с перекрытием байтов (byte interleave, см. Рисунок 4.3.6.6). Согласно требованиям CCITT n может принимать значения 1, 4 и 16, предоставляя интерфейс для каналов с полосой 155.52, 622.08 и 2488 Мбит/с. Каждый STM-1 кадр содержит 2430 байтов, передаваемых каждые 125 мксек. Для удобства такой кадр можно отобразить в виде блока, содержащего 9 строк по 270 байт.
Рисунок 4.6.2.10. Иерархия субъектов сертификации
Из списка этих субъектов один является опционным, это GCA (Геополитический центр сертификации - Geo-Political Certificate Authority). Проверка сертификатов производится строго в соответствии с данной иерархической схемой. Доступ к корневому центру сертификации производится крайне редко, только в случае получения нового сертификата платежной системы или при обновлении корневого сертификата. При взаимодействии с ним привлекается в максимально возможной мере аппаратный контроль. Если произойдет раскрытие секретного ключа платежной системы, то RCA сформирует и разошлет новый список отмененных сертификатов CRL (Certificate Revocation List).
BCA являются независимыми для каждой платежной системы и реализуются практически теми же мерами безопасности, как и RCA. Эти центры служат для формирования и рассылки геополитических и/или сертификатов владельцев карты, продавцов или платежных центров, размещенных ниже по иерархии. Они также ответственны за обновление и рассылку списков CRL и BCI, содержащие все CRL платежной системы.
Геополитические центры сертификации (являются опционными) позволяют платежным системам перераспределять ответственность между отдельными географическими и политическими регионами. Эти центры ответственны за формирование и рассылку соответствующих региональных CRL.
Центры сертификации владельцев карт (ССА) формируют по запросу и отсылают сертификаты владельцам платежных карт. Запрос сертификата может быть послан через WEB или по электронной почте. ССА поддерживают взаимоотношения с эмитентами карт для сертификации счетов владельцев карт. ССА также занимаются рассылкой CRL, сформированных RCA, BCA, GCA и центров сертификации платежных центров. Функции CCA может выполнять центр платежной системы, эмитента карты или какой-то иной субъект, который отвечает требованиям конкретной платежной системы.
Центр МСА ответственен за рассылку сертификатов продавцам. Получатели (Acquirers) проверяют и одобряют запросы сертификатов продавца до их выдачи центром MCA.
Рисунок 2.4.1. Иллюстрация функций преобразования сигналов
Дальнейшим усовершенствованием схемы pcm является адаптивный дифференциальный метод кодово-импульсной модуляции (Рисунок 2.4.2). Здесь преобразуется в код не уровень сигнала в момент времени ti, а разница уровней в моменты ti и ti-1. Так как обычно сигнал меняется плавно, что типично для человеческой речи, можно заметно сократить необходимое число разрядов АЦП. Принципиальное отличие между PCM и ADPCM (1984 год) заключается в использовании адаптивного АЦП и дифференциального кодирования, соответственно. Адаптивный АЦП отличается от стандартного PCM-преобразователя тем, что в любой момент времени уровни квантования расположены однородно (а не логарифмически), причем шаг квантования меняется в зависимости от уровня сигнала. Применение адаптивного метода базируется на том, что в человеческой речи последовательные уровни сигнала не являются независимыми. Поэтому, преобразуя и передавая лишь разницу между предсказанием и реальным значением, можно заметно снизить загрузку линии, а также требования к широкополосности канала. Следует иметь в виду, что метод не лишен серьезных недостатков: уровень шумов, связанный с квантованием сигнала, выше; при резких изменениях уровня сигнала, превышающих диапазон АЦП, возможны серьезные искажения.
Информационные сертификатные запросы и обработка статуса
Если сертификат не возвращен немедленно в CertRes, EE может попросить прислать ему информацию о состоянии его запроса путем присылки CertReq в центр СА. Запрос CertInqRes возвращает сертификат, если он готов, или предоставляет информацию о том, когда сертификат будет прислан. Такие запросы могут посылать владелец карты, продавец или расчетный центр. Адресуются эти запросы CA, CCA, MCA или PCA (источникам сертификатов).
Если CertStatusCode из CertRes равен “Certificate Request in Progress” или “Certificate Request Pending”. EE формирует CertInqReq для получения сертификата следующим образом:
Шаг |
Действие |
1 |
Копируется LID-CA3 из CertRes в поле данных “CertInqReqTBS” |
2 |
Генерируется новый RRPID |
3 |
Генерируется новый LID-EE |
4 |
Генерируется новый Chall-EE3 |
5 |
Копируется LID-CA из предыдущего CertRes |
6 |
Подписывается CertInqReqTBS. Устанавливается тип содержимого равным id-set-content-CertInqReqTBS. CertInqReq подписывается также как и CertReq. |
7 |
Формируется цифровой конверт и посылается CertInqReq в центр СА. |
Формат сообщения представлен в таблице ниже.
2.9.1 Используемые стандарты
Для видеоконференций стандартизованы следующие скорости обмена:
112 Кбит/с (64 видео, 48 аудио);
128 Кбит/с (64 видео, 64 - аудио);
128 Кбит/с (96 видео, 32 -аудио);
128 Кбит/с (112 - видео, 16 -аудио);
384 Кбит/с (320 - видео, 64 аудио).
G.711 CCITT рекомендация для импульсно-кодовой модуляции (PCM) голоса с использованием m-закона кодирования при 8 кГц (8000 стробирований в сек)
G.721 CCITT рекомендация для адаптивной дифференциальной импульсно-кодовой модуляции (ADPCM) для кодирования звука с полосой 32 кГц.
G.722 CCITT рекомендация для ADPCM при 64 Кбит/с (7 кГц)
G.723 CCITT рекомендация для ADPCM при 24 Кбит/с
G.728 (CLEP) CCITT рекомендация для ADPCM при 16 Кбит/с (3.1 кГц)
H.221 CCITT рекомендация для структуры кадров аудио-видео каналов при скоростях 64 - 1920 Кбит/с.
H.261 или P*64- CCITT рекомендация для кодирования/декодирования аудио-видео процедур при скоростях p x 64 Кбит/с, где p=1-30, что эквивалентно 64 Кбит/с - 2 Мбит/с. Рекомендации первоначально были разработаны для узкополосного ISDN. Достижимы коэффициенты сжатия от 4:1 до 160:1. Регламентированы форматы:
CIF 352x288 15 кадров/сек.
Quarter CIF (QCIF) 176x144
CIF 704x576
QCIF 352x288
Super CIF 704x576.
H.320 CCITT рекомендации для узкополосных видео-телефонных систем и терминального оборудования со скоростями не более 1920 Кбит/с. Общее описание CODEC.
JPEG - ISO/CCITT рекомендации объединенной группы фотоэкспертов. В рекомендации определен алгоритм сжатия для стационарных цветных изображений, при котором отбрасываются визуально второстепенные детали изображения, убирается избыточность в пределах кадра, в результате обеспечивается сжатие1:30 при потере качества изображения и 1:15 без потери качества.
JPEG для движущегося изображения - стандарт JPEG, адаптированный для отображения движущегося изображения, обеспечивает индивидуальный доступ к кадрам и коэффициент сжатия информации 20:1.
MPEG-1 ISO/CCITT рекомендации группы экспертов по движущемуся изображению, определен алгоритм сжатия для движущегося изображения при работе с каналами 1.5 Мбит/с (1.2 Мбит/с видео + 200 Кбит/с для аудио) с коэффициентами сжатия от 50:1 до 200:1 при размере изображения 352x240x24 бит и частоте кадров 30/сек.
MPEG-2 ISO/CCITT рекомендации группы экспертов по движущемуся изображению, поток данных для видео и аудио лежит в пределах между 4 и 15 Мбит/с, достигаются коэффициенты сжатия от 50:1 до 200:1, размер изображения 728x486, качество соответствует телевидению высокого разрешения стандарта NTSC (National Television Standards Committee US).
Сводные данные по стандартам для видеоконференций представлены в таблице 2.9.1.1. Новым универсальным набором стандартов для реализации видео-телефонии и мультимедийных обменов является H.323.
6.4.3 Электронная подпись
В конце любого письма мы привыкли ставить подпись с тем, чтобы уведомить получателя о том, кто является отправителем данного документа. Кроме того, подпись ответственного лица придает документу юридическую силу. По мере внедрения электронных средств доставки документов (факс и электронная почта) проблема их достоверности обрела крайнюю актуальность. Ведь копирование любой последовательности битов или пикселей не представляет никакой трудности. Современные телекоммуникационные каналы уязвимы для перехвата и искажения пересылаемых документов.
Рассмотрим сначала то, от каких действий злоумышленника должна защищать система идентификации.
Отказ от выполненных действий. Субъект утверждает, что он не посылал некоторый документ, хотя на самом деле он его послал.
Модификация документа. Получатель модифицирует полученный документ и утверждает, что именно такую версию документа он и получил.
Подделка. Субъект фабрикует сообщение и утверждает, что оно ему прислано.
Перехват. Злоумышленник С перехватывает сообщение, посланное А к В с целью модификации.
Маскировка. Посылка сообщения от чужого имени.
Повтор. Злоумышленник С посылает повторно сообщение от А к Б, перехваченное им ранее.
Решение практически всех этих проблем может быть реализовано с помощью электронной подписи, базирующейся на алгоритме RSA. Рассмотрим принципы, на которых базируется электронная подпись.
Пусть имеются секретные коды d, p и q, а также открытые e и n=pq. Пусть также А передает сообщение DATA адресату Б. Электронная подпись отправителя А базируется на его секретном ключе и открытом ключе получателя Б. Сначала отправитель с помощью хэш-функции (SHS - Secure Hash Standard; www.nist.gov/itl/div897/pubs/fip180-1.htp) генерирует дайджест своего сообщения длиной 160 бит (5 слов). Затем с помощью своего секретного ключа он формирует электронную подпись. При этом А не может отказаться от того, что именно он послал сообщение, так как только он знает свой секретный ключ.
Электронную подпись нельзя использовать повторно и подписанный документ нельзя модифицировать, так как любые модификации неизбежно изменят его дайджест, а, следовательно, и электронную подпись. Получатель с помощью открытого ключа дешифрует код электронной подписи, а затем с использованием дайджеста проверяет ее корректность.
Национальный институт стандартов США принял стандарт DSS (Digital Signature Standard; www.itl.nist.gov/div897/pubs/fip198.htm), в основу которого легли алгоритмы Эль-Гамаля и RSA.
Рассмотрим алгоритмы вычисления дайджеста сообщения, электронной подписи и идентификации отправителя. Начнем с алгоритма SHA (Secure Hash Algorithm).
Сначала сообщение разбивается на блоки длиной 512 бит. Если длина сообщения не кратна 512, к последнему блоку приписывается справа 1, после чего он дополняется нулями до 512 бит. В конец последнего блока записывается код длины сообщения. В результате сообщение приобретает вид n 16-разрядных двоичных слов M1,M2,…,Mn. M1 содержит первый символ.
Алгоритм SHA использует 80 логических функций f0,f1,…,f79, которые производят операции над тремя 32-разрядными словами (B,C,D):
ft(B,C,D) = (B AND C) OR ((NOT B) AND D) | для 0 ЈtЈ 19 |
ft(B,C,D) = B XOR C XOR D | для 20 Ј t Ј 39 |
ft(B,C,D) = (B AND C) OR (B AND D) OR (C AND D) | для 40 Ј t Ј 59 |
ft(B,C,D) = B XOR C XOR D | для 60 Ј t Ј 79 |
Kt = 5A827999 | для 0 Ј t Ј 19 |
Kt = 6ED9EBA1 | для 20 Ј t Ј 39 |
Kt = 8F1BBCDC | для 40 Ј t Ј 59 |
Kt = CA62C1D6 | для 60 Ј t Ј 79 |
4.1.13 Коммутируемая мультимегабитная информационная служба SMDS
Коммутируемая мультимегабитная информационная служба SMDS (Switched Multimegabit Data Service; RFC-1209, -1694) создана для объединения большого числа локальных сетей. Система была разработана в 80-е годы и реализована в начале 90-х годов. Система SMDS функционирует как высокоскоростная опорная сеть, транспортирующая пакеты от одной локальной сети к другой. SMDS рассчитана на большие краткосрочные всплески трафика. При N локальных сетях, соединенных выделенными каналами, полносвязная схема их соединения требует N(N-1)/2 каналов (см. Рисунок .1А). Для системы SMDS требуется только N каналов до ближайшего SMDS-маршрутизатора (Рисунок .1В).
2.4 Методы преобразования и передачи звуковых сигналов
Номер раздела | Название раздела | Объем в страницах | Объем в кбайт |
2.4 | Методы преобразования и передачи звуковых сигналов | 6 | 5 |
2.4.1 | Дельта-модуляция | 1 | 1 |
2.4.2 | Кодировщики голоса (Vocoder) | 2 | 2 |
2.4.3 | Передача голоса по каналам Интернет | 4 | 2 |
Модель электронных чеков
Данная модель с хорошей точностью воспроизводит практику применения обычных чеков. Клиент заполняет электронный чек, который представляет собой платежное поручение. Этот чек подписывается электронным образом и передается партнеру (например, продавцу), который предъявляет его банкиру. Банкир проверяет корректность чека, наличие необходимых средств на счете клиента, заполнившего чек, и, если все в порядке, переводит средства на счет продавца. Преимуществом этой модели является простота, легкость разрешения любых споров, а также отсутствие требование выполнения всех операций в реальном масштабе времени. Уровень конфиденциальности здесь также вполне разумен.
Модель электронных монет
Эта схема моделирует традиционную денежную систему. Банкир формирует цифровые сертификаты, называемые монетами, и приобретаемые участниками сделок. Эти сертификаты могут быть банкиром выкуплены. Клиенты используют эти сертификаты (монеты) для расчетов как обычные деньги. Эту модель достаточно трудно реализовать из-за проблемы повторного использования сертификатов для покупок. Есть у этой модели и преимущества, например, плательщик не должен иметь контакт с банкиром в реальном масштабе времени в момент платежа, да и уровень конфиденциальности здесь вполне приемлем.
Модель электронных переводов
Данная модель простейшая из описанных. Плательщик выдает платежное поручение банкиру, снабжая его электронной подписью. Банкир верифицирует платежное поручение, проверяет наличие средств и, если все в порядке, осуществляет перевод денег. Операция со стороны плательщика выполняется в реальном масштабе времени. Эта модель прозрачна, получатель перевода не должен быть доступен в реальном масштабе времени. Схема хороша для начисления зарплаты, но совершенно не приемлема для торговли через Интернет.
Теперь рассмотрим требования к безопасности платежной системы. В случае работы через Интернет эти требования должны быть достаточно жестки, так как сами транспортные протоколы TCP/IP практически не предоставляют сколько-нибудь существенной защиты.
Никто кроме владельца счета не может иметь к нему доступа, и никто не должен иметь возможности имитировать работу владельца счета.
Плательщик должен иметь возможность доказать третьей стороне, что платеж произведен и предоставить данные о предмете платежа. Это необходимо в случае конфликта, когда клиент либо не получил оплаченный товар, либо, например, не удовлетворен его качеством. Здесь нужно учитывать возможность случайного или преднамеренного искажения сообщений при их передаче.
Получатель платежа должен иметь возможность доказать третей стороне, какую сумму, когда, за что и от кого он получил. Это нужно для разрешения возможных конфликтов с клиентом.
Банкир должен иметь возможность доказать третьей стороне, что он при работе со счетами строго следовал платежным поручениям. Это позволит ему отвести обвинения в осуществлении неавторизованных платежных операций.
Плательщик должен быть уверен, что платеж будет осуществлен именно тому продавцу товара или услуг, кому он хотел. Это подразумевает иммунитет системы против преднамеренных искажений платежных сообщений.
Система должна противостоять фальсификации расписок банкира.
Все возможные конфликты между банкиром и его клиентами должны разрешаться с помощью анализа сообщений, снабженных электронными подписями.
Этап | Действие |
1 | Владелец карты просматривает позиции каталога продавца: В реальном масштабе времени на WEB-сервере На CD-диске на своей рабочей станции Читая бумажную версию каталога Через поисковую систему посредника |
2 | Владелец карты выбирает понравившийся товар или услугу. |
3 | Владельцу карты предоставляется форма заказа, содержащая список позиций, их цены, стоимости доставки, уровни платежей по налогам, возможные скидки и т.д. Такая форма может быть доставлена по сети с сервера продавца или сформирована торговой программой владельца карты. Иногда продавцы предоставляют возможность согласования цены продукта (например, предъявляя карту постоянного покупателя или предоставляя цены конкурентов). |
4 | Владелец карты выбирает средство платежа. SET предполагает применение различных кредитных и платежных карт. |
5 | Владелец карты посылает продавцу заполненную форму заказа и платежные инструкции. В данной спецификации предполагается, что заказ и инструкции подписываются владельцем карты электронным образом с привлечением имеющихся в его распоряжении сертификатов. |
6 | Продавец запрашивает платежную авторизацию от эмитента карты. |
7 | Продавец посылает подтверждение заказа. |
8 | Продавец доставляет заказанный товар или услугу |
9 | Продавец посылает запрос на оплату товара или услуги финансовой организации владельца карты. |
10.23 Модель машины конечных состояний
Машина состояний протокола может быть охарактеризована с помощью ориентированного графа, в котором число узлов равно числу конечных состояний системы, а число ребер всей совокупности возможных переходов из одного состояния в другое. Одно из состояний выбирается в качестве исходного. Из этого состояния система может попасть в некоторые (все) другие состояния с помощью последовательности переходов. Данный подход позволяет часто выявить слабые места протокола (например, возможности "повисаний").
Машина конечных состояний протокола характеризуется следующими наборами переменных
S | Набор состояний процессов и канала |
M | Набор кадров, которые могут быть переданы по каналу |
I | Набор исходных состояний процессов |
T | Набор переходов между состояниями |
Обработка информационных запросов
Пара сообщений InqReq/InqRes позволяет владельцу карты получать информацию о состоянии транзакции. Информационный запрос может быть послан в любое время после запроса PReq, адресованного продавцу. Запросы InqReq могут посылаться многократно. Отклик InqRes имеет тот же формат, что и PRes. Продавец должен проверять, что сертификат, сопровождающий InqRes, соответствует сертификату, использованному с PRes. Это препятствует запросам одного владельца карты о состоянии транзакций других покупок. Владелец карты без сертификатов не подписывает информационные запросы, что означает возможность нарушения целостности сообщения. Владелец карты формирует запрос InqReq следующим образом.
Шаг |
Действие |
1 |
Копируется InqReqData из предыдущего запроса Формируется новый RRPID Генерируется новый Chall-С Опционно добавляются любые InqReqExtensions |
2 |
Если владелец карты послал подписанный PReq, вставить Compose SignedData c InqReqData |
3 |
Вставить сообщение в цифровой конверт и послать продавцу |
Структура данных запроса InqReq представлена в таблице 4.6.2.63.
Обработка ошибок
Каждому сообщению-запросу должно соответствовать сообщение-отклик. Сообщения об ошибках могут соответствовать как запросам, так и откликам. Сообщение об ошибке указывает, что приславший его не смог разобрать формат полученного запроса или отклика, или при обработке потерпели неудачу верификационные тесты. Не следует путать отрицательный отклик с сообщением об ошибке. Сообщение об ошибке посылается при невозможности обработать входное сообщение. Сообщение Error не посылается, например, при непрохождении аутентификации. Причиной сигнала ошибки может быть искажение пакета при транспортировке по локальной сети или через Интернет, нелегальные значения полей сообщения или протокольные искажения.
Для выявления сообщений-дубликатов достаточно использовать открытый текст, содержащийся в цифровом конверте сообщения. Реакция получателя на сообщение-дубликат зависит от свойств идемпотентности конкретного типа сообщения, от числа дубликатов, частоты их поступления и от того, кто является их отправителем.
Поврежденным сообщением считается такое, которое не может быть обработано. В норме такие сообщения не должны приходить, так как имеется контроль корректности пакетов на транспортном уровне и при обнаружении любых повреждений сообщение должно быть переслано повторно. Но если такое “невозможное событие” все-таки произойдет, будет послано сообщение Error, содержащие код типа ошибки и идентификатор сообщения, ее вызвавшего. Приложение никогда не посылает сообщение Error в ответ на другое сообщение Error. Сообщения, которые не являются протокольными для SET, просто игнорируются.
Если тэг типа сообщения равен 999 (указывая, что это сообщение об ошибке), приложение SET не должно ни при каких обстоятельствах посылать на него отклик. Когда приложение сталкивается с ошибкой, оно формирует Error-сообщение в следующей последовательности.
Шаг | Действие | |
1 | Сформировать ErrorTBC следующим образом:
Установить ErrorCode равным значению, указывающему на причину (см. табл. 4.6.2.16) Сформировать новый ErrorNonce Если ошибка случилась из-за того, что приложение не знает, как обрабатывать расширение сертификата или сообщения, занести в ErrorOID объектный идентификатор расширения. Если ошибка произошла из-за проблем с сертификатом, занести в ErrorThamb ThumbPrint сертификата Если ошибка является результатом неудачной верификации подписи, занести в ErrorThamb хэш сертификата ErrorMsg формируется следующим образом: заносится MessageHandler или все сообщение (но не более 20 килобайт). Выбор того, следует ли заносить все сообщение или только заголовок, оставляется на усмотрение разработчика. | |
2 | Подписать сообщение Error, если имеется сертификат подписи | |
3 | Вызвать формирование цифрового конверта и отправить сообщение |
Имя поля | Описание |
Error | <Signed Error, UnsignedError > |
SignedError | S(EE, ErrorTBS) |
UnsignedError | ErrorTBS Неподписанная версия Error будет использоваться, если объект не имеет сертификата подписи |
ErrorTBS |
{ ErrorCode, ErrorNonce, [ErrorOID], [ErrorThumb], ErrorMsg} |
ErrorCode |
Цифровой код, определяющий условия ошибки (см. табл. 4.6.2.16) |
ErrorNonce |
Разовый код, который гарантирует, что подпись генерируется для трудно предсказуемых данных |
ErrorOID |
Объектный идентификатор неподдерживаемых критических расширений, вызвавших ошибку |
ErrorThumb |
Оттиск сертификата, который вызвал ошибку или хэш сертификата, если произошла ошибка верификации подписи |
ErrorMsg |
<MessageHeader, BadWrapper> |
MessageHeader |
Заголовок сообщения, которое вызвало ошибку |
BadWrapper |
Цифровой конверт сообщения, которое вызвало ошибку (не более 20 килобайт) |
Рисунок 4.6.2.18. Обработка платежных запросов
После завершения обработки заказа владельца карты продавец осуществляет запрос платежа. Между запросами авторизации и запросом платежа может быть достаточно большая задержка.
Программа продавца генерирует платежный запрос, снабженный цифровой подписью. Этот запрос содержит итоговую сумму транзакции, ее идентификатор из OI и другую информацию о транзакции. Запрос шифруется с использованием вновь сформированного симметричного ключа, который в свою очередь шифруется с привлечением общедоступного ключа расчетного центра. Запрос платежа и опционно платежный маркер (capture token), если таковой был включен в авторизационный отклик, пересылаются в расчетный центр. В общем случае в одном сообщении может быть заключено несколько платежных запросов.
Когда расчетный центр получает запрос платежа, он дешифрует цифровой конверт, извлекает из него симметричный ключ и дешифрует с его помощью текст платежного запроса. Далее посредством общедоступного ключа продавца верифицируется его цифровая подпись. Расчетный центр дешифрует платежный маркер (если таковой имеется) и использует платежный запрос и маркер для формирования клирингового запроса, который направляется эмитенту карты через платежную систему кредитной карты.
После этого расчетный центр генерирует платежный отклик, снабженный цифровой подписью. Этот отклик содержит в себе копию сертификата подписи расчетного центра. Отклик шифруется с использованием нового симметричного ключа и переправляется продавцу.
Когда продавец получает платежный отклик из расчетного центра (РЦ), он дешифрует цифровой конверт, извлекает из него симметричный ключ и с его помощью дешифрует полученный текст отклика. Далее верифицируется сертификат подписи расчетного центра и цифровая подпись РЦ. Продавец запоминает платежный отклик для последующего использования при контроле платежей, поступающих из его банка.
Пары запросов CapReq/CapRes предоставляют механизм завершения ранее авторизованного денежного платежа.
Размер платежа определяется на фазе обмена авторизационными сообщениями. Продавец не должен посылать запрос CapReq для ранее успешно прошедших платежей. Возможно осуществление платежей с помощью пар сообщений, выходящих за пределы протокола SET. Формирование запроса CapReq продавцом осуществляется следующим образом.
Шаг | Действие |
1 | Заполнить поле CapRRTags |
2 | Опционно заполнить поля AuthReqData и AuthResPayload. Процедура опускается, если информация содержится в CapToken |
3 | Рекомендуется заполнить MThumbs всех сертификатов для расчетного центра, куда посылается это сообщение, для CRL и для BrandCRLIdentifier |
4 | Заполнить один или более CapItem в CapSeq следующим образом. Для каждого CapItem: Заполнить TransIDs и AuthRRPID платежной позиций предшествующих сообщений в каждой транзакции. Заполнить CapPayload Заполнить SaleDetail, как это требует политика платежной системы карты. Если CapToken нет, или отсутствует авторизация в расчетном центре, копировать CapTokenItem из соответствующего AuthReqItem запроса AuthReq и из AuthResPayload отклика AuthRes |
5 | Заполнить CapTokSeq с помощью CapToken из соответствующих сообщений AuthRes, полностью тождественных с CapItem в CapSeq. Если CapToken для транзакции отсутствует, заносится нуль. |
6 | В дополнительные позиции инкапсуляции EncBX заносятся PANToken, если продавец получил PANToken |
7 | Опционно заполняется CRqExtensions |
8 | Если включено PANToken, использовать EncBХ-инкапсуляцию |
9 | Если PANToken не включено, использовать EncB-инкапсуляцию |
10 | Вложить сообщение в цифровой конверт и послать владельцу карты |
Шаг | Действие |
1 | Занести в поле CapDate текущее значение даты |
2 | Занести в CapReqAmt сумму выплаты |
3 | Скопировать AuthResPayload из соответствующего AuthRes |
4 | Опционно заполнить CPayExtensions |
Обработка сообщений
Базовыми процедурами протокола SET является посылка и прием сообщений. Процесс отправки сообщения представлен в таблице 4.6.2.4.
Обработка заказа-покупки
Обмен запрос-отклик (PReq/PRes) представляет собой реализацию покупки, выполняемой владельцем карты у продавца. Данные сообщения составляют ядро протокола купли-продажи. На долю владельца карты выпадает функция платежа.
Реализация запроса покупки проходит через 5 этапов (см. Рисунок 4.6.2.16).
Рисунок 4.6.2.16. Обработка запроса покупки
Прежде чем послать запрос покупки покупатель (владелец карты) должен заполнить форму заказа, одобрить условия сделки и выбрать платежную карту. Для того чтобы послать запрос продавцу, владелец карты должен иметь копию ключей расчетного центра. Обработка заказа начинается, когда программа владельца карты запрашивает копию сертификата расчетного центра. В этом сообщении содержится информация о выборе платежной системы. Когда продавец получает запрос, он присваивает транзакции уникальный идентификатор. После этого продавец пересылает свой сертификат и сертификат расчетного центра вместе с этим идентификатором владельцу карты. Программа владельца карты верифицирует полученные сертификаты и запоминает их для использования в последующей обработке заказов. Приложение владельца карты формирует данные заказа OI (Order Information) и платежные инструкции PI. OI и PI снабжаются идентификатором транзакции, для того чтобы расчетный центр мог связать их вместе при авторизации запроса продавца. Заметим, что OI не содержит таких данных как описание товара или условий поставки. Эта информация получается на фазе сделки, предшествующей операциям SET (например, в рамках протокола IOTP).
Программное обеспечение владельца карты генерирует двойную цифровую подпись для OI и PI путем вычисления дайджеста для обоих модулей данных, объединения этих дайджестов, вычисления дайджеста результата и осуществления подписи этого сообщения с привлечением секретного ключа владельца карты. Дайджесты OI и PI посылаются вместе с этим сообщением. Далее программа формирует симметричный ключ и использует его для шифрования дважды подписанных PI. Затем программа шифрует номер счета владельца карты и симметричный ключ с привлечением общедоступного ключа расчетного центра. Результат составляет цифровой конверт сообщения, которое передается продавцу.
Когда программа продавца получает заказ, она верифицирует сертификат подписи владельца карты, используя общедоступный ключ владельца карты и дайджест PI (заключенный в OI), проверяет цифровую подпись, чтобы убедиться в не искаженности заказа и в том, что сообщение подписано секретным ключом владельца карты.
Заметим, что продавцу не обязательно выполнять авторизацию до посылки отклика владельцу карты. Последний может позднее определить, была ли выполнена авторизация, послав информационный статусный запрос. После обработки OI продавец генерирует отклик и снабжает его цифровой подписью. Этот отклик содержит в себе сертификат подписи продавца и указывает на факт получения заказа от владельца карты. Если отклик авторизации указывает на одобрение транзакции, продавец поставляет товар или услугу, указанные в заказе.
Когда приложение владельца карты получает отклик на запрос покупки от продавца, сначала верифицируется сертификат подписи. Далее проверяется цифровая подпись продавца. При благоприятном исходе этих проверок выдается соответствующее сообщение и производится запись в базу данных. Состояние выполнения заказа владелец карты может выяснить путем посылки информационных статусных запросов.
Сообщение PReq не обязательно следует за сообщениями PInitReq/PInitRes. Сообщение же PRes может быть прислано до выполнения авторизации и оплаты. Если владелец карты обладает сертификатом, то для обеспечения целосности и аутентичности сообщения выполняется двойная подпись.
PReq представляет собой наиболее сложное сообщение в протоколе. Оно состоит из двух частей: инструкции-заказа OI (Order Instruction) для продавца и платежной инструкции PI (Payment Instruction), которая проходит транзитом через продавца в расчетный центр. Эти две части принципиально должны подписываться независимо. Продавец получает описание заказа OD (Order Description) и PurchAmt. В PI включаются хэши OD и PurchAmt (HODINput). Расчетный центр проверяет, что хэш передан покупателем (владельцем карты) через продавца и равен хэшу, выданному продавцом в AuthReq. Некоторые владельцы карт могут не иметь сертификатов. Сообщения от таких владельцев не будут подписаны, вместо этого PIHead связывается с OIData. Целостность таких сообщений обеспечивается следующими мерами:
C PI используется OAEP
В блок OAEP включается H(PIHead) (вместе с PANData)
С PIHead используется H(OIData)
Расчетным центром производится сравнение H(OIData), присланного продавцом, с H(OIData) из PIHead.
Владелец карты формирует сообщение PReq следующим образом (эти действия предпринимаются как для PReqUnsigned так и для PreqDualSigned).
Шаг | Действие | |
1 | Извлечь PurchAmt и OD | |
2 | Сформировать OIData следующим образом: | |
a) | Если имел место обмен PInitReq/ PInitRes: | Скопировать TransIDs из PInitRes |
В противном случае: | Для формирования TransIDs владелец карты сгенерирует PreqDate (текущие дата/время), LID-C и XID | |
b) | Сформировать новый RRPID, запомнить его значение для сверки с откликом продавца | |
Если имел место обмен PInitReq/PInitRes: | Скопировать Chall-c из PInitRes | |
В противном случае: | Сформировать новый Chall-C | |
c) | Сформировать новый ODSalt | |
d) | Сформировать HODInput посредством следующей процедуры: Скопировать OD из данных процесса инициализации SET Записать PurchAmt cо значением, одобренным владельцем карты на фазе инициации SET. Скопировать ODSalt из пункта 2 с) Если владелец карты намерен выполнить инсталляцию или последовательные платежи, то записать InstallRecurData Опционно: добавить любые ODExtensions | |
e) | Сформировать HOD с HODInput из пункта 2 d | |
f) | Если имел место обмен PInitReq/ PInitRes: | Скопировать Chall-M из PInitRes и не заполнять BrandID |
В противном случае: | Не заполнять Chall-M Записать BrandID, указав предпочтительный тип карты | |
g) | Произвести записьв поле BIN с HODInput из пункта 2d | |
h) | Если HODInput из шага 2.d имеет какие-то расширения OIExtensions, внести ODExtOIDs со всеми OID в ODExtensions. ODExtOIDs будут перечислены в том же порядке, что и расширения ODExtensions, таким образом продавец сможет вычислить тот же самый хэш | |
i) | Опционно: добавить любые расширения OIExtensions. | |
3 | Сформировать PIHead следующим образом: | |
a) | Скопировать TransIDs, вычисленные в пункте 2.а | |
b) | Сгенерировать Inputs согласно процедуре: Скопировать HOD из пункта 2.е Скопировать PurchAmt из шага 2.d.2 | |
c) | Скопировать MerchandID из сертификата продавца в PInitRes, или из CD-ROM-каталога | |
d) | Скопировать InstallRecurData из пункта 2.d.4 (если имеется) | |
e) | Сформировать TransStain, как HMAC, используя XID в качестве данных и CardSecret - в качестве ключа. Если владелец карты не имеет сертификата, использовать CardSecret, заполненный нулями. | |
f) | Записать SWIdent, который получен из локальных данных. Это значение будет соответствовать коду в цифровом конверте сообщения | |
g) | Если присутствует туннельное расширение Cert_PE, сформировать AcqBackInfo следующим образом: Найти туннельное расширение для алгоритма шифрования, приемлемое для владельца карты. Если такое найдено, заполнить AcqBackAlg, в противном случае, не формировать AcqBackInfo и перейти к пункту f. Сформировать новый AcqBackKey (приемлемый для AcqBackAlg) | |
h) | Опционно добавить любые PIExtensions | |
4 | Сформировать PANData | |
5 | Сгенерировать PU-OIData c L-оператором, используя PIHead из пункта 3 (параметр t1) и OIData из пункта 2 (параметр t2) | |
6 | Используя результат пунктов 2, 3 и 4, сгенерировать PreqDualSigned, если владелец карты имеет сертификат или PreqUnsigned, если сертификата нет. |
Шаг | Действие |
1 | Сформировать PISignature: Сформировать PI-TBS: Сгенерировать HPIData в виде дайджеста PIData Сгенерировать HOIData в виде дайджеста OIData Выполнить PISinature c оператором S0, используя сертификат владельца карты (параметр s) и PI-TBS (параметр t). |
2 | Применить оператор EX, используя общедоступный ключ расчетного центра (параметр r), PI-OILink от владельца карты создает PReq шаг 5 (параметр t), а PANData от владельца карты создает PReq шаг 4 (параметр p) |
3 | Образовать PIDualSigned как объединение подписи PISignature, вычисленной в пункте 1, и шифрованных данных, полученных на шаге 2. |
4 | Генерируем PIData как объединение HIHead из PReq владельца карты, (см. пункт 3 предшествующей таблицы), и PANData владельца карты, которая создается в пункте 4 при формировании PReq (см. предшеств. табл.). |
5 | Генерируем OIDualSigned, посредством оператора L, используя OIData от владельца карты, создаем PReq - пункт 2 (параметр t1) и данные PIData, полученные в пункте 4 (параметр t2) |
6 | Генерируем PReqDualSigned как объединение PIDualSigned из пункта 3 и OIDualSigned из пункта 5. |
Обработка запросов/откликов инициализации платежа
Процедура инициализации платежа включает в себя обмен двумя сообщениями. Первоначальный запрос PInitReq посылает владелец карты, отклик PInitRes ему присылает продавец. Задачей этого обмена является получение владельцем карты сертификатов и CRL. Без такого обмена данная информация может быть получена и каким-то другим образом, например с CD-ROM. Эти сообщения посылаются после инициализации процесса SET. Сообщение-запрос PInitReq идентифицирует платежную систему карты (Brand), предоставляет локальный идентификатор владельца карты для данной транзакции, посылает переменную вызова для определения пригодности (свежести) сообщения-отклика. В этом сообщении передается также набор оттисков, который идентифицирует соответствующие сертификаты и CRL, уже имеющиеся у владельца карты, чтобы их не нужно было посылать еще раз.
Сообщение-отклик PInitRes содержит запрошенные данные, включая сертификаты и CRL. Присылается продавцом также дата, XID и вызов владельца карты, добавляется, кроме того, и вызов продавца. Алгоритм формирования владельцем карты сообщения PInitReq приведен в таблице ниже.
Шаг |
Действие |
1 |
Сформировать RRPID для идентификации сообщения и установления соответствия между запросом и откликом |
2 |
Занести в поле Language, значение которое выбрал владелец карты для данной транзакции |
3 |
Сформировать идентификатор LID-C, который является идентификатором пары сообщений, так как XID еще не присвоен. Этому полю могут присваиваться числа натурального ряда или случайные коды. |
4 |
Если продавец при инициации SET-процесса предоставил код LID-M, скопировать его в сообщение. |
5 |
Сформировать новый код Chall-C |
6 |
На основе выбранной формы платежа заполнить BrandID (из программы-магазина или из программы инициализации SET). |
7 |
Заполнить поле BIN (первые 6 цифр номера счета владельца карты) |
8 |
Опционно. Заполнить оттиски для сертификатов, CRL и BrandCRLIdentifier, имеющиеся у владельца карты. Сюда должен входить корневой сертификат. |
9 |
Записать в базу данных транзакций RRPID, LID-C, LID-M (если имеется), Chall-C и оттиски (если имеются). |
10 |
Опционно. Заполнить любые расширения PInitReq. |
11 |
Занести все это в цифровой конверт и послать продавцу |
Сообщение PInitReq, задавая естественный язык владельца карты, определяет ID и контекст транзакции, а также спецификацию платежной системы. Кроме того, предоставляются оттиски, где записаны сертификаты и криптографические вызовы, гарантирующие новизну отклика. Структура PInitReq представлена в таблице 4.6.2.55.
Рисунок 4.6.2.15. Опции обмена сообщениями при покупке
Основной протокол
Далее рассматривается протокол и обработка откликов владельца карты, продавца или платежного центра (конечный объект – EE), а также получение подписей и/или сертификатов Х.509 шифрования данных от СА (Certificate Authority). Протокол определяет процедуры получения первого сертификата или обновления предшествующего.
Прежде чем запросить сертификат владелец карты должен выполнить следующее:
Получить счет в одной из платежных систем, например, в VISA или MasterCard.
Иметь возможность формировать общедоступный и секретные ключи. Обеспечить безопасное хранение секретного ключа. Понятно, что местом его хранения не может быть оперативная память, да и дисковые накопители вряд ли можно считать приемлемым местом записи, если хотя бы теоретически к ним может быть получен доступ.
Программа владельца карты должна иметь определенную информацию, которая может быть использована для идентификации и аутентификации владельца карты. Это должно быть сделано в соответствии с требованиями эмитента карты.
Иметь URL или электронный почтовый адрес для связи с ССА.
Обзавестись прикладной программой (например, броузером), поддерживающей протокол SET.
Продавец должен иметь следующее, прежде чем посылать запрос сертификата:
Идентификатор, присланный получателем (Acquirer – банк продавца)
Иметь возможность формировать общедоступный и секретные ключи. Обеспечить безопасное хранение секретного ключа.
Программа продавца должна иметь определенную информацию, объем и характер которой согласуется с банком продавца.
URL или электронный почтовый адрес для связи с MCA.
Обзавестись прикладной программой (например, броузером), поддерживающей протокол SET.
Расчетный центр должен обзавестись следующим, прежде чем посылать запрос сертификата:
Возможностью формировать пары ключей (секретый/общедоступный) и местом их надежного храниения.
Получить банковский идентификационный номер BIN (Bank ID)
Программа владельца карты должна иметь определенную информацию, которая может быть использована для идентификации и аутентификации платежного центра.
Объем и характер этой информации согласуется с банком продавца.
Иметь URL или электронный почтовый адрес для связи с PCA
Обзавестись прикладной программой (например, броузером), поддерживающей протокол SET.
После того как приложение запущено, стартуют сертификационные обмены между владельцем карты и CCA, между продавцом и MCA, а также между платежным центром и PCA. В результате участники получают необходимые сертификаты подписи и шифрования. Так взаимодействие владельца карты и ССА предполагает следующие обмены:
Приложение владельца карты посылает CardCInitReq CCA. При этом используется идентификатор платежной системы или идентификатор, полученный из стартового сообщения.
ССА посылает приложению SET сообщение CardCInitRes.
Приложение владельца карты посылает ССА сообщение RegFormReq.
ССА отправляет сообщение RegFormRes, содержащее регистрационную форму и формулировку общих требований.
Приложение владельца карты заполняет регистрационную форму, заносит свой общедоступный ключ и сертификат, подлежащий обновлению (если имеется) в CertReq и посылает его ССА.
ССА формирует сертификат, включает его в CertRes и посылает владельцу карты.
Функционирование приложения продавца и платежного центра имеет свою специфику:
Приложение SET посылает сертификационному центру СА сообщение Me-AqCInitReq, при этом используется BIN и идентификатор продавца, полученные от системного администратора продавца или платежного центра.
СА посылает приложению SET сообщение Me-AqCInitRes, содержащее регистрационную форму и формулировку общих требований.
Приложение SET отображает эту форму и требования. Пользователь должен заполнить регистрационную форму и согласиться с предлагаемыми требованиями.
Приложение SET включает в CertReq заполненную форму, новый общедоступный ключ и сертификат, подлежащий обновлению (если он имеется) и посылает это все СА.
СА формирует сертификат, включает его в CertRes и посылает продавцу или платежному центру.
Схемы таких обменов для получения нового или обновления старого сертификатов представлены на Рисунок 4.6.2.12 и 4.6.2.13.Логика обменов для получения сертификата владельцем карты при начальной регистрации была показана на рис 4.6.2.12.
Рисунок 4.3.6.1. pdh-мультиплесирование
SDH-иерархия распространяется до 2500 Мбит/с и может быть расширена вплоть до 13 Гбит/с (ограничение оптического кабеля). SDH предоставляет существенно улучшенную схему мультиплексирования каналов для быстродействующих интерфейсов с полосой 150 Мбит/с и выше:
обеспечивается единый стандарт для мультиплексирования и межсетевого соединения;
прямой доступ к низкоскоростным каналам без необходимости полного демультиплексирования сигнала;
простая схема управления сетью;
возможность использования новых протоколов, по мере их появления (напр. atm)
При передаче по сети SDH информация вкладывается в специальные структуры, называемые виртуальными контейнерами (VC). Эти контейнеры состоят из двух частей:
Собственно контейнер (C), где лежит передаваемая информация;
Заголовок (path overhead - POH), который содержит вспомогательную информацию о канале, управляющую информацию, связанную с маршрутом передачи.
Описано несколько типов виртуальных контейнеров для использования в различных каналах.
4.5.8 Поиск узлов и людей
Номер раздела | Название раздела | Объем в страницах | Объем в кбайт |
4.5.8 | Поиск узлов и людей | 1 | 3 |
4.5.8.1 | Whois | 5 | 31 |
4.5.8.2 | FRED | 4 | 22 |
4.5.8.3 | X500 | 5 | 20 |
4.5.8.4 | Система поиска NETFIND | 5 | 22 |
Получение BCI
BrandCRLIdentifier (BCI) является списком текущих CRL, соответствующим всем СА из зоны ответственности платежной системы (Brand). Центр сертификации платежной системы отвечает за поддержку, корректность и актуальность BCI. Каждый CA из зоны ответственности платежной системы отвечает за обновление и осуществление доступа к BCI и соответствующим спискам CRL. Эту информацию они выдают в виде откликов на запросы ЕЕ или нижестоящих СА.
Центр сертификации каждой платежной системы формирует и поддерживает свой BCI и реализует механизм для рассылки этой информации. СА, например, расчетного центра должен организовать ежедневное обновление этих данных.
Центр сертификации платежной системы рассылает информацию о новых CRL в виде сообщений BCI Distribution. Это сообщение является подписанным, содержащим текущую дату, BCI, соответствующие сертификаты и CRL. Сообщение BCI Distribution
не формируется ежедневно, а лишь по мере необходимости. Алгоритм формирования этого сообщения представлен ниже.
Шаг | Действие | |
1 | Заполнить BCIDistributionTBS: Ввести текущую дату Включить последнюю версию BCI | |
2 | Подписать содержимое, используя сертификат подписи центра сертификации платежной системы. Установить contenttype равным id-set-content-BCIDistributionTBS. В CRL секцию SignedData ввести все CRL, перечисленные в BCI. В сертификатную часть вставить все сертификаты, необходимые для верификации всех CRL. | |
3 | Закодировать и вложить в цифровой конверт подписанное сообщение BCIDistribution в форме, согласованной с транспортным механизмом. |
Сообщение BCI Distribution содержит в себе следующие поля:
Название поля | Описание |
BCIDistribution |
S(CA, BCIDistributionTBS) |
BCIDistributionResTBS |
{Date, BCIDistribution} |
Дата |
Дата формирования сообщения |
BrandCRLIdentifier |
Список текущих CRL для всех СА в зоне ответственности центра сертификации платежной системы и корневого СА. Сообщение подписывается сертификационным центром платежной системы. |
Обработка пришедшего сообщения BCIDistribution соответствующим СА производится согласно алгоритму, приведенному ниже:
Шаг | Действие |
1 | Извлечь BCIDistribution из транспортного сообщения. Проверить подпись сообщения, используя сертификат подписи СА платежной системы. |
2 | Если дата относится к моменту времени раньше, чем та, что в предыдущем сообщении BCIDistribution, сообщение следует выбросить. |
3 | Если BrandCRLIdentifier отличается от текущего, проверить подпись каждого CRL из BCI. Если подпись некорректна или список CRL из перечня BCI не включен в сообщение, оно отбрасывается. |
4 | Запомнить все CRL и BrandCRLIdentifier для последующей рассылки |
Поток платежных сообщений
Основу потока платежных сообщений SET составляют пары запрос/отклик, следующие между владельцем карты и продавцом, а также между продавцом и расчетным центром. Основу обмена между владельцем карты и продавцом составляют сообщения PReq/PRes. Сообщение PRes может быть прислано немедленно или спустя некоторое время. Присылаемая информация зависит от фазы реализации протокола, в которой находится система.
Авторизация продавца в расчетном центре выполняется с помощью сообщений AuthReq/AuthRes.
На Рисунок 4.6.2.14 показан типичный пример обмена сообщениями при реализации протокола покупки.
Приложение A. ASN.1 синтаксис сертификатов
Сертификаты используются SSL для аутентификации серверов и клиентов. SSL Сертификаты базируются в основном на X.509 [3]. Сертификат X.509 содержит следующую информацию (в нотации ASN.1 [1]):
X.509-Certificate ::= SEQUENCE { certificateInfo CertificateInfo,
signatureAlgorithm AlgorithmIdentifier, signature BIT STRING }
CertificateInfo ::= SEQUENCE { version [0] Version DEFAULT v1988,
serialNumber CertificateSerialNumber, signature AlgorithmIdentifier,
issuer Name, validity Validity, subject Name,
subjectPublicKeyInfo SubjectPublicKeyInfo }
Version ::= INTEGER { v1988(0) }
CertificateSerialNumber ::= INTEGER
Validity ::= SEQUENCE { notBefore UTCTime, notAfter UTCTime }
SubjectPublicKeyInfo ::= SEQUENCE { algorithm AlgorithmIdentifier,
subjectPublicKey BIT STRING }
AlgorithmIdentifier ::= SEQUENCE { algorithm OBJECT IDENTIFIER,
parameters ANY DEFINED BY ALGORITHM OPTIONAL }
Для целей SSL наложены ограничения на некоторые значения полей X.509:
Поля X.509-Certificate::signatureAlgorithm и CertificateInfo::signature должны иметь идентичные значения.
Имя эмитента сертификата должно преобразовываться в имя, которое приемлемо для приложения, использующего SSL.
Сертификаты верифицируются в несколько шагов. Во-первых, проверяется подпись сертификата и, если она некорректна, некорректен и сертификат (произошла транспортная ошибка или попытка модификации). Далее верифицируется поле CertificateInfo::issuer. Там должна быть ссылка на эмитента, которому приложение доверяет. Поле CertificateInfo::validity проверяется на текущую дату и верифицируется.
Наконец, проверяется поле CertificateInfo::subject. Эта проверка опционна и зависит от уровня доверия, необходимого приложению, которое использует SSL.
Приложение B. Идентификаторы объектов и типов атрибутов
SSL использует субнабор X.520 типов атрибутов, а также несколько специфических идентификаторов объектов. Будущие модификации протокола SSL смогут поддерживать больше типов атрибутов и больше идентификаторов объектов.
commonName { attributeType 3 } |
Общее имя, содержащееся в поле эмитента сертификата или субъекта сертификата. |
countryName { attributeType 6 } | Название страны. |
localityName { attributeType 7 } | Название местоположения. |
stateOrProvinceName { attributeType 8 } | Название штата или провинции. |
organizationName { attributeType 10 } | Название организации. |
organizationalUnitName { attributeType 11 } | Название подразделения. |
[1] | CCITT. Recommendation X.208: "Specification of Abstract Syntax Notation One (ASN.1). 1988. |
[2] | CCITT. Recommendation X.209: "Specification of Basic Encoding Rules for Abstract Syntax Notation One (ASN.1). 1988. |
[3] | CCITT. Recommendation X.509: "The Directory - Authentication Framework". 1988. |
[4] | CCITT. Recommendation X.520: "The Directory - Selected Attribute Types". 1988. |
[5] | RSA Laboratories. PKCS #1: RSA Encryption Standard, Version 1.5, November 1993. |
[6] | RSA Laboratories. PKCS #6: Extended-Certificate Syntax Standard, Version 1.5, November 1993. |
[7] | R. Rivest. RFC 1321: The MD5 Message Digest Algorithm. April 1992. |
[8] | R. Rivest. RFC 1319: The MD2 Message Digest Algorithm. April 1992. |
[9] | B. Schneier. Applied Cryptography: Protocols, Algorithms, и Source Code in C, Published by John Wiley & Sons, Inc. 1994. |
[10] | M. Abadi и R. Needham. Prudent engineering practice for cryptographic protocols. 1994. |