А (продолжение)

Рисунок 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).

ADPCM-преобразователь голоса в код для кбит/с

Рисунок 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-файлы.

Алгоритм работы SSL

Рисунок 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).

Алгоритм шифрования SAFER

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

AmtExp) Значение может быть как

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	Поместить сообщение в цифровой конверт и отправить адресату

Процедура формирования AuthTags показана в таблице ниже.

Шаг	Действие
1	Заполнить поле AuthRRTags (см. табл. 4.6.2.52)
2	Заполнить поле TransIDs. Если это последовательная авторизация и определено PaySysID, занести его значение в поле PaySysID.
3	Если это многоэтапный платеж и банк продавца задал для авторизации значение AuthRetNum, скопировать AuthRetNum из предыдущего AuthRes

Схема формирования поля данных AuthReq показана ниже.

Шаг	Действие
1	Если планируется обработка последовательных авторизаций для покупки и это не последняя авторизация, установить SubsequentAuthInd равным TRUE, в противном случае FALSE.
2	Если продавец и владелец карты договорились о рекуррентных или поэтапных платежах, заполнить поле InstallRecurData
3	Установить AuthReqAmt равным числу авторизаций
4	Опционно присвоить CardSuspect соответствущее значение, если продавец имеет какие-то подозрения относительно владельца карты.
5	Если при некотором платеже необходимы данные MerchData, добавить их в сообщение.
6	Сформировать MarketSpecAuthData, если это диктуется платежной системой карты или типом покупки.
7	Если политика платежной системы карты требует наличия AVSData, записать в это поле информацию, предоставленную владельцем карты.
8	Если политика платежной системы карты требует наличия SpecialProcessing, сгенерировать его значение.
9	Если продавец требует информацию о типе платежной карты, установить RequestCardTypeInd = TRUE.

Структура данных сообщения AuthReq представлена в таблице 4.6.2.64.

Безопасное ядро (SSH)

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.

Блок-схема реализации цикла алгоритма SAFER

Рисунок 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 показаны все возможные сообщения, которые могут иметь место при обработке транзакции (опционные сообщения отмечены курсивом). Следует заметить, что приведенный порядок обмена является рекомендуемым, и допускается его изменение.

Диаграмма реализации протокола SET

Рисунок 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 байтовый номер заказа продавца

Рассмотрим более подробно функции субъектов протокола SET.

Держатель карты (Cardholder)	Авторизованный владелец платежной карты, предоставленной ему эмитентом и предназначенной для выполнения платежей за покупки и услуги.
Продавец (Merchant)	Субъект или фирма, предлагающие товары, информацию или услуги, получающие от этого прибыль в виде платежей.
Эмитент (Issuer)	Финансовая организация, которая осуществляет выпуск платежных карт для клиентов и поддерживает функционирование их счетов. Эмитент гарантирует осуществление платежа для авторизованной транзакции.
Получатель (Acquirer)	Финансовая организация, которая поддерживает продавцов, осуществляя операции с платежными картами. Получатель осуществляет сбор финансовых данных, имеющих отношение к транзакции, для получения авторизации платежа, который выполняет эмитент.
Расчетный центр (Payment Gateway)	Система, которая предоставляет коммерческие услуги продавцам через посредство получателя, и обеспечивает интерфейс получателю для авторизации и реализации транзакции. Расчетный центр обычно управляется получателем.
Платежная система (Brand)	Система или компания, предоставляющая платежные средства (например, карты VISA, MasterCard и т.д.)
Сертификационный центр (Certificate Authority –CA)	Агент одной или нескольких систем платежных карт, который осуществляет создание и рассылку сертификатов для продавцов, покупателей и расчетных центров. Участники транзакции могут иметь единый сертификационный центр, но могут работать и с разными центрами. Основная задача СА – гарантия того, что данное сообщение, ключ и т.д. посланы определенным субъектом, а не самозванцем.

Протокол SET защищает только финансовую информацию, непосредственно сопряженную с платежной транзакцией. Защита информации, содержащейся в заказе, SET не регламентирует. Хэш описания заказа включается в запрос покупки (PReq).

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

Эта программа выполняет опосредованную связь с получателем. Зашифрованные платежные данные через систему продавца поступают в расчетный центр, где они дешифруются.

Программа продавца предоставляет интерфейс для взаимодействия с программой владельца платежной карты, с программой получателя (Acquirer – банк продавца) и с центром сертификации. Эта программа авторизует транзакцию, инициированную владельцем карты. Выполнение криптографических операций может производиться на аппаратном уровне. Такие криптографические модули могут быть снабжены также аппаратными устройствами генерации и запоминания секретных ключей (например, смарт-карты).

Важной функцией расчетных центров помимо реализации платежей является поддержка списков аннулированных сертификатов CRL (Certificate Revocation List). Это крайне важно для вовлеченных финансовых организаций и фирм предоставляющих платежные средства (например, таких как VISA или MasterCard).

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

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

Банк продавца получает свои сертификаты из платежной системы (brand).

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

Протокол SET определяет иерархию сертификационных центров, во главе которой находится RCA (Root Certificate Authority). Далее следуют BCA (Brand-specific CA) и GCA (Geo-political CA). Некоторые платежные системы имеют свои сети, например, VisaNet или BankNet. Эти сети осуществляют авторизацию платежей от эмитента к получателю и имеют свою систему защищенной передачи сообщений (ISO 8583).

Цифровая подпись устанавливает соответствие между подписанными данными и уникальным секретным ключом подписанта (покупателя, продавца, банкира или центра сертификации). Секретный ключ математически связан с общедоступным ключом, и таким образом, связывает данные и общедоступный ключ. Фундаментальной целью сертификата является установление соответствия между общедоступным ключом и уникальным идентификатором объекта (или субъекта), гарантируя отсутствие подмены. Следует помнить, что общедоступные ключи пересылаются по незащищенным каналам Интернет. В случае держателя карты сертификат подписи устанавливает соответствие между его общедоступным ключом и индивидуальным кодом PAN (Primary Account Number). Цифровая подпись в сочетании с хэшированием сообщения (вычислением его цифрового дайджеста) гарантирует, кроме того, целостность данного сообщения, блокируя возможность его модификации в процессе пересылки. Сообщения SET следуют рекомендациям ISO/IEC и ITU-T ASN.1 (Abstract Syntax Notation) и кодируется с использованием правил DER (Distinguished Encoding Rules). Механизм пересылки сообщений между объектами SET не регламентируется. Предполагается, что приложения SET могут работать в одном из двух режимов.

Интерактивном, когда объекты взаимодействуют в реальном масштабе времени с малыми задержками между запросами и откликами (например, в рамках технологии WWW).

Не интерактивном, когда задержки между запросом и откликом велики, например, при использовании электронной почты.

Каждая платежная система обеспечивает поддержку CRL в пределах зоны своей ответственности. Архитектура SET использует концепцию BrandCRLidentifier (BCI). BCI подписывается цифровым образом представителем платежной системы.

Протокол SET предполагает использование пар общедоступный/секретный ключ платежными центрами и продавцами обязательным и рекомендательным для владельцев карточек. SET использует стандарты PKCS (Public Key Cryptography Standards). Разработчики программ и систем должны обращать особое внимание на способы хранения секретных ключей. Настоятельно рекомендуется применение аппаратных средств для генерации ключей и шифрования. В настоящее время такие модули предлагаются и для обычных рабочих станций. Особые меры безопасности должны быть приняты для центров сертификации, так как именно они выступают гарантами корректности и безопасности применения общедоступных ключей участников транзакций.

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

Так как сертификаты, CRL и BCP используются достаточно часто при обработке сообщений SET, должен быть создан безопасный кэш для их хранения.

Так как объем транспортируемых протокольных структур весьма велик, для сокращения трафика используется механизм оттисков (thumbprints). Оттиск представляет собой хэш сертификата, CRL или BCI. Точнее это хэш SHA-1 одного из перечисленных объектов, снабженный цифровой подписью.

Цифровой конверт сообщения (MessageWrapper). MessageWrapper является информационной структурой верхнего уровня (ASN.1/DER) протокола SET. Эта структура размещается в самом начале сообщения и часто не шифруется.Она определяет тип MessageWrapper, информационные поля цифрового конверта представлены в таблице 4.6.2.1.

EncryptedData

Рисунок 4.6.2.7. EncryptedData

Тип DigestedData из PKCS #7 проиллюстрирован на Рисунок 4.6.2.8.

EnvelopedData

Рисунок 4.6.2.6. EnvelopedData

В пределах EnvelopedData допускается наличие нескольких EnvelopedData и только одно RecepientInfo.

Тип EncryptedData из PKCS #7 проиллюстрирован на Рисунок 4.6.2.7.

Формат информационной структуры msg_struc

Рисунок 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:

Формат SMDS-пакета

Рисунок .2. Формат SMDS-пакета

Адреса места назначения и отправителя состоят из 4-битного кода, за которым следует телефонный номер, содержащий до 15 десятичных чисел. Каждая цифра кодируется посредством четырех бит. Телефонный номер содержит код страны, код зоны и номер клиента-подписчика, что делает сеть SMDS международной. Длина поля данные является переменной. Когда пакет попадает в сеть SMDS, первый маршрутизатор проверяет, соответствует ли адрес отправителя номеру входной линии. При несоответствии пакет отбрасывается.

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

Другой особенностью адресации в SMDS является возможность использования списков доступа (screening) для входящих и исходящих пакетов. Кроме того, такая функция позволяет эффективно строить корпоративные сети типа Интранет. Поле данных может содержать в себе кадр Ethernet или пакет Token Ring, что также повышает эффективность и надежность работы сети, упрощая задачу интерфейсного оборудования.

Работа в условиях всплесков загрузки осуществляется следующим образом. Маршрутизатор в каждом из интерфейсов содержит счетчик, который инкрементируется с постоянной частотой (например, раз в 10 мксек). Когда на вход маршрутизатора приходит пакет, осуществляется сравнение длины пакета в байтах с содержимым этого счетчика. Если содержимое счетчика больше, пакет немедленно пересылается, а содержимое счетчика уменьшается на длину пакета. Если длина пакета больше содержимого счетчика, такой пакет отбрасывается. В результате при данной частоте приращения счетчика в среднем допускается передача 100000 байт/сек. Но импульсная загрузка может существенно превышать это значение.

Формат snmp-сообщений, вкладываемых в UDP-дейтограммы

Рисунок 4.4.13.2 Формат snmp-сообщений, вкладываемых в UDP-дейтограммы

Поле версия содержит значение, равное номеру версии snmp минус один. Поле пароль (community – определяет группу доступа) содержит последовательность символов, которая является пропуском при взаимодействии менеджера и объекта управления. Обычно это поле содержит 6-байтовую строку public, что означает общедоступность. Для запросов GET, GET-next и SET значение идентификатора запроса устанавливается менеджером и возвращается объектом управления в отклике GET, что позволяет связывать в пары запросы и отклики. Поле фирма (enterprise) = sysobjectid объекта. Поле статус ошибки характеризуется целым числом, присланным объектом управления:

Формат списка указателей для функций readv и writev

Рисунок 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) однажды, далее могут жить своей жизнью. Они могут принимать пакеты от других аналогичных “соединителей” и сами посылать им дейтограммы (кавычки здесь связаны с тем, что это не реальный соединитель и никакого соединения здесь не осуществляется).

Формат заголовка SNMP-запроса

Рисунок 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-протокол служит примером системы управления, где для достижения нужного результата выдается не команда, а осуществляется обмен информацией, решение же принимается "на месте" в соответствии с полученными данными.

Формат заголовка SNTP-пакета

Рисунок 4.4.16.2. Формат заголовка SNTP-пакета

Поле LI (Leap Indicator) содержит два бита кода предупреждения о добавлении/удалении секунды в последней минуте текущего дня. Значения кодов поля LI приведены в таблице 4.4.16.1:

Формат заголовка SPX-II

Рисунок 4.2.1.2.2. Формат заголовка SPX-II

Управление сетями Novell осуществляется с помощью стандартного протокола SNMP (Simple Network Management Protocol) и управляющей базы данных MIB.

Формат заголовка SPX-пакета

Рисунок 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 тем, что необходимо согласовать размер пересылаемых пакетов.

/H Десинхронизация может

ЭВМ Б проигнорирует сообщения от А, так как они имеют неправильные (навязанные хакером) номера, а ЭВМ А проигнорирует сообщения от Б, так как ожидает, что они будут пронумерованы по-новому. Теперь хакер знает, какие номера нужны А и Б (непосредственно же А и Б взаимодействовать не могут, так как не знают правильных номеров) и может перехватывать, модифицировать или посылать сообщения по своему усмотрению как А, так и Б.

Но десинхронизация может быть реализована и в ходе сессии. Если послать флаг 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. Обмен здесь полностью контролируется атакующей ЭВМ

Иерархия мультиплексирования SDH

Рисунок 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.

Центр PCA служит для выдачи сертификатов для платежных центров. Их функции, также как и в случае CCA, могут выполняться центрами платежной системы, получателя и т.д.

Любой центр сертификации выполняет следующие функции:

Формирование и выдача сертификата

Обновление сертификатов

Контроль работоспособности сертификатов и удаление непригодных

Формирование сертификатов осуществляется различными методами, зависящими от типа объекта. Для владельцев карты формируются только сертификаты подписи, для продавцов и платежных центров формируются сертификаты подписи и шифрования.

Сертификаты для владельцев карт формируются центрами CCA. Выпуск сертификата держателя карты включает в себя следующие обмены между держателем карты и CCA (см. также Рисунок 4.6.2.2).

Владелец карты посылает запрос сертификата

ССА производит шифрование сертификата для защиты передачи номера платежной карты в ССА

Владелец шифрует номер своей карты, используя сертификат ССА, и посылает результат в ССА

ССА откликается посылкой формы для регистрации сертификата карты

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

ССА верифицирует полученную регистрационную информацию с привлечением эмитента карты и генерирует сертификат, подписывает его и посылает владельцу карты.

Для продавцов сертификаты формируются в центрах MCA. Перед выпуском сертификата продавца запрос верифицируется банком продавца (получатель – acquirer) или центром управления платежной системы. Сертификат получается продавцом в результате последовательности следующих операций.

Продавец посылает запрос сертификата в МСА.

МСА откликается посылкой регистрационной формы.

Продавец заполняет форму и посылает ее и свой общедоступный ключ в МСА для обработки.

Банк продавца или центр управления платежной системы проверяет запрос продавца и МСА генерирует, подписывает и посылает сертификат продавцу.

Сертификаты платежного центра формируются и присылаются центром PCA. Процедура генерации сертификата сходна с вариантом продавца.

Банк продавца верифицирует запрос сертификата платежного центра и авторизует генерацию сертификата в РСА. Сертификаты центров сертификации формируются вышестоящими по иерархии узлами. Обновление любых сертификатов производится периодически и следует тем же алгоритмам, что и формирование совершенно нового сертификата. Регистрационная форма при обновлении сертификата может содержать существенно меньше информации.

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

При выполнении любой операции в рамках протокола SET производится проверка всех сертификатов, образующих иерархическую цепочку (см. Рисунок 4.6.2.11), начиная от конечного объекта (ЕЕ) до корневого (Root). Стрелки означают, чей сертификат использовался для подписи. Таким образом, каждый сертификат связан с сертификатом подписи субъекта его сформировавшего.

Иллюстрация функций преобразования

Рисунок 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

В алгоритме используется также 80 констант K1,K2,…, K79:

Kt = 5A827999	для 0 Ј t Ј 19
Kt = 6ED9EBA1	для 20 Ј t Ј 39
Kt = 8F1BBCDC	для 40 Ј t Ј 59
Kt = CA62C1D6	для 60 Ј t Ј 79

Вводится 5 переменных Hi инициализируемых как:

H0 = 67452301

H1 = EFCDAB89

H2 = 98BADCFE

H3 = 10325476

H4 = C3D2E1F0

Делим массив M на группы из 16 слов W0, W1,…,W15 (W0 самое левое слово).

Для t = 16 - 79 wt = S1(Wt-3 XOR Wt-8 XOR Wt-14 XOR Wt-16)

Ak означает операцию циклического сдвига влево на k разрядов.

Пусть теперь A = H0, B = H1, C = H2, D = H3, E = H4.

for t = 0 to 79 do

TEMP = S5(A) + ft(B,C,D) + E + Wt + Kt. (TEMP – временная переменная).

E = D; D = C; C = S30(B); B = A; A = TEMP;

Пусть H0 = H0 + A; H1 = H1 + B; H2 = H2 + C; H3 = H3 + D; H4 = H4 + E.

В результате обработки массива М будет получено 5 слов H0, H1, H2, H3, H4 с общей длиной 160 бит, которые и образуют дайджест сообщения. Полученная кодовая последовательность с высокой степенью уникальности характеризует сообщение. Любое редактирование сообщения практически неизбежно приведет к изменению дайджеста. Поскольку алгоритм вычисления дайджеста общеизвестен, он не может рассматриваться как гарантия предотвращения модификации сообщения. Смысл вычисления дайджеста заключается в уменьшении объема данных, подлежащих шифрованию. Для того чтобы превратить дайджест в электронную подпись надо воспользоваться секретным ключом. Схема реализации алгоритма DSA (Digital Signature Standard) показана на Рисунок 6.4.3.1.

Коммутируемая мультимегабитная информационная служба SMDS

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 практически не предоставляют сколько-нибудь существенной защиты.

Никто кроме владельца счета не может иметь к нему доступа, и никто не должен иметь возможности имитировать работу владельца счета.

Плательщик должен иметь возможность доказать третьей стороне, что платеж произведен и предоставить данные о предмете платежа. Это необходимо в случае конфликта, когда клиент либо не получил оплаченный товар, либо, например, не удовлетворен его качеством. Здесь нужно учитывать возможность случайного или преднамеренного искажения сообщений при их передаче.

Получатель платежа должен иметь возможность доказать третей стороне, какую сумму, когда, за что и от кого он получил. Это нужно для разрешения возможных конфликтов с клиентом.

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

Плательщик должен быть уверен, что платеж будет осуществлен именно тому продавцу товара или услуг, кому он хотел. Это подразумевает иммунитет системы против преднамеренных искажений платежных сообщений.

Система должна противостоять фальсификации расписок банкира.

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

Конфликты между клиентами должны разрешаться без участия банкира.

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

Не менее важную роль имеет конфиденциальность любых финансовых операций.

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

Получатель платежа не должен получать информации, позволяющей идентифицировать плательщика.

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

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

4.6.2.1. Протокол микроплатежей MPTP (Micro Payment Transfer Protocol)

Разработчики технологии WWW, HTML и XML (группа W3C;

http://www.w3.org/TR/WD-mptp-951122) разработали проект платежного протокола, который является модификацией алгоритма Pay-Word, предложенного Ривестом и Шамиром (“PayWord and MicroMint – Two Simple Micropayment Schemes”, R.L. Rivest and A.Shamir; http://theory.lcs.mit.edu/~rivest/RivestShamir-mpay.ps). Электронная коммерция предполагает рекламу, продажу материальных и нематериальных товаров. Материальные товары требуют доставки, что усложняет процедуру купли-продажи. Торговля через Интернет требует минимизации времени отклика для клиента. Кроме того, важно, чтобы издержки, сопряженные с торговыми операциями, составляли небольшую долю стоимости покупки, что становится весьма критично при низкой стоимости приобретаемого товара или услуги. При проектировании новых торговых систем следует учитывать, что процедуры верификации электронной подписи могут выполняться на стандартной рабочей станции со скоростью около 1000/сек, а вычисление однопроходной хэш-функции занимает примерно 10 мксек. Контроль хэш-функции в 100 раз быстрее, чем верификация RSA-подписи, и в 10000 раз быстрее формирования RSA-подписи. Таким образом, современная персональная ЭВМ вполне успешно может решать любые торговые операции даже в режиме сервера, который обслуживает десятки и сотни клиентов одновременно.

Время отклика в любом случае не будет превышать одной секунды. Работа в реальном масштабе времени предлагает на два порядка более высокие требования, чем работа в режиме off-line.

Протокол MPTP является асинхронным (большинство операций выполняются в режиме off-line). MPTP не делает различия между покупателем и продавцом. Протокол предполагает существование посредника-брокера (B; банкира), который контролирует счета участников сделок. Под брокером может подразумеваться любая организация, способная работать со счетами достаточно большого числа клиентов при минимальных издержках. Брокером может быть сервис-провайдер (ISP), телефонная компания или банк.

При разработке протокола принимались во внимание следующие риски.

Злоупотребление кредитом (осуществление платежей через счет без реального намерения платить)

Мошенничество (например, направление фиктивного платежного поручения).

Неавторизованный отзыв платежа

Неавторизованная модификация заказа

Ошибка при выполнении кредитной операции

Дублирование платежного поручения (клиентом или третьим лицом)

Отказ от услуги (клиент или продавец отказываются использовать свои счета)

Отказ выполнения платежа

Недоставка (платеж получен, а товар не доставлен).

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

Алгоритм платежа в MPTP основан схеме PayWord (1996 г.), где вычисляется цепочка значений хэш-функций c привлечением схемы MD5 или SHA. Полученные значения имеют 128 или 160 бит, допускается и меньшая длина.

Схема PayWord является кредитной и практически реализует схему электронных монет.

Пользователь запрашивает у брокера (банкира) счет и сертификат, передав ему по безопасному каналу номер своей кредитной карты, общедоступный ключ шифрования и адрес доставки (например, E-mail или IP-адрес). Брокер при этом посылает сертификат покупателя СП, который имеет вид:

СП = [B, ID, AП, PKП, E, IП]SKB

где B – идентификатор (имя) брокера; ID – идентификатор покупателя; AП – адрес доставки; PKП – общедоступный ключ покупателя; Е – время истечения действия сертификата (брокер может обновлять его, например, раз в месяц); IП – дополнительная информация, задаваемая брокером, например, серийный номер сертификата, лимит кредита и т.д.; SKB – секретный ключ брокера. Сертификат СП получен путем шифрования содержимого квадратных скобок с помощью SKB. В некоторых других платежных схемах сертификат формируется клиентом-покупателем. Сертификат устанавливает связь между общедоступным ключом покупателя и его счетом для заданного общедоступного ключа брокера. Предполагается, что общедоступный ключ брокера известен всем участникам платежного процесса. Генерация пар общедоступный-секретный ключ осуществляется каждым участником независимо. Данная схема не гарантирует анонимности (AП!), более того, здесь имеется риск утечки информации о номере кредитной карты пользователя. Сертификат гарантирует продавцу, что платежные слова (payWord) покупателя будут выкуплены брокером.

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

Когда пользователь обращается к коммерческой странице продавца, его броузер определяет, является ли данный вызов первым в этот день. Если это первое обращение, программа покупателя формирует и подписывает обязательство, сопряженное с цепочкой платежных слов w1, w2, …, wn, где wn выбирается случайным образом. Значение n определяется клиентом. Все остальные платежные слова вычисляются рекурсивно, согласно соотношению:

wi = H(wi+1) для i= n-1, n-2,…,0.

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

i-платеж (для i = 1, 2, …) продавцу состоит из пары чисел (wi,i). Продавец может проверить это посылку, используя значение wi-1. Стоимость всех платежных слов (PayWord) w1, w2, …, wn идентична. Каждый платеж не предполагает каких-либо вычислений в программе покупателя и лишь одну хэш-операцию в программе продавца.

Платежи должны быть индексированы в соответствии с порядком (i) сформированных платежных слов. Это исключает повторное использование платежных слов. Но возможна передача после платежного слова wi платежного слова wi+10, это будет означать оплату очередной покупки стоимостью 10 рублей (если одно платежное слово стоит один рубль). В конце каждого дня продавец передает брокеру последнее платежное сообщение за этот день (wl, L) каждого из покупателей, добавляя к нему соответствующее обязательство. Брокер снимает со счета покупателя L рублей (L платежных слов) и переводит их на счет продавца. Предполагается, что существует всего несколько брокерских центров на страну. Практически все операции выполняются в режиме off-line, а брокер не получает даже сообщений о каждом платеже (а только о последнем за данный день). Заметим, что в данной системе не специфицируется явно то, за какой товар или услугу осуществлен платеж.

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

4.6.2.2. MicroMint

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

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

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

Монеты MicroMint формируются с использованием кратных столкновений хэш-функций. Однопроходная хэш-функция H ставит в соответствие m битам строки х n бит строки y. Строка х называется исходным образом y, если H(x)=y. Пара строк (х1,х2) называются двойным столкновением, если H(x1)=H(x2)=y, где строка y имеет n бит. Если хэш-функция гарантирует достаточно высокий уровень рэндомизации, то для получения одного двойного столкновения необходимо вычислить для строки х примерно 2n/2 xэш-функций. Но при ограниченном n вычисление двойных столкновений является относительно простой задачей и для злоумышленника, по этой причине для формирования монет чаще используется вычисление k-кратных столкновений.

k-кратным столкновением называется набор строк х1, х2, …, хk для которых H(x1)=H(x2)=…=H(xk)=y. Для получения k-кратного столкновения необходимо выполнить вычисление примерно 2n(k-1)/k хэш-функций. В дальнейшем будем считать, что монета характеризуется k-кратным столкновением (х1, х2, …, хk). Корректность монеты может проверить кто угодно, вычислив k хэш-функций и проверив условие.

H(x1)=H(x2)=…=H(xk)=y

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

Предположим, что брокер хочет иметь чистый доход размером в 1 млн.

долларов США (эквивалентно примерно 227 центов/месяц). Пусть доходы брокера составляют 10%, это означает, что продавец получает 0,9 цента при выкупе монеты. Таким образом, брокер должен продать миллиард монет в месяц. Если обычный клиент покупает 2500 монет в месяц, необходимо иметь 500000 клиентов.

Пусть k=4 (4-кратные столкновения). Для того чтобы сформировать 230 монет, надо будет закупить специализированное оборудование стоимостью около 100000$ (что менее 10% месячного дохода). Для целей вычисления хэш-функций могут использоваться специализированные ИС, применяемые для DES-шифрования или ИС FPGA – программируемые логические матрицы. Подготовка брокером нового набора монет может продолжаться в течение всего месяца. Нетрудно понять, что злоумышленнику, использующему обычную рабочую станцию, сформировать самостоятельно достаточное число монет не по плечу.

При продаже монет клиенту брокер запоминает, какому клиенту какие монеты проданы, что позволяет в будущем проконтролировать попытки злоупотреблений. Неиспользованные монеты ликвидируются в конце месяца. Ограничение времени действия монет создает определенные трудности для клиента. Но за то это ограничивает требуемые объемы баз данных, хранящих информацию о выпущенных и использованных уже монетах. Монетная система по своей природе предполагает определенное доверие между плательщиком и получателем платежа. Получатель может присвоить монету и заявить, что она уже была использована, а плательщик может предъявить претензии получателю (банку или продавцу), утверждая, что повторного использования не было, а монета просто присвоена. В сущности, это является общим свойством любых монет и сертификатов на предъявителя.

Каждый раз, когда клиент осуществляет покупку, он пересылает продавцу одну или несколько монет (х1, х2, …, хk). Это может осуществляться автоматически программой WEB-броузера. Продавец проверяет корректность монет путем вычисления k функций H(xi), что занимает совсем немного вычислительных ресурсов. При возвращении монет продавцом брокеру проверка повторяется.

Существуют методы формирования монет специфических для клиента или для продавца, что снижает риски злоупотреблений (смотри “PayWord and Micromint: Two simple micropayment schemes” Ronald L. Riverst и Adi Shamir, 7 мая 1996).

Мелкомасштабная атака малоэффективна, и по этой причине недостойна серьезного внимания (злоумышленник должен понести большие издержки из-за нескольких центов). Для такого рода атак для k=4 и n=54 при использовании стандартной рабочей станции требуются десятки лет.

Крупномасштабное мошенничество легко детектируется из-за следующих обстоятельств.

Все фальшивые монеты теряют силу в конце месяца.

Фальшивые монеты могут быть сформированы после того, как брокер выбросил на рынок новую партию монет в начале месяца.

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

Брокер может в любой момент объявить об истечении срока годности выпущенных в оборот монет и запустить в оборот новую партию.

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

Таким образом, любые злоупотребления легко обнаруживаются, но так как в MicroMint не используются подписи, выяснение отношений в суде невозможно.

Для генерации монет, специфических для клиентов, последние делятся брокером на группы. Например, клиенту U даются монеты, которые дополнительно отвечают требованию h(х1, х2, …, хk)=h(U), где h – хэш-функция, формирующая 16-битовый код. Данное решение может оказаться не слишком хорошим для больших групп, где вор всегда сможет найти клиента, желающего приобрести украденные монеты.

При малых же группах брокер будет вынужден производить слишком большую вычислительную работу.

Другим вариантом может быть обобщение понятия столкновения. Монета (х1, х2, …, хk) будет считаться корректной для клиента U, если образы y1=(x1), y2=(x2),…, yk=(xk) удовлетворяют условию yi+1 – yi = di (mod 2u) для i =. 1,2,..,k-1, где (d1,d2,…,dk-1)=h(U). Стандартный алгоритм формирования монет соответствует случаю, когда все значения d равны нулю. Формирование монет специфических для продавца может осуществляться согласно алгоритму, схожему с выше описанным.

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

Другие системы для осуществления небольших платежей, например, NetBill предлагают дополнительные возможности (например, заказы товара и шифрование информации о покупке), но они относительно дороже.

4.6.2.3. Безопасный протокол электронных платежей SET

Для операций с кредитными карточками используется протокол SET (Secure Electronic transactions; см. http://www.visa.com/cgi-bin/vee/sf/standard.html http://www.citynet.net/personal/till/set1.htm), разработанный совместно компаниями Visa, MasterCard, Netscape (http://www.netscape.com) и Microsoft (см. также достаточно полное англоязычное описание протокола по адресу ftp://saturn.itep.ru/../set_bk1.pdf и т.д. “SET - Secure Electronic Transaction Specification”). Полная документация по SET имеет объем около 970 страниц. Данная статья является изложением базовых принципов и понятий. В отличие от SSL протокол SET узко специализирован. Целью SET является обеспечение необходимого уровня безопасности для платежного механизма, в котором участвует три или более субъектов. При этом предполагается, что транзакция реализуется через Интернет. В РФ в настоящее время разработано и разрабатывается большое число различных платежных программ, некоторые из них достаточно совершенны. Здесь следует иметь в виду, что если российские торговые компании и банки не хотят оказаться в изоляции, если они не будут учитывать складывающиеся тенденции и стандарты, шансов конкурировать на международном, а вскоре и на отечественном рынке у них не будет.

Для этого нужно снять ряд юридических ограничений, действующих в РФ и блокирующих развитие электронной торговли (это касается прежде всего алгоритмов RSA, электронной подписи и т.д.). На базовом уровне SET осуществляет следующие функции:

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

Конфиденциальность. Все операции производятся в зашифрованном виде.

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

Подсоединение. SET позволяет подключить к базовому сообщению дополнительный текст и послать его одному из партнеров.

Безопасность. Протокол должен обеспечить максимально возможную безопасность операции, достижимую в имеющихся условиях.

Совместимость. Должна быть предусмотрена совместимость с любыми программными продуктами и с любыми сервис-провайдерами.

Независимость от транспортного протокола. Безопасность операций не должна зависеть от уровня безопасности транспортного протокола. Такие гарантии особенно важны, так как протокол SET ориентирован для работы в Интернет.

На более высоком уровне протокол SET поддерживает все возможности, предоставляемые современными кредитными карточками:

Регистрацию держателя карточки

Регистрацию продавца

Запрос покупки

Авторизацию платежа

Перевод денег

Кредитные операции

Возврат денег

Отмену кредита

Дебитные операции

Окончательная версия протокола SET была выпущена в мае 1997 года. Протокол работает с четырьмя субъектами: владельцем кредитной карточки, банком, эту карточку выпустившим (issuer - эмитент), продавцом (merchant) и банком, где помещен счет продавца (acquirer). Помимо этих функциональных субъектов в процессе обычно (опционно) участвует центры сертификации, в задачу которых входит подтверждение подлинности предъявляемых параметров аутентификации, причем в случае крупных сделок с этими центрами должны взаимодействовать все участники.

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

Практика электронной торговли позволяет выделить семь этапов сделки.

Этап	Действие
1	Владелец карты просматривает позиции каталога продавца: В реальном масштабе времени на WEB-сервере На CD-диске на своей рабочей станции Читая бумажную версию каталога Через поисковую систему посредника
2	Владелец карты выбирает понравившийся товар или услугу.
3	Владельцу карты предоставляется форма заказа, содержащая список позиций, их цены, стоимости доставки, уровни платежей по налогам, возможные скидки и т.д. Такая форма может быть доставлена по сети с сервера продавца или сформирована торговой программой владельца карты. Иногда продавцы предоставляют возможность согласования цены продукта (например, предъявляя карту постоянного покупателя или предоставляя цены конкурентов).
4	Владелец карты выбирает средство платежа. SET предполагает применение различных кредитных и платежных карт.
5	Владелец карты посылает продавцу заполненную форму заказа и платежные инструкции. В данной спецификации предполагается, что заказ и инструкции подписываются владельцем карты электронным образом с привлечением имеющихся в его распоряжении сертификатов.
6	Продавец запрашивает платежную авторизацию от эмитента карты.
7	Продавец посылает подтверждение заказа.
8	Продавец доставляет заказанный товар или услугу
9	Продавец посылает запрос на оплату товара или услуги финансовой организации владельца карты.

Порядок следования этапов при определенных условиях может несколько варьироваться. Спецификация SET определяет функции и технику реализации этапов 5, 6, 7 и 9. Таким образом, работа протокола SET инициализируется владельцем карты. Владельцем карты может быть как частное лицо, так и корпоративный клиент, работающие на своих рабочих станциях.

Многие современные WEB-броузеры поддерживают протокол SET. Что позволяет осуществлять торговлю товарами и услугами с использованием WWW-технологии.

Напрашивается вопрос, почему для финансовых операций не использовать протокол SSL, который весьма широко распространен? SSL позволяет безопасно передавать продавцу номер кредитной карточки покупателя, но не способен реализовать многие другие операции, например, проверить этот номер на правильность, проконтролировать, позволено ли данному клиенту пользоваться данной карточкой и т.д.. Конечно, не трудно создать CGI-скрипты, которые решат некоторые из этих проблем, но это не может заменить контроля в реальном масштабе времени, необходимого для некоторых операций. Нельзя утверждать, что в рамках протокола SSL нельзя решить и эти проблемы, но для этого нужно создать достаточно большое число специализированных программ, которые в существующих пакетах пока отсутствуют. Кроме того, нужно думать и о безопасности на стороне сервера. Продавец, получив номер кредитной карточки, может занести его в базу данных. А где гарантия (для покупателя), что эта база данных достаточно хорошо защищена? Таким образом, даже передача номера кредитной карточки посредством SSL не самая лучшая идея. Тем более такая схема позволяет осуществлять подбор номеров кредитных карт. А заботиться об удобствах воров не самое полезное занятие.

Номер кредитной карточки имеет определенную структуру (это не случайное число). Первые четыре цифры – код банка, выпустившего карточку. Последняя цифра представляет собой контрольную сумму номера. Вычисление этой контрольной суммы производится по следующему алгоритму.

Каждая цифра номера умножается на его “вес”. Веса меняются 1,2,1,2. Для карт с четным числом цифр, последовательность весов начинается с 2, в противном случае с 1. Если взвешенное число больше 9, из него вычитается 9. Далее вычисляется сумма по модулю 10. Результат всегда должен получаться равным нулю (с учетом кода контрольной суммы).

Схема взаимодействия субъектов в протоколе SET показана на Рисунок 4.6.2.1 (взаимодействия с центром сертификации не показаны). Протокол SET помогает реализовать следующие процедуры.

Модель машины конечных состояний

10.23 Модель машины конечных состояний

Базовой концепцией построения многих современных протоколов является машина конечных состояний (FSM - Finite State Machine). При этом подходе каждый протокол характеризуется машиной, которая в любой момент времени находится в каком-то конкретном состоянии. Каждому состоянию соответствует определнный набор значений системных переменных. Такой подход требует определенного уровня абстрагирования. Например, для того чтобы ЭВМ перешла из состояния ожидания в состояние, когда получено некоторое сообщение, реализуется достаточно много промежуточных операций (проверка качества сигнала, контроль целостности сообщения, проверка отсутствия переполнения буфера и многие другие). Все эти промежуточные операции и состояния считаются переходными и в данной модели не рассматриваются. Таким образом, состояние протокольной машины полностью определяется набором значений определенных системных переменных. Так состояние протокольной машины канала определяется состояниями клиента и сервера. Если состояние как отправителя так и получателя характеризуются двумя битами, то состояние системы будет характеризоваться 16 состояниями. Из любого состояния может быть нуль или более возможных переходов в другое состояние. Переход из одного состояние в другое происходит при наступлении определенного события (например, полчение сообщения, прерывание, таймаут и т.д.).

Машина состояний протокола может быть охарактеризована с помощью ориентированного графа, в котором число узлов равно числу конечных состояний системы, а число ребер всей совокупности возможных переходов из одного состояния в другое. Одно из состояний выбирается в качестве исходного. Из этого состояния система может попасть в некоторые (все) другие состояния с помощью последовательности переходов. Данный подход позволяет часто выявить слабые места протокола (например, возможности "повисаний").

Машина конечных состояний протокола характеризуется следующими наборами переменных

S	Набор состояний процессов и канала
M	Набор кадров, которые могут быть переданы по каналу
I	Набор исходных состояний процессов
T	Набор переходов между состояниями

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

Обработка информационных запросов

Пара сообщений 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 определены следующие поля

Имя поля	Описание
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	Вложить сообщение в цифровой конверт и послать владельцу карты

Генерация CapPayload осуществляется согласно алгоритму.

Шаг	Действие
1	Занести в поле CapDate текущее значение даты
2	Занести в CapReqAmt сумму выплаты
3	Скопировать AuthResPayload из соответствующего AuthRes
4	Опционно заполнить CPayExtensions

Формат сообщения CapReq представлен в таблице 4.6.2.68

Обработка сообщений

Базовыми процедурами протокола 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, если сертификата нет.

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

Реализация PReqDualSigned рассмотрена ниже.

Шаг	Действие
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.

Сообщение запроса покупки PReq содержит инструкцию заказа OI для продавца и платежную инструкцию для передачи транзитом в зашифрованном виде через продавца в расчетный центр. Аутентичность и целостность сообщений достигается за счет использования двойной подписи, если владелец карты имеет сертификат (PReqDualSigned). Если владелец карты не имеет сертификата, для тех же целей применяются хэши в ОАЕР-конверте (PReqUnsigned).Структура данных в случае PreqDualSigned показана в таблице 4.6.2.57.

Обработка запросов/откликов инициализации платежа

Процедура инициализации платежа включает в себя обмен двумя сообщениями. Первоначальный запрос 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.

Pdh-мультиплесирование

Рисунок 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синтаксис сертификатов

Приложение 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 смогут поддерживать больше типов атрибутов и больше идентификаторов объектов.

B.1. Выбранные типы атрибутов

commonName { attributeType 3 }	Общее имя, содержащееся в поле эмитента сертификата или субъекта сертификата.
countryName { attributeType 6 }	Название страны.
localityName { attributeType 7 }	Название местоположения.
stateOrProvinceName { attributeType 8 }	Название штата или провинции.
organizationName { attributeType 10 }	Название организации.
organizationalUnitName { attributeType 11 }	Название подразделения.

B.2. Идентификаторы объекта

md2withRSAEncryption { ... pkcs(1) 1 2 }

Идентификатор объекта для цифровой подписи, которая используется при шифровании MD2 и RSA. Применяется при SSL-верификации подписи сертификата.

md5withRSAEncryption { ... pkcs(1) 1 4 }

Идентификатор объекта для цифровой подписи, которая используется при шифровании MD5 и RSA. Применяется при SSL-верификации подписи сертификата.

rc4 { ... rsadsi(113549) 3 4 }

Алгоритм симметричного поточного шифра RC4, используемый SSL для массового шифрования.

Приложение C. Значения протокольных констант

Ниже рассмотрены различные протокольные константы. Одна вещь требует особого упоминания - IANA зарезервировала номер порта для "https" (HTTP использующий SSL). Этот порт имеет номер 443.

C.1. Коды версии протокола

#define SSL_CLIENT_VERSION 0x0002

#define SSL_SERVER_VERSION 0x0002

C.2. Коды протокольных сообщений

Определены следующие значения для кодов сообщений, которые используются версией 2 протокола диалога SSL.

#define SSL_MT_ERROR 0

#define SSL_MT_CLIENT_HELLO 1

#define SSL_MT_CLIENT_MASTER_KEY 2

#define SSL_MT_CLIENT_FINISHED 3

#define SSL_MT_SERVER_HELLO 4

#define SSL_MT_SERVER_VERIFY 5

#define SSL_MT_SERVER_FINISHED 6

#define SSL_MT_REQUEST_CERTIFICATE 7

#define SSL_MT_CLIENT_CERTIFICATE 8

C.3. Коды сообщений об ошибках

Определены следующие значения для кодов ошибок, используемых в сообщениях ERROR.

#define SSL_PE_NO_CIPHER 0x0001

#define SSL_PE_NO_CERTIFICATE 0x0002

#define SSL_PE_BAD_CERTIFICATE 0x0004

#define SSL_PE_UNSUPPORTED_CERTIFICATE_TYPE 0x0006

C.4. Значения вида шифра

Определены следующие значения для кодов CIPHER-KIND, используемых в сообщениях CLIENT-HELLO и SERVER-HELLO.

#define SSL_CK_RC4_128_WITH_MD5 0x01,0x00,0x80

#define SSL_CK_RC4_128_EXPORT40_WITH_MD5 0x02,0x00,0x80

#define SSL_CK_RC2_128_CBC_WITH_MD5 0x03,0x00,0x80

#define SSL_CK_RC2_128_CBC_EXPORT40_WITH_MD5 0x04,0x00,0x80

#define SSL_CK_IDEA_128_CBC_WITH_MD5 0x05,0x00,0x80

#define SSL_CK_DES_64_CBC_WITH_MD5 0x06,0x00,0x40

#define SSL_CK_DES_192_EDE3_CBC_WITH_MD5 0x07,0x00,0xC0

C.5. Коды типа сертификата

Определено следующее значение для кода типа сертификации, используемое в сообщениях SERVER-HELLO и CLIENT-CERTIFICATE.

#define SSL_CT_X509_CERTIFICATE 0x01

C.6. Коды типов аутентификации

Определено следующее значение для кода типа аутентификации, используемое в сообщениях REQUEST-CERTIFICATE.

#define SSL_AT_MD5_WITH_RSA_ENCRYPTION 0x01

C.7. Верхние/нижние ограничения

Следующие величины определяют верхние/нижние ограничения для различных протокольных параметров.

#define SSL_MAX_MASTER_KEY_LENGTH_IN_BITS 256

#define SSL_MAX_SESSION_ID_LENGTH_IN_BYTES 16

#define SSL_MIN_RSA_MODULUS_LENGTH_IN_BYTES 64

#define SSL_MAX_RECORD_LENGTH_2_BYTE_HEADER 32767

#define SSL_MAX_RECORD_LENGTH_3_BYTE_HEADER 16383

Приложение D: Атаки

В данном разделе описываются различные атаки, которые могут быть предприняты против протокола SSL. Этот перечень не может считаться исчерпывающим. SSL показал устойчивость к этим атакам.

D.1. Раскрытие шифров

SSL зависит от нескольких криптографических технологий. Шифрование с общедоступным ключом RSA [5] используется для пересылки ключей сессии и аутентификации клиента/сервера. В качестве шифра сессии применяются различные криптографические алгоритмы. Если осуществлена успешная атака на эти алгоритмы, SSL не может уже считаться безопасным.

Атаки против определенных коммуникационных сессий могут производиться путем записи сессии, и затем, потратив большое количество компьютерного времени, предпринимается попытка подобрать ключ сессии или ключ RSA.

В случае успеха открывается возможность прочесть переданную информацию. Этот подход легче, чем попытка вскрытия криптографии всех возможных сообщений. Заметим, что SSL пытается сделать цену таких атак выше, чем выгоды от успешной атаки, таким образом, делая ее пустой тратой времени и денег.

D.2. Атака открытого текста

Атака открытого текста производится, когда атакующий имеет соображения о том, какого типа сообщения посылаются зашифрованными. Атакующий может формировать базу данных, где ключами являются зашифрованные строки известного текста (или открытого текста). Раз база данных создана, с помощью простых просмотровых функций можно идентифицировать ключ сессии, который соответствует определенному зашифрованному блоку данных. Если ключ сессии удалось раскрыть, можно дешифровать весь поток данных. Общедоступные аппаратные средства могут сделать эту работу быстрее и эффективнее.

Из-за самой природы SSL атаки открытого текста возможны. Например, наиболее часто встречающейся строкой, пересылаемой HTTP-клиентом серверу является "GET". SSL пытается противостоять этим атакам, используя большие ключи сессии. Сначала клиент генерирует ключ, который длиннее чем допускается экспортными ограничениями, и посылает часть его открытым текстом серверу (это разрешено экспортными правилами). Открытая часть ключа объединяется с секретной частью, чтобы получить достаточно длинный ключ, например 128 бит, как этого требует RC4.

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

Другой способ, с помощью которого SSL может противостоять данной атаке, заключается в использовании максимально возможных длин ключей (например, в случае не экспортного варианта).

Заметим, что следствием всех этих мер защиты SSL является то, что самым простым и дешевым способом атаки становится лобовая атака ключа. Такого рода атаки требуют большой памяти и много времени и их стоимость достаточно легко оценить. Для 128-битового ключа стоимость его раскрытия можно считать бесконечной. В случае 40-битного секретного ключа цена много меньше, но все равно за пределами возможностей “дикого хакера”.

D.3. Атака отклика

Атака отклика достаточно проста. Злоумышленник записывает коммуникационную сессию между клиентом и сервером. Позднее, он устанавливает соединение с сервером и воспроизводит записанные сообщения клиента.

SSL отбивает эту атаку, с помощью специального кода "nonce" (идентификатор соединения), который является уникальным. Теоретически злоумышленник не может предугадать этот код заранее, так как он основывается на наборе случайных событий, неподвластных злоумышленнику и, следовательно, он не может реагировать адекватно на запросы сервера.

Злоумышленник с большими ресурсами может записать большое число сессий между клиентом и сервером и попытаться подобрать “правильную” сессию, основываясь на коде nonce, посланном сервером посылает в сообщении SERVER-HELLO. Однако коды nonce SSL имеют, по крайней мере, длину 128 бит, таким образом, злоумышленник будет вынужден записать примерно 264 кодов nonce, при этом он получит вероятность угадывания лишь 50%. Это число достаточно велико, чтобы сделать такого рода атаки бессмысленными.

D.4. Человек посередине

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

“Посредник” прикидывается сервером для клиента и клиентом для сервера.

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

Если посредник предоставляет поддельный сертификат, то он не пройдет проверку подписи, так как злоумышленник не может знать секретного ключа сервера.

Приложение E: Термины

Прикладной протокол

Прикладным протоколом является протокол, работающий поверх TCP/IP. Например: HTTP, TELNET, FTP и SMTP.

Массовый шифр

Массовые шифры используются, когда нужно за ограниченное время зашифровать/дешифровать большой объем данных. Примерами могут служить RC2, RC4 и IDEA.

Клиент

Клиентом считается приложение субъекта, который инициирует соединение с сервером.

CLIENT-READ-KEY

Ключ сессии, который использует клиент для инициализации своего шифра чтения. Этот ключ имеет то же значение, что и SERVER-WRITE-KEY.

CLIENT-WRITE-KEY

Ключ сессии, который использует клиент для инициализации своего шифра записи. Этот ключ имеет то же значение, что и SERVER-READ-KEY.

Мастерный ключ

Мастерный ключ, который используется клиентом и сервером для формирования всех ключей сессий. CLIENT-READ-KEY, CLIENT-WRITE-KEY, SERVER-READ-KEY и SERVER-WRITE-KEY генерируются на основе MASTER-KEY.

MD2

MD2 [8] – это хэш-функция, которая преобразует поток данных произвольной длины в дайджест фиксированного размера. Эта функция является предшественницей MD5 [7] [9].

MD5

MD5 [7] – это хэш-функция, которая преобразует поток данных произвольной длины в дайджест фиксированного размера. Функция имеет свойства, которые делают ее полезной при обеспечении конфиденциальности, главное из этих свойств – невозможность обратимости.

Nonce

Случайный код, который используется для предотвращения атак воспроизведения. Один партнер генерирует случайный код (nonce) и посылает его другому партнеру.

Получатель шифрует его с помощью секретного ключа и возвращает отправителю. Так как nonce является случайным числом, злоумышленник не может предугадать его значение, что делает невозможной атаку воспроизведения. Получатель разрывает соединение, если обнаружит неверно зашифрованный код nonce.

Регистрируемый информационный обмен

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

Шифрование общедоступным ключом

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

Конфиденциальность

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

RC2, RC4

Массовые шифры, изобретенные RSA. RC2 является блочным шифром, а RC4 - поточным.

Сервер

Сервером считается приложение субъекта, которое реагирует на запросы установления соединения клиентов. Сервер является пассивным объектом, ожидающим запросов от клиентов.

Шифр сессии

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

Идентификатор сессии

Идентификатор сессии является случайным числом, генерируемым клиентом, который идентифицирует таким способом себя серверу. Идентификатор сессии может рассматриваться как средство доступа обоих участников к записанному секретному ключу (в нашем случае к ключу сессии). Если оба партнера помнят идентификатор сессии, тогда считается, что секретный ключ известен и его не нужно согласовывать.

Ключ сессии

Ключ шифра сессии. В SSL существует четыре ключа, которые называются ключами сессии: CLIENT-READ-KEY, CLIENT-WRITE-KEY, SERVER-READ-KEY и SERVER-WRITE-KEY.

SERVER-READ-KEY

Ключ сессии, который используется сервером для инициализации шифра чтения сервера. Этот ключ имеет то же значение что и CLIENT-WRITE-KEY.

SERVER-WRITE-KEY

Ключ сессии, который используется сервером для инициализации шифра записи сервера. Этот ключ имеет то же значение что и CLIENT-READ-KEY.

Симметричный шифр

Симметричный шифр используется как для шифрования, так и для дешифрования. Примерами симметричных шифров могут служить: IDEA, RC2, RC4.

Ссылки

[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.

Патентное заявление

Эта версия протокола SSL базируется на использовании патентованной технологии шифрования с общедоступным ключом, которая служит для аутентификации и шифрования/дешифрования. Процесс стандартизации в Интернет, определенный в RFC 1310, требует письменного заявления от владельца патента, что лицензия предоставляется пользователям на определенных, приемлемых условиях, прежде чем рекомендации будет одобрены в качестве предложения, проекта или стандарта Интернет.

Массачусетский Технологический институт и Совет попечителей Стэнфордского университета (Leland) предоставили эксклюзивные права PKP (Public Key Partners) на следующие патенты США и все соответствующие зарубежные патенты:

Криптографическое устройство и метод (Diffie-Hellman) No. 4,200,770

Устройство и метод для криптографии с общедоступным ключом (Hellman-Merkle) No. 4,218,582

Криптографическая коммуникационная система и метод (RSA) No. 4,405,829

Устройство и метод экспоненциальной криптографии (Hellman-Pohlig) No. 4,424,414

Эти патенты объявлены PKP покрывающими все известные методы шифрования с общедоступным ключом, включая вариации, базирующиеся на алгоритме Эль Гамаля.

Группа PKP предоставила письменные гарантии Интернет сообществу, что участники могут получить на разумных не дискриминирующих условиях права на использование технологий, покрываемых этими патентами. Эта гарантия представлена в документе RFC 1170 "Public Key Standards и Licenses". Данный документ датирован 20 апреля 1990, и может быть получен в IANA (Internet Assigned Number Authority).