Профайлы сертификатов

В таблице 4.6.2.33 представлен полный список сертификатов необходимых SET.

Программа Sendmail

4.4.14.5 Программа Sendmail

Одной из досадных особенностей программы Sendmail является огромное количество опций. К счастью большинство из них обычно не используются. Иной раз может показаться, что назначение некоторых опций знает только их автор. Часть этих опций служит для тестирования конфигурационного файла и файла псевдонимов. Такие опции как -bt и -bv используются при изменении конфигурационного файла, чтобы гарантировать, что новые наборы правил работают безошибочно. Наиболее важные опции служат администратору для установления отладочного уровня (-d#), или для установки программы в фоновый режим или режим демона (-bd), или для установки самого отладочного режима (-v).

Почтовая программа sendmail должна запускаться в фоновом режиме с помощью строки в стартовом скрипте. Например:

/usr/lib/sendmail -bd -q30m

Эта командная строка предлагает обрабатывать занесенные в очередь сообщения каждые 30 минут. Время после опции -q может быть задана как произвольная комбинация дней, часов, минут и секунд. В этом случае за числами должны следовать соответственно символы d, h, m или s. Так, например, запись: -q1d2h30m15s указывает, что очередь будет обрабатываться с периодичностью 1 день, 2 часа, 30 минут и 15 секунд.

Конфигурационный файл sendmail является читаемым текстовым. Этот файл начинается с перечня опций и макросов, далее следует набор правил. Эти правила определяют метод дешифровки адресов почтовых сообщений. Обычно настройке подвергаются опции и макросы.

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

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

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

Опция OL# определяет уровень работы журнала операций. Эта опция управляет объемом информации, которая записывается в log-файл при работе программы sendmail. Чем больше число, проставленное вместо символа #, тем больше информации будет записано. Наибольшему уровню соответствует цифра 9.

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

Опции Or<время> и OT<время> являются опциями таймаута. Опция ОТ производит запись проблемного сообщения в очередь и осуществляет повторную попытку через специфицированный промежуток времени, прежде чем отправитель будет проинформирован о неудаче. Опция Or специфицирует значение таймаута для операций чтения. Если при получении почты от удаленной ЭВМ возникает пауза, в течение которой не приходит ничего, sendmail по истечение заданного времени прерывает процесс и закрывает соединение. Так как эта опция, вообще говоря, нарушает стандарт RFC-821, значение таймаута должно быть достаточно велико.

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

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

Опция -о или Оо означает, что имена получателей могут разделяться пробелами (стандарт требует применения запятых).

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

Привилегированные пользователи могут изменить имя поля From, которое используется при посылке сообщений об ошибках. Это имя может быть изменено с помощью команды –f<пользователь>.

Файл alias обычно размещается в каталоге /usr/lib/aliases и служит для создания почтовых ящиков, которым не соответствует никакой аккоунт пользователя. В этом файле определяется, в какой почтовый ящик следует направлять сообщение, адресованное субъекту с указанным псевдонимом. Допускается направление сообщений вместо какого-либо почтового ящика на stdin. Стандартная строка переадресации в этом файле выглядит как.

alias: имя_пользователя или

alias: имя_пользователя_1, имя_пользователя_2, имя_пользователя_3, …

Первая строка перенаправляет все сообщения, адресованные alias пользователю с указанным именем. Второй пример соответствует случаю, когда все сообщения, адресованные alias переадресовываются всем пользователям из предлагаемого списка. Этот список может быть продолжен на следующей строке, если пред CR ввести символ \. В качестве имен пользователей могут быть записаны полные почтовые адреса типа vanja.ivanov@somewhere.ru или локальное имя. Для особо длинных списков имен можно указать файл, где этот список содержится. Для этого в файл /usr/lib/aliases нужно занести стоку типа.

Participants: “:include:/usr/local/lib/participants.list”

Обычно желательно включать псевдоним “почтмейстера” и администратора. Когда пользователь на удаленной ЭВМ не может найти имя аккоунта или ЭВМ, он может послать запрос по одному из этих псевдонимов.

Одной из наиболее эффективных (и опасных в то же самое время) особенностей файла alias является возможность перенаправлять приходящую почту программе, базирующейся на псевдониме. Когда первый символ имени аккоунта в псевдониме является вертикальной чертой (|), имя воспринимается как наименование программы, которой следует передать управление. Приходящее сообщение будет передано этой программе, как если бы этот текст был введен с консоли. В файле псевдонимов вертикальная черта работает также как в ядре UNIX. Таким образом, строка:

listserv: “|/usr/local/bin/listserv –l”

пошлет почтовый файл программе listserv, как если бы вы выполнили команду cat mailfile|listserv –l. В действительности так работают серверы подписных листов (LISTSERV). Администратор устанавливает псевдоним, а программа listserv транслирует строку поля Subject или тела сообщения в качестве команды, управляющей работой почтового сервера рассылки. Следует иметь в виду, что эта техника представляет достаточно серьезную угрозу безопасности. По этой причине ее использование должно быть обставлено соответствующими мерами (например, аутентификацией с использованием шифрованных паролей).

Программирование для сетей (новые идеи, принципы и возможности)

7 Программирование для сетей (новые идеи, принципы и возможности)

Volk und Knecht und Uberwinder

Sie gestehn zu jeder Zeit

Hochtest Gluck der Erdenkinder

Sie nur die Personlichkeit

В. Гёте

Программирование - искусство индивидуальное, но сетевое программирование имеет много специфических особенностей, требующих выполнения определенных правил. Оно в значительной мере напоминает написание программ реального времени, так как здесь также приходится иметь дело с постоянно изменяющимися обстоятельствами. Заметные отличия возникают из-за работы в разных операционных системах (DOS, UNIX, Windows, OS/2). Существуют задачи, которые даже сегодня лучше реализовать в ОС DOS. К таким задачам следует отнести хронометраж некоторых сетевых операций (к сожалению многозадачные и многопользовательские системы довольно часто вносят ошибки в результаты временных измерений с использованием внутренних машинных часов). Кроме того, в рамках, например, ICMP.DLL нельзя послать очередной пакет до тех пор, пока не истечет таймаут или не будет получен отклик. Это также создает некоторые трудности. Да и библиотека RAWSOCK не у каждого под рукой. Если задача может быть решена в рамках Windows, ничего другого и не нужно (при всех бесчисленных недостатках эта среда наиболее дружественна к пользователю). В крайнем случае, можно без особого труда перенести ваше приложение в Windows NT или OS/2. Если же вы разрабатываете нечто для многопользовательской среды, стоит подумать о работе под ОС UNIX. Новейшие пакеты для работы с соединителями (socket) заметно облегчают работу программисту. Современные соединители (см. http: //www.stardust.com/wsresource/winsock2/ws2ident.html) способны настраиваться на протокольный набор (это не обязательно TCP/IP) и на конкретный протокол. Библиотеки допускают работу как IPv4 так и с IPv6, необходимо лишь корректно задать параметры. Идеология соединителей, пришедшая из UNIX, и унификация библиотек для работы с ними заметно облегчают перенос программ из одной ОС в другую. Сегодня программист, даже не вникая в особенности протокола, за счет использования стандартных библиотек может создать программу любого приложения. Современная среда программирования, особенно в Windows, позволяет сформировать и удобный интерфейс для работы с разрабатываемым приложением. Новейшие версии библиотек для работы с соединителями позволяют запускать и управлять несколькими процессами ввода/вывода одновременно.

Следует иметь в виду, что, например, в системе UNIX все виды Интернет услуг обслуживает демон inetd. Конкретный запрос (telnet, FTP, finger и т.д.) поступает именно к нему, inetd резервирует номер порта и запускает соответствующий процесс, после чего переходит в режим ожидания новых запросов. Такая схема позволяет эффективно и экономно работать со стандартными номерами портов.

Практически любая утилита использует в качестве параметра имя какого-либо узла или ЭВМ. По этой причине исполнение программы начинается с посылки запроса серверу имен (DNS). После получения нужного IP-адреса посылается ARP-запрос. Далее формируется соединитель и посылается запрос, который зависит от типа реализуемого приложения.

В следующих двух статьях рассмотрено программирование для DOS (непосредственная работа с драйвером сетевого интерфейса) и программирование для Windows. Программирование для UNIX во многом сходно с программированием для Windows, так как здесь используется сходная библиотека для работы с соединителями.

Протокол электронной почты SMTP

4.4.14 Протокол электронной почты SMTP

Главной целью протокола simple mail transfer protocol (SMTP, RFC-821, -822) служит надежная и эффективная доставка электронных почтовых сообщений. SMTP является довольно независимой субсистемой и требует только надежного канала связи. Средой для SMTP может служить отдельная локальная сеть, система сетей или весь Интернет.

SMTP базируется на следующей модели коммуникаций: в ответ на запрос пользователя почтовая программа-отправитель устанавливает двухстороннюю связь с программой-приемником (TCP, порт 25). Получателем может быть оконечный или промежуточный адресат. SMTP-команды генерируются отправителем и посылаются получателю. На каждую команду должен быть отправлен и получен отклик.

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

tn dxmint.cern.ch 25 (команда telnet с использованием порта 25)

220 dxmint.cern.ch sendmail ready at sun, 9 jul 1995 11:13:57 +0200 (связь установлена, код отклика 220 является положительным)

EHLO dxmint.cern.ch	(поддерживает ли сервер расширение mime?)
500 command unrecognized	(не поддерживает)
HELO crnvma.cern.ch	(команда выхода на конкретный сервер)

250 dxmint.cern.ch hello crnvma.cern.ch, pleased to meet you (отклик 250 также является положительным)

mail from:<> (так как на моей PC нет резидентной почтовой программы, я не указываю обратного адреса)

250 <>... sender ok	(команда прошла успешно)
RCPT TO: ysemenov@cernvm.cern.ch	(указываем адрес места назначения)

Почтовое сообщение отправлено без использования

/p> 250 ... recipient ok

DATA	(начало ввода текста сообщения)
nu-i-nu...	(текст сообщения)
.	(знак конца сообщения)
QUIT	(прерывание или завершение процедуры)

221 dxmint.cern.ch closing connection (сообщение об успешном завершении процедуры)

Почтовое сообщение отправлено без использования доступа к локальной почтовой программе (mail на sun, например). Следует отметить, что работа через порт 25 в данном случае открывает богатые возможности для хакеров. Вообще умелый программист может многого достичь, используя номера портов. Здесь есть над чем поработать людям, ответственным за безопасность сетей. Аналогично, не имея авторизации, можно выявить клиентов почтового сервера, используя команду VRFY:

tn ns.itep.ru 25

220 ns.itep.ru 5.67a8/ida-1.5 sendmail is ready at sat, 29 jul 1995 13:53:03

vrfy bobyshev

250 andrey bobyshev

и т.д.

quit

SMTP-отправитель и SMTP-получатель могут вести диалог с несколькими оконечными пользователями (Рисунок 4.4.14.1). Любое почтовое сообщение завершается специальной последовательностью символов. Если получатель успешно завершил прием и обработку почтового сообщения, он посылает положительное подтверждение.

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

Протокол SLIP

3.4 Протокол SLIP

Протокол SLIP (Serial Line IP, RFC-1055) – это простейший способ инкапсуляции IP-дейтограмм для последовательных каналов связи. Этот протокол стал популярным благодаря возможностям подключения домашних персональных машин к сети Интернет через порт RS-232, который соединен с модемом. IP-дейтограмма в случае SLIP должна завершаться специальным символом 0xC0, называемым конец. Во многих реализациях дейтограмма и начинается с этого символа. Если какой-то байт дейтограммы равен символу конец, то вместо него передается двухбайтовая последовательность 0xDB, 0xDC. Октет 0xDB выполняет в SLIP функцию ESC-символа. Если же байт дейтограммы равен 0xDB, то вместо него передается последовательность 0xDB, 0xDD. Использование протокола SLIP предполагает выполнение ряда условий:

Каждый партнер обмена должен знать IP-адрес своего адресата, так как не существует метода обмена такого рода информацией.

SLIP в отличии от Ethernet не использует контрольных сумм, поэтому обнаружение и коррекция ошибок целиком ложится на программное обеспечение верхних уровней.

Так как кадр SLIP не имеет поля тип, его нельзя использовать, в отличии от кадров Ethernet, для реализации других протоколов методом инкапсуляции.

Впервые протокол SLIP был применен в 1984 году в 4.2BSD. Скорость передачи информации при использовании протокола SLIP не превышает 19.2кб/с, что обычно достаточно для интерактивного обмена в рамках протоколов telnet или RLOGIN. Максимальный размер передаваемого блока (MTU) для SLIP лежит вблизи 256-512 байт, что обеспечивает разумный компромисс между значением задержки отклика (~256мс.) и эффективностью использования канала (~98% для CSLIP). При этом для передачи одного символа (нажатая клавиша) используется 20 байт заголовка в IP-дейтограмме и 20 байт TCP-заголовка. Если мы учтем издержки формирования SLIP-кадра, накладные расходы превосходят 40 байт. Частично этот недостаток устранен в новой версии CSLIP (Compressed SLIP, RFC-1144, предложенной Джекобсоном в 1990 году). В CSLIP заголовок сокращается до 3-5байт (против 40 в SLIP). Эта версия протокола способна поддерживать до 16 TCP-соединений на каждом из концов последовательного канала. Многие современные SLIP-драйверы поддерживают и CSLIP.

3.4.1. Протоколы RS

Протоколы RS (RS-232, RS-449, RS-423-А, RS-422-А и RS-485) относятся к семейству рекомендованных протоколов (буква R в названии обозначает recommended). RS-232 обеспечивает дуплексную связь и скорость передачи 19,2 кбит/с при длине связи до 15м. На практике при расстояниях порядка 10 метров можно получить быстродействие канала более 100кбит/с. Здесь обеспечивается связь точка-точка. Логической 1 соответствует уровень сигнала -(5-15)В, а логическому нулю +(5-15)В. В отличии от других упомянутых выше стандартов, которые допускают скорости обмена до 10Мбит/с (при длине линии 15м), данный протокол из-за низкой скорости обмена работает без использования симметричных сигналов на скрученной паре канала связи. Более подробную информацию можно найти, например, в http://ixbt.stack.net/comm/rs_proto.html. Разводка разъема приведена в приложении.

Стандарт RS-449 представляет собой в действительности семейство, состоящее из 3-х стандартов. Механическая, функциональная и процедурная часть содержится в самом RS-449, а регламентации электрического интерфейса описаны в RS-423-A (подобен RS-232-C) дле схемы с общей землей. Балансная симметричная схема интерфейса представлена в документе на RS-422-A, для для передачи каждого сигнала используется два провода, что позволяет достичь быстродействия 2Мбит/с при длине соединения до 60м. Разводка разъемов представлена в приложении .

Протокол SNTP

4.4.16 Протокол SNTP

Протокол SNTP V 4 отличается от предыдущей версии NTP и SNTP (Simple Network Time Protocol (SNTP) V.4 for IPv4, IPv6 and OSI, D. Mills, RFC-2030) модификацией интерпретации заголовка с целью осуществления совместимости адресации с IPv6 [DEE96] и OSI [COL94].

1. Введение

Протокол сетевого времени (NTP v3), описанный в документе RFC-1305 [MIL92], широко используется для синхронизации часов ЭВМ в глобальном Интернет. Он обеспечивает доступ к национальным системам точного времени. В большинстве мест Интернет протокол гарантирует точность синхронизации с точностью 1-50 мс, в зависимости от свойств источника синхронизации и сетевых задержек.

RFC-1305 специфицирует машину протокола NTP v3 в терминах событий, состояний, функций перехода и действий. Кроме того, там определены инженерные алгоритмы улучшения точности синхронизации и выбора из списка эталонных источников, некоторые из которых могут быть неисправны. Эти алгоритмы необходимы для компенсации влияния вариаций задержки пакетов в сети Интернет. Однако, во многих обстоятельствах приемлемы точности порядка доли секунды. В таких случаях используется более простые протоколы времени [POS83]. Эти протоколы обычно использует RPC-обмен, где клиент запрашивает время дня, а сервер присылает его значение в секундах после некоторого известного эталонного момента.

NTP создан для использования клиентами и серверами с широким диапазоном возможностей для широкого интервала сетевых задержек и большого временного разброса. Большинство пользователей NTP синхронизации используют программное обеспечение с полным набором опций и алгоритмов (смотри http://www.eecis.udel.edu/~ntp).

SNTP v 4 предполагает совместимость с NTP и SNTP v 3 как для клиентов так и для серверов. Кроме того, клиенты и серверы SNTP v.4 могут реализовывать расширения для работы в эникаст режиме.

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

2. Рабочие режимы и адресация

SNTP v.4 может работать в уникастном (точка-точка), мультикастном (один передатчик – много приемников) или эникаст (несколько передатчиков - один приемник). Уникастный клиент посылает запросы специально выделенному серверу по его уникастному адресу и ожидает отклика, из которого он может определить время и опционно RTT, а также сдвижку временной шкалы местных часов по отношению к шкале сервера. Мультикастный сервер периодически посылает сообщения по локальному мультикаст-адресу (IPv4 или IPv6). Мультикастный клиент воспринимает получаемые данные и не посылает никаких запросов. Эникастный клиент посылает запрос по локальному специально выделенному мультикастному (IPv4 или IPv6) адресу, при этом один или более эникатных серверов отправляют клиенту отклик. Клиент связывается с первым из них и в дальнейшем продолжает работу уже в уникастном режиме адресации.

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

В уникастном режиме адреса клиенту и серверу присваиваются согласно обычной схеме IPv4, IPv6 или OSI. В мультикастном режиме сервер использует локальный широковещательный адрес или мультикастный групповой адрес. Локальный широковещательный IP-адрес имеет область действия, ограниченную субсетью, так как маршрутизаторы не ретранслируют широковещательные IP-дейтограммы. С другой стороны IP-адрес мультикастинг-группы имеет область действия, распространяющуюся потенциально на весь Интернет. Для IPv4 iana для целей NTP выделила мультикастный групповой адрес 224.0.1.1, который используется как для мультикаст серверов, так и для эникаст клиентов.

Мультикастные клиенты прослушивают выделенный локальный широковещательный адрес или мультикастный групповой адрес. В случае мультикастного IP-адреса, мультикастный клиент и эникастный сервер должны реализовать протокол IGMP (Internet Group Management Protocol) [DEE89], для того чтобы местный маршрутизатор подключился к мультикаст-группе и ретранслировал сообщения, направленные по IPv4 или IPv6 мультикастным групповым адресам, присвоенным IANA.

Очень важно оптимально выбрать значение поля TTL в IP-заголовке мультикастинг-сообщения, для того чтобы ограничить сетевые ресурсы, используемые данным видом сервиса.

Режим эникаст сконструирован для использования с набором взаимодействующих серверов, чьи адреса не известны клиенту заранее. Эникастный клиент посылает запрос по локальному широковещательному адресу или групповому мультикастинг-адресу. Для этой цели используется групповой адрес NTP специально выделенный iana для этих целей. Один или более эникастных серверов воспринимают этот запрос и отправляют отклик по уникастному адресу клиента. Клиент устанавливает связь с сервером, от которого получил отклик раньше. Последующие отклики эникаст-серверов игнорируются.

В случае SNTP, существует реальная угроза того, что SNTP мультикаст-клиент может быть введен в заблуждение поведением SNTP или NTP-серверов (возможно и преднамеренным), так как все они используют один и тот же групповой мультикаст-адрес, выделенный для этих целей IANA. Где необходимо, для выбора сервера, известного клиенту может проводиться отбор по адресу. Опционной является схема криптографической аутентификации, описанной в документе RFC-1305.

3. Формат временных меток NTP

Протокол SNTP использует стандартный формат временных меток NTP, описанный в документе RFC-1305 и в предыдущих версиях стандарта. Для согласования со стандартной практикой в Интернет данные NTP характеризуются целыми числами с фиксированной запятой. Биты нумеруются так, что нулевой (старший) разряд размещается слева. Если не оговорено обратного, все числа не имеют знака и занимают все выделенное для них поле.

Так как временная метка NTP представляет собой наиважнейшую часть протокола, для нее разработан специальный формат. Временные метки NTP характеризуются 64-битным числом без знака с фиксированной запятой, которое равно количеству секунд с 0 часов 1 января 1900. Для целочисленной части выделено 32 бита и столько же для дробной части.

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

Максимальное число, которое может быть представлено в данном формате равно 4,294,967,295 секунд с точностью порядка 200 пикосекунд, что может удовлетворить самым экзотическим требованиям.

Протокол SSL Безопасный уровень соединителей

6.5 Протокол SSL. Безопасный уровень соединителей

Протокол SSL спроектирован для обеспечения конфиденциальности обмена между двумя прикладными процессами клиента и сервера (см. http://www.netscape.com/eng/security/SSL_2.html). Он предоставляет возможность аутентификации сервера и, опционно, клиента. SSL требует применения надежного транспортного протокола (например, TCP).

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

Протокол SSL предоставляет "безопасный канал", который имеет три основные свойства:

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

Канал аутентифицирован. Серверная сторона диалога всегда аутентифицируется, в то время как клиентская – аутентифицируется опционно.

Канал надежен. Транспортировка сообщений включает в себя проверку целостности (с привлечением MAC).

6.5.1. Спецификация протокола записей SSL

6.5.1.1. Формат заголовка записи SSL

В SSL все данные пересылаются в виде рекордов (записей), объектов, которые состоят из заголовка и некоторого количества данных. Каждый заголовок рекорда содержит два или три байта кода длины. Если старший бит в первом байте кода длины рекорда равен 1, тогда рекорд не имеет заполнителя и полная длина заголовка равна 2 байтам, в противном случае рекорд содержит заполнитель и полная длина заголовка равна 3 байтам. Передача всегда начинается с заголовка.

Заметим, что в случае длинного заголовка (3 байта), второй по старшинству бит первого байта имеет специальное значение. Когда он равен нулю, посылаемый рекорд является информационным.
Когда рекорды SSL посылаются открытым текстом, никаких шифров не используется. Следовательно, длина PADDING-DATA будет равна нулю и объем MAC-DATA также будет нулевым. Когда используется шифрование, PADDING-DATA является функцией размера блока шифра. MAC-DATA зависит от CIPHER-CHOICE. MAC-DATA вычисляется следующим образом:

MAC-DATA = HASH[ SECRET, ACTUAL-DATA, PADDING-DATA, SEQUENCE-NUMBER ]

Где SECRET передается хэш-функции первым, далее следует ACTUAL-DATA и PADDING-DATA>, за которыми передается SEQUENCE-NUMBER. Порядковый номер (SEQUENCE-NUMBER) представляет собой 32-битовый код, который передается хэш-функции в виде 4 байт. Первым передается старший байт (т.е., используется сетевой порядок передачи - "big endian").

MAC-SIZE является функцией используемого алгоритма вычисления дайджеста. Для MD2 и MD5 MAC-SIZE равен 16 байтам (128 битам).

Значение SECRET зависит оттого, кто из партнеров посылает сообщение. Если сообщение посылается клиентом, тогда SECRET равен CLIENT-WRITE-KEY (сервер будет использовать SERVER-READ-KEY для верификации MAC). Если клиент получает сообщение, SECRET равен CLIENT-READ-KEY (сервер будет использовать SERVER-WRITE-KEY для генерации MAC).

SEQUENCE-NUMBER является счетчиком, который инкрементируется как сервером, так и получателем. Для каждого направления передачи, используется пара счетчиков (один для отправителя, другой для получателя). При отправлении сообщения счетчик инкрементируется. Порядковыми номерами являются 32-битовые целые числа без знака, которые при переполнении обнуляются.

Получатель сообщения использует ожидаемое значение порядкового номера для передачи хэш-функции MAC (тип хэш-функции определяется параметром CIPHER-CHOICE). Вычисленная MAC-DATA должна совпадать с переданной MAC-DATA. Если сравнение не прошло, рекорд считается поврежденным, такая ситуация рассматривается как случай "I/O Error" (т.e. как непоправимая ошибка, которая вызывает закрытие соединения).

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

Объем данных в рекорде (RECORD-LENGTH) должен быть кратным размеру блока шифра. Если полученный рекорд не кратен размеру блока шифра, рекорд считается поврежденным, при этом считается, что имела место "I/O Error" (что вызовет разрыв соединения).

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

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

Прежде чем послать первый рекорд SSL все порядковые номера делаются равными нулю. При передаче сообщения порядковый номер инкрементируется, начиная с сообщений CLIENT-HELLO и SERVER-HELLO.

6.5.2. Спецификация протокола диалога SSL

6.5.2.1. Протокол диалога SSL

Протокол диалога SSL имеет две основные фазы. Первая фаза используется для установления конфиденциального канала коммуникаций. Вторая - служит для аутентификации клиента.

Фаза 1

Первая фаза является фазой инициализации соединения, когда оба партнера посылают сообщения "hello". Клиент инициирует диалог посылкой сообщения CLIENT-HELLO. Сервер получает сообщение CLIENT-HELLO, обрабатывает его и откликается сообщением SERVER-HELLO.

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

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

Клиент генерирует мастерный ключ и посылает сообщение CLIENT-MASTER-KEY ( или сообщение ERROR, если информация сервера указывает, что клиент и сервер не могут согласовать базовый шифр).

Здесь следует заметить, что каждая оконечная точка SSL использует пару шифров для каждого соединения (т.е. всего 4 шифра). На каждой конечной точке, один шифр используется для исходящих коммуникаций и один - для входящих. Когда клиент или сервер генерирует ключ сессии, они в действительности формируют два ключа, SERVER-READ-KEY (известный также как CLIENT-WRITE-KEY) и SERVER-WRITE-KEY (известный также как CLIENT-READ-KEY). Мастерный ключ используется клиентом и сервером для генерации различных ключей сессий.

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

Фаза 2

Вторая фаза является фазой аутентификации. Сервер уже аутентифицирован клиентом на первой фазе, по этой причине здесь осуществляется аутентификация клиента. При типичном сценарии, серверу необходимо получить что-то от клиента, и он посылает запрос. Клиент пришлет позитивный отклик, если располагает необходимой информацией, или пришлет сообщение об ошибке, если нет. Эта спецификация протокола не определяет семантику сообщения ERROR, посылаемого в ответ на запрос сервера (например, конкретная реализация может игнорировать ошибку, закрыть соединение, и т.д. и, тем не менее, соответствовать данной спецификации). Когда один партнер выполнил аутентификацию другого партнера, он посылает сообщение finished. В случае клиента сообщение CLIENT-FINISHED содержит зашифрованную форму идентификатора CONNECTION-ID, которую должен верифицировать сервер. Если верификация терпит неудачу, сервер посылает сообщение ERROR.

Раз партнер послал сообщение finished он должен продолжить воспринимать сообщения до тех пор, пока не получит сообщение finished от партнера.Как только оба партнера послали и получили сообщения finished, протокол диалога SSL закончил свою работу. С этого момента начинает работать прикладной протокол.

6.5.2.2. Типовой протокол обмена сообщениями

В несколько упрощенном варианте диалог SSL представлен на Рисунок 6.5.1.

Протокол управления SNMP

4.4.13 Протокол управления SNMP

Интернет - гигантская сеть. Напрашивается вопрос, как она сохраняет свою целостность и функциональность без единого управления? Если же учесть разнородность ЭВМ, маршрутизаторов и программного обеспечения, используемых в сети, само существование Интернет представится просто чудом. Так как же решаются проблемы управления в Интернет? Отчасти на этот вопрос уже дан ответ – сеть сохраняет работоспособность за счет жесткой протокольной регламентации. "Запас прочности" заложен в самих протоколах. Функции диагностики возложены, как было сказано выше, на протокол ICMP. Учитывая важность функции управления, для этих целей создано два протокола SNMP(Simple Network Management Protocol, RFC-1157, -1215, -1187, -1089 разработан в 1988 году) и CMOT (Common Management Information services and protocol over TCP/IP, RFC-1095, в последнее время применение этого протокола ограничено). Обычно управляющая прикладная программа воздействует на сеть по цепочке SNMP-UDP-IP-Ethernet. Наиболее важным объектом управления обычно является внешний порт сети (gateway) или маршрутизатор сети. Каждому управляемому объекту присваивается уникальный идентификатор.

Протокол snmp работает на базе транспортных возможностей UDP и предназначен для использования сетевыми управляющими станциями. Он позволяет управляющим станциям собирать информацию о положении в сети Интернет. Протокол определяет формат данных, а их обработка и интерпретация остаются на усмотрение управляющих станций или менеджера сети. SNMP-сообщения не имеют фиксированного формата и фиксированных полей. При своей работе SNMP использует управляющую базу данных (MIB - management information base, RFC-1213, -1212).

Алгоритмы управления в Интернет обычно описывают в нотации ASN.1 (Abstract Syntax Notation). Все объекты в Интернет разделены на 10 групп и описаны в MIB: система, интерфейсы, обмены, трансляция адресов, IP, ICMP, TCP, UDP, EGP, SNMP. В группу "система" входит название и версия оборудования, операционной системы, сетевого программного обеспечения и пр.. В группу "интерфейсы" входит число поддерживаемых интерфейсов, тип интерфейса, работающего под IP (Ethernet, LAPB etc.), размер дейтограмм, скорость обмена, адрес интерфейса. IP-группа включает в себя время жизни дейтограмм, информация о фрагментации, маски субсетей и т.д. В TCP-группу входит алгоритм повторной пересылки, максимальное число повторных пересылок и пр.. Ниже приведена таблица (4.4.13.1) команд (pdu - protocol data unit) SNMP:

Работа с сертификатами

В работе с сертификатами участвуют девять субъектов. Иерархия этих субъектов представлена на Рисунок 4.6.2.10. Верхнюю позицию в иерархии занимает корневой центр сертификации. Корневой сертификат следует требованиям документа X.509 (версия 3) с некоторыми расширениями, вводимыми протоколом SET. Прежде чем система будет развернута, должны быть проделаны следующие операции:

Нужно сформировать пару #1 корневых ключей R1

Сгенерировать сертификат для корневого ключа #1 (C1)

Сформировать пару #2 корневых ключей R2

Вычислить оттиск (хэш – H2) общедоступной составляющей R2

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

Когда приходит время заменить корневой сертификат R1, производятся следующие операции:

Вычисляется общедоступная часть корневого ключа #3 (R3)

Определяется оттиск R3 (хэш H3)

Формируется сертификат корневого ключа #2 (C2 – содержит H3)

Новый корневой сертификат рассылается с использованием SET-сообщений или методик HTTP, FTP или SMTP. Приложение SET проверяет подпись, используя R2, вычисляет хэш R2 и сравнивает его с H2, полученным из расширения в С1.

Рассылка CRL

CRL представляет собой механизм, определенный Х.509, и предназначенный для публикации и рассылки списков выведенных из употребления сертификатов, срок действия которых еще не истек. Когда корневой СА актуализует свой CRL, он посылает его каждому центру сертификации платежной системы. Когда нижерасположенный центр сертификации актуализует свой CRL, он рассылает его своим СА платежных систем. CRL рассылаются в секции SignedData сообщений CRLNotification согласно следующему алгоритму.

Шаг	Действие
1	Сформировать CRLNotificationTBS: Занести в поле данные текущую дату Занести в CRLThumbprint оттиск, несущий в себе CRL
2	Подписать содержимое, используя сертификат подписи СА. Установить тип содержимого равным id-set-content-CRLNotificationTBS
3	Внести новый CRL в CRL-секцию SignedData. Вложить CRL в сертификационную секцию сообщения.
4	Закодировать и вложить в цифровой конверт подписанное сообщение CRLNotification. Следует заметить, что это не SET-сообщение. SignedData подвергается DER-кодированию и вкладывается в цифровой конверт MIME.

CRL-Notification-сообщение содержит следующие поля:

Название поля	Описание
CRL-Notification	S(CA, CRLNotificationTBS)
CRL-NotificationTBS	{Date, CRLThumbprint}
Дата	Дата, когда сформировано сообщение
CRLThumbprint	Оттиск CRL, заключенный в CRL-секцию SignedData

При получении сообщения CRL Notification СА платежной системы проверяет и анализирует его следующим образом:

Шаг	Действие
1	Если дата раньше, чем для любого предыдущего CRL, полученного от этого СА, сообщение проигнорировать и откликнуться отправившему СА сообщением Error c кодом ошибки badDate.
2	Если CRL-оттиск не согласуется с тем, который записан в CRL-секции SignedData, сообщение проигнорировать и откликнуться отправившему СА сообщением Error c кодом thumbMismatch.
3	Запомнить модифицированный CRL и послать СА платежной системы для добавления в последующее сообщение рассылки BCI.

CA платежной системы формирует отклик CRL Notification согласно следующему алгоритму:

Шаг	Действие
1	Заполнить NotificationResTBS: Вставить дату из сообщения CRLNotification Вставить оттиск полученного CRL
2	Подписать содержимое, используя сертификат подписи центра сертификации платежной системы. Установить contenttype равным id-set-content-CRLNotificationResTBS
3	Закодировать и вложить в цифровой конверт подписанное сообщение CRLNotificationRes в форме согласованной с транспортным механизмом. Послать сообщение отклика CRLNotification запросившему СА.

Сообщение-отклик CRLNotification содержит следующие поля.

Название поля	Описание
CRL-NotificationRes	S(CA, CRLNotificationTBS)
CRL-NotificationResTBS	{Date, CRLThumbprint}
Дата	Копируется из сообщения CRLNotification
CRLThumbprint	Оттиск CRL, копируется из сообщения CRLNotification

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

Разные варианты объединения локальных сетей

Рисунок .1. Разные варианты объединения локальных сетей

Быстродействие системы SMDS составляет 45 Мбит/с. Система SMDS использует передачу данных без установления соединения. Формат пакета SMDS показан на Рисунок .2.

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

Рисунок 4.6.2.3. Регистрация продавца.

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

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

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

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

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

Символы-префиксы	Участник сделки
C	Владелец карты (Cardholder)
M	Продавец (Merchant)
P	Расчетный центр (Payment Gateway)
CA	Сертификационный центр (Certificate Authority)

Рассмотрим диаграмму конечных состояний протокола SET (см. Рисунок 4.6.2.4).

Регистрация владельца карты в центре сертификации

Рисунок 4.6.2.2. Регистрация владельца карты в центре сертификации

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

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

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

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

Схема процедуры регистрации продавца показана на Рисунок 4.6.2.3 и содержит в себе 5 этапов.

SET и другие системы осуществления платежей

4.6.2 SET и другие системы осуществления платежей

Идеальная платежная система должна отвечать следующим требованиям:

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

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

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

Схема и реализация должны быть простыми (не нужно использовать сложных протоколов)

Система должна быть открытой (протоколы и тесты программ должны быть общедоступны).

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

Должна предоставлять достаточное количество данных для целей аудита.

Система должна быть свободной, то есть не иметь ограничений владельца.

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

А. Электронные монеты

Б. Электронные чеки

В. Электронные переводы (трансферты)

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

Сетевая безопасность

6 Сетевая безопасность

Номер раздела	Название раздела	Объем в страницах	Объем в кбайт
6	Сетевая безопасность	20	219
6.1	Технические средства сетевой безопасности	3	21
6.2	Виртуальные локальные сети VLAN, Интранет	4	26
6.3	Система Firewall	2	69
6.4	Системы шифрования	4	38
6.5	Протокол SSL. Безопасный уровень соединителей	21	37
6.6	Безопасное ядро (SSH)	2	9
6.7	Безопасность WEB-серверов	2	10
6.8	Протокол TLS версия 1.0	49	250
6.9	Квантовая криптография	6	54
6.10	Идентификатор доступа к сети	32	11

Совсем недавно персональная ЭВМ стоила в России дороже автомашины, сегодня же десятки (а может быть и сотни) тысяч ЭВМ работают дома, развлекая и зарабатывая деньги своим хозяевам. Сети ЭВМ из достояния научных центров постепенно стали обязательным атрибутом процветающих торговых фирм, банков, милиции, таможни, налоговые службы и т.д. Если раньше главной проблемой было создание сети и обеспечение доступа к Интернет, то сегодня по мере увеличения размеров сети проблема безопасности выходит на лидирующие позиции. Безопасность - комплексное понятие, это и ограничение нежелательного доступа, и сохранность информации, и живучесть самой сети. Актуальность проблемы подтверждает количество RFC-документов, опубликованных за последнее время [1-14, 18] по данной тематике (см. библиографию в конце данного раздела). Эту статью следует рассматривать как обзор возможных угроз и способов защиты. В основном это касается обычных сетей, не содержащих конфиденциальную или тем более секретную информацию. Но многие соображения, приводимые здесь, носят достаточно универсальный характер.

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

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

несанкционированные действия операторов удаленных ЭВМ.

Основу стабильности сети составляют надежность ЭВМ и сетевого оборудования, а также устойчивость каналов связи. Каналы связи, особенно если речь идет о проводных, достались нам от проклятого царизма, их создатели давно умерли, и спросить не с кого. Начинать надо с того, что в вашей власти, а это, прежде всего, правильная конфигурация узла, разумное распределение ответственности и качество сетевого питания (стабильность напряжения и частоты, амплитуда помех). Для решения последней проблемы используют специальные фильтры, мотор-генераторы и UPS (uninterruptable power supply). Выбор того или иного решения зависит от конкретных условий, но для серверов использование UPS крайне желательно (ведь вы не хотите восстанавливать дисковую систему, которая разрушилась из-за отключения питания в момент записи в FAT или dir). При выборе UPS нужно учесть суммарную потребляемую мощность оборудования, подключаемого к источнику питания, и время, в течение которого UPS способен работать без напряжения в сети. При этом главная задача UPS - обеспечение завершения операций обмена с диском до того, как произойдет полное обесточивание сервера, или когда будет произведено переключение на резервный канал питания. Это осуществимо при использовании специального интерфейса и соответствующего программного обеспечения, работающего согласно протоколу SNMP. Указанный интерфейс обеспечит блокировку начала новых операций обмена или выполнит shutdown, если напряжение в сети упало ниже допустимого уровня. К UPS не следует подключать дисплеи (эти приборы не столь критичны к питанию, как диски и оперативная память) и принтеры (лазерные принтеры запрещено подключать к UPS из-за мощных печек, входящих в состав этих приборов). Сетевые фильтры являются желательными при работе с любыми ЭВМ, так как сеть в России сильно засорена высокочастотными помехами.

С использованием нанотехнологии фирма IBM разработала запоминающее устройство с плотностью записи данных 1 Терабит на квадратный дюйм.

Это позволяет записать 25 миллионов страниц или 25 DVD дисков на площади одной почтовой марки. Система использует тысячи сверх тонких иголок из кремния, которые служат для формирования миниатюрных углублений в тонкой синтетической пленке. Вершины иголок имеют размер нескольких атомов (диаметр ? 10нм). Технология допускает перезапись.Внедрение этой технологии на какое-то время решит проблему.

Поскольку абсолютная надежность недостижима, одним из средств сохранения информации является дублирование носителей (напр. дисков), копирование и сохранение копий в надежном месте. Если раньше для этой цели годились гибкие диски или магнитные ленты, сегодня их пригодность может быть подвергнута сомнению. Конечно, ленты типа exabyte емкостью 2.5-20 Гбайт достаточно широко используются, но относительно высокая стоимость таких накопителей ограничивает их применимость (да и скорость записи для них не слишком высока). Альтернативой им могут стать накопители с перезаписываемыми CD, где стоимость устройства несколько ниже, за то емкость одного диска для дешевых моделей пока не превосходит 1 Гбайт. Не исключено, что в скором времени основным средством сохранения информации станет ее дублирование на независимом жестком диске. Это может произойти при широком внедрении компактных жестких дисков емкостью 10 Гбайт и более.

К сожалению, помимо объективных причин на надежность и устойчивость работы сети влияет и субъективный фактор. Это, прежде всего некомпетентный персонал, различные компьютерные вирусы и хакеры. Скрытая безработица среди высоко квалифицированных программистов способствует распространению хакерства в России. Практическое отсутствие сетевых вирусов связано с ограниченностью сетей в России и со сложностью их написания, но этот барьер будет скоро преодолен и к этому следует готовиться уже сегодня. Еще в декабре 1994 года я получил предупреждение о распространении сетевых вирусов (good times и xxx-1) по Интернет:

“there are two virus infected messages circulated in the internet.

one is called " good times" and the other "xxx-1".

do not read !! do not download !!! delete right away !!!!”

(Не читайте!! Не загружайте!!! Немедленно уничтожайте!!!!)

Или еще один более свежий пример

"if you receive an email titled "it takes guts to say jesus" do not open it. it will erase everything on your hard drive. this information was announced yesterday morning from ibm; aol states that this is a very dangerous virus, much worse than "melissa," and that there is no remedy for it at this time."

ЭВМ, подключенная к сети, потенциально всегда уязвима. Есть сообщения о вирусе cascade в сетях Novell, созданы вирусы, переносимые с помощью электронной почты (например, вирусы, базирующиеся на макросах WinWord), и т.д. Последние наиболее опасны, так как, проглядывая какое-то очередное сообщение, содержащее приложение (attachment), клиент может и не предполагать, какую угрозу это таит. Макро-вирус может выполнять функцию "троянского коня". Тривиальным и одновременно крайне полезным советом является рекомендация стирать, не читая, сообщения, содержащие исполняемое приложение, даже если это сообщение получено от вашего хорошего знакомого (это может быть рассылка, выполняемая мактро-вирусом, через его адресную книгу). Если есть сомнения, позвоните вашему знакомому, или пошлите ему mail, прежде чем читать подозрительное послание.

Троянский конь. К этой категории относят две разновидности объектов. Один из них – программа, засылаемая в атакуемый узел, которая осуществляет перехват всего ввод с терминала, записывает эти данные в файл и позднее пересылает этот файл “хозяину этого коня”. Другой объект является пассивным, выглядит безопасным и привлекательным. Например, находится в каталоге FTP-депозитария games и выглядит как игра. Легковерный клиент может скопировать такой файл и попытаться его запустить. Результатом может стать уничтожение содержимого жесткого диска.

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

Сами по себе эти программы, как правило, не несут в себе разрушительных функций.

Черви. Программы, напоминающие “кроликов”, но способные перемещаться по сети Интернет от одного узла к другому (узлы должны иметь идентичную операционную среду).

Макро вирусы. Вирусы, базирующие на макросах таких систем, как excel или winword. Опасность таких вирусов заключается в том, что они могут разноситься электронной почтой, когда соответствующие файлы подсоединены к почтовому сообщению. Попытка просмотра текста excel или winword приводит к заражению ЭВМ этим вирусом. После чего такая машина может стать сама разносчиком вируса. Из-за простоты заражения этот тип вируса в настоящее время наиболее опасен. Кроме того, он может иметь все свойства "троянского коня", что усугубляет опасность.

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

Существуют и другие угрозы, например, так называемая “Молдавская связь”. Суть этой уловки, использованной впервые одним из провайдеров в Молдове, заключается в том, что в каком-то депозитарии или web-странице приводится ссылка на некоторый привлекательный объект, например набор эротических картинок. Но для их просмотра предлагается скопировать себе специальную программу. При запуске оговоренной программы канал связи с местным провайдером разрывается и устанавливается связь через модем с другим удаленным провайдером. Это особенно опасно для людей, подключенных к Интернет через модем, так как может стоить им многие сотни долларов за пользование междугородним телефоном.

Многие современные просмотрщики файлов (viewer) и вставные программы (plug-in), предоставляя определенные удобства, несут в себе ощутимые угрозы безопасности. Мало того, что они являются достаточно часто разносчиками вирусов, некоторые из них снабжены интерпретаторами команд. Такие интерпретаторы встраиваются, например, для создания справочной системы, но хакер может ввести туда свои, нужные только ему команды. А некоторые команды могут, скажем, разметить ваш диск. Подводя итоги, можно сказать, что всякая программа, имеющая макро процессор, потенциально опасна. По этой же причине следует избегать применения редактора emacs (UNIX) в качестве внешнего просмотрщика. Опасна и любая программа, способная запустить внешнее приложение. Примером такой программы можно назвать microsoft powerpoint, которая допускает во время презентации запуск любого приложения. Конфигурируя свою систему windows, не желательно объявлять powerpoint в качестве просмотрщика. И чем меньше программ просмотрщиков в системе, тем лучше для ее здоровья.

Современные WEB-серверы довольно широко используют java-аплеты. При этом должны строго выполняться определенные правила.

Аплеты не могут читаться с или писаться на локальный диск.

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

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

Аплеты не должны исполнять системных команд или запускать внешние программы.

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

Если все эти условия выполняются, аплеты совершенно безопасны, но контролировать это желательно.

При создании протоколов Интернет в начале 80-х годов авторы мало думали о безопасности. Предполагалось, что пользоваться сетью будут исключительно ответственные и добропорядочные люди. Но людям, к сожалению, свойственно преувеличивать свои положительные качества. Реальность оказалась не столь позитивна.

Сказалась и любовь получать что-то бесплатно и врожденный разрушительный потенциал. Некоторые приемы хакеров описаны в разделе, посвященном протоколу TCP. Рассмотрим, что может произойти, если будет получен TCP-сегмент с битами SYN и FIN, равными 1. При получении такого сегмента TCP осуществляет переход в состояние close_wait. Если до этого не было установлено соединений, переход в это состояние не должен производиться, но большинство реализаций выполняют его. Такой переход крайне не желателен, так как в этом состоянии не работает таймер и система останется в нем вечно.

Другой вид атак протокола TCP называется “syn flooding”. Здесь используется трехшаговый диалог при установлении соединения (SYN -> syn+ack -> ack; см. описание протокола TCP в разделе 4.4.3). Когда ЭВМ-1 получает запрос syn от ЭВМ-2, она должна подождать в частично открытом состоянии, по крайней мере, 75 секунд. Это позволяет успешно устанавливать связь даже в условиях очень больших сетевых задержек. Проблема заключается в том, что многие реализации способны отслеживать ограниченное число соединений (по умолчания 5). ЭВМ-злоумышленник может воспользоваться ограниченностью очереди и послать атакуемой ЭВМ большое число SYN-запросов, не отвечая на присылаемые SYN+ACK. В результате очередь будет быстро переполнена и прием запросов на соединение прекратится до тех пор, пока очередь не будет обслужена или очищена по таймауту. Данный метод пригоден для отключения ЭВМ от сети, во всяком случае, на 75 сек. Этот вид атаки часто является частью процедуры проникновения, когда нужно заблокировать ЭВМ от получения нежелательных откликов.

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

При установлении соединения оконечный сегмент, содержащий ACK, должен нести ISN (initial sequence number; cм. описание транспортного протокола TCP раздел 4.4.3) удаленной ЭВМ. Этот сегмент посылается ЭВМ, чей адрес указан в первоначальном запросе SYN. Хакер должен выяснить ISN каким-то иным способом (этому может помочь служба netstat). Так как ISN 32-разрядное число случайно угадать его совсем не просто. Но в большинстве систем (например, unix bsd) ISN берется из некоторого счетчика, содержимое которого увеличивается на 128 каждую секунду и на 64 после каждого нового соединения. Например:

x -> s: syn(ISNx)

s -> x: syn(ISNs), ack(ISNx) (получено искомое текущее значение кода ISNs)

Таким образом, установив однажды соединение с нужной ЭВМ (s), некоторое время спустя можно с высокой вероятностью угадать значение ISN, послав несколько пакетов с разными значениями ISN. При завершении процедуры посылается сегмент SYN+ACK, который будет отвергнут, так как машина получатель не инициализировала связь. В пакете отклике будет установлен флаг RST и соединение окажется абортированным. Чтобы этого не произошло, хакер может предпринять атаку типа syn-flooding, что приведет к игнорированию SYN+ACK. В результате соединение будет установлено и хакер, празднуя победу, может продолжить свое черное дело, например, он может исполнить какую-либо r-команду на атакуемой ЭВМ. Если даже изменять ISN каждые 4 микросекунды, проблему угадывания разрешить не удастся. Радикальным решением может стать лишь псевдослучайная генерация ISN-кодов (при этом случайным образом должны задаваться не менее 16 бит). Решить проблему поможет шифрование соответствующей части содержимого пакета. Рассмотрим здесь еще несколько таких атак.

Один из известных методов базируется на IP-опции “маршрутизации отправителя” (source routing). ЭВМ инициатор обмена может специфицировать маршрут, которым получатель должен воспользоваться при пересылке отклика. Маршрут может быть специфицирован так, чтобы он проходил через узел, контролируемый хакером.

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

Интересные возможности предоставляет вариант, когда хакер вставляет свою машину на пути обмена двух других узлов (hijacking). Обычные методы атак (типа spoofing) могут не привести к успеху из-за необходимости идентификации (пароль!). В данном методе хакер позволяет завершиться установлению связи и аутентификации и только после этого перехватывает контроль над виртуальным каналом. Этот способ использует механизм “десинхронизации” tcp-соединения. Когда порядковый номер полученного пакета не совпадает с ожидаемым значением, соединение называется десинхронизованным. Полученный пакет в зависимости от его номера будет выброшен или буферизован (если он находится в пределах окна). Таким образом, если узлы, участвующие в обмене сильно десинхронизованы, приходящие к ним пакеты будут отбрасываться. Хакер в этом случае может вводить пакеты с корректными порядковыми номерами. Разумеется, это совсем просто, если машина хакера является транзитной, что позволяет ей “портить” или удалять нормальные пакеты и подменять их своими. Атака же возможна и в случае, когда машина хакера находится где угодно. В этом случае “отброшенные” пакеты могут вызвать посылку ACK, которые содержат ожидаемое значение порядкового номера пакета, но и они будут отвергнуты из-за неверного их номера и т.д.. При реализации этой схемы пересылается большое число “лишних” пакетов ACK. Количество их будет сколь угодно велико, по этой причине данная ситуация называется “штормом ACK’. Обмен уведомлениями (ACK) о неверных ISN будет продолжаться до тех пор, пока один из таких пакетов не будет потерян. Механизм обмена IP-дейтограммами устроен так, что вероятность потери тем выше, чем больше пакетов передается, т.е. процесс саморегулируется. Тем не менее, высокая интенсивность потока сегментов ACK может говорить об атаке. В норме процент сегментов ACK от общего потока TCP составляет 30-45%.Иллюстрацией данного метода нападения может служить Рисунок 6.1.

Схема обмена сообщениями при получении сертификата между владельцем карты и ССА

Рисунок 4.6.2.12. Схема обмена сообщениями при получении сертификата между владельцем карты и ССА

Если ЕЕ уже имеет регистрационную информацию, обмены CardCInitReq/Res и RegFormReq/Res могут быть опущены. При работе через WWW используется во всех случаях полный перечень обменов. После того как приложение SET инициализировано, владелец карты посылает ССА сообщение CardCInitReq, указывающее через оттиски на сертификаты, CRL и BrandCRLIdentifier, которые содержаться в его кэше сертификатов. ССА реагирует посылкой сообщения CardCInitRes, содержащего любые сертификаты, CRL и BrandCRLIdentifier, которые потребуются владельцу карты для верификации подписи, а также сертификат шифрования, используемый для последующих сообщений.

Приложение SET формирует сообщение CardCInitReq следующим образом.

Шаг	Действие
1	Генерируется RRPID
2	Генерируется LID-EE
3	Формируется новый случайный Chall-EE
4	Копируется BrandID, который запомнен или получен в инициализирующем сообщении
5	Опционно заполняется поле Thumbs, которое содержит оттиски для каждого CRL, сертификатов SET, BrandCRLIdentifier и корневой сертификат, резидентный в кэше владельца карты
6	Формируется цифровой конверт сообщения, чтобы послать CardCInitReq центру ССА

Структура сообщения CardCInitReq охарактеризована в таблице 4.6.2.17.

Рисунок 4.6.2.13. Схема обмена сообщениями при получении сертификата между продавцом и MCA или между платежным центром и PCA

При получении Me-AqCInitRes программа конечного пользователя (ЕЕ) может послать сообщение CertReq, содержащее заполненную форму. Процедура формирования Me-AqCInitReq включает в себя следующие операции:

Шаг	Действие
1	Сформировать новый RRPID
2	Сформировать новый LID-EE
3	Сформировать новый случайный код Chall-EE
4	Занести BrandID, который хранится в приложении или получен в стартовом сообщении
5	Заполнить поле RequestType
6	Заполнить поле Language (язык)
7	Опционно создать оттиски для каждого CRL, сертификата, BrandCRLIdentifier и корневого сертификата, резидентно размещенных в кэше (если имеются)
8	Если ЕЕ (конечным пользователем) является продавец, заполнить поля BIN и ID продавца. В противном случае BIN получателя и его рабочий ID.
9	Сформировать цифровой конверт и послать сообщение Me-AqCInitReq СА.

Формат сообщения Me-AqCInitReq представлен в таблице 4.6.2.22.

Схема вычисления и верификации электронной подписи (DSA)

Рисунок 6.4.3.1. Схема вычисления и верификации электронной подписи (DSA)

DSA использует следующие параметры (www.itl.nist.gov/div897/pubs/fip186.htm):

p – простое число, которое при 512Ј L Ј 1024 удовлетворяет условию 2L-1 < p < 2L, L кратно 64.

q – простой делитель p-1, где 2159 < q < 2160.

g = h(p-1)/q mod p, где h любое целое, для которого 1 < h < p-1 и h(p-1)/q mod p > 1.

x равно случайному или псевдослучайному целому числу, для которого 0 < x < q.

y = gx mod p.

k равно случайному или псевдослучайному целому числу, для которого 0 < k < q.

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

Подпись сообщения M представляет собой два числа r и s, вычисленные согласно формулам:

r = (gk mod p) mod q

s = (k-1(SHA(M) + xr)) mod q. (здесь k-1 величина обратная k).

SHA(M) – представляет собой дайджест сообщения M (160-битовая строка). После вычисления r и s следует проверить, не равно ли одно из них нулю.

Для верификации электронной подписи проверяющая сторона должна иметь параметры p, q и g, а также открытый ключ отправителя (подписанта) y.

Пусть M`, r` и s` представляют собой полученное сообщение и электронную подпись. Получатель начинает верификацию с проверки условия 0 < r` < q и 0 < s` < q. Если хотя бы одно из условий не выполнено, электронная подпись некорректна. Далее производится вычисление:

w = (s`)-1 mod q

u1 = ((SHA(M`)w) mod q

u2 = ((r`)w) mod q

v = (((g)u1 (y)u2) mod p) mod q.

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

Схема взаимодействия операторов winsock для процедур, ориентированных на соединение

Рисунок 7.1.Схема взаимодействия операторов winsock для процедур, ориентированных на соединение

Лишь при успешной реализации всех перечисленных операций может начаться обмен данными. Для пересылки данных могут использоваться команды write, read, send, recv. Команды write и read имеют форму вызова:

R=write(s, buf, len) или R=read(s, buf, len),

где s - дескриптор соединителя, buf - имя массива, подлежащего пересылке (или предназначенного для приема), len - длина этого массива. Оператор writev отличается от write тем, что данные могут не лежать в виде непрерывного массива:

R=writev(s, io_vect, vectlen) или R=readv(s, io_vect, vectlen),

где s - дескриптор соединителя, io_vect - вектор-указатель на список указателей, vectlen - длина списка указателей. Команда выполняется медленнее, чем write или read. Список указателей имеет формат (Рисунок 7.2):

Рисунок 7.4. Схема взаимодействия операторов winsock для процедур, не ориентированных на соединение

Помимо уже описанных операторов для работы с соединителями (sockets) имеется еще один - select, довольно часто используемый серверами. Оператор select позволяет процессу отслеживать состояние одного или нескольких соединителей. Для каждого соединителя вызывающая программа может запросить информацию о статусе read, write или error. Форма обращения имеет вид:

R=select(num_of_socks, read_socks, write_socks, error_socks, max_time),

где num_of_socks - число контролируемых соединителей (в некоторых реализациях не используется и является необязательным, по умолчанию это число не должно превышать 64). В версии Беркли read_socks, write_socks и error_socks представляют собой побитовые маски, определяющие тип соединителя. Параметр read_socks представляет собой указатель на структуру, описывающую набор соединителей, состояние которых контролируется на возможность чтения (версия winsock). Если соединитель находится в состоянии listen, он будет помечен как “готов для чтения”, при условии, что запрос на соединение уже получен. Это предполагает выполнение оператора accept без блокировки. Для других соединителей “готовность к чтению” подразумевает наличие в очереди запросов чтения. Для соединителей типа SOCK_STREAM это означает, что виртуальный соединитель, соответствующий данному соединителю закрылся, и операторы recv или recvfrom будут выполнены без блокировки. Если виртуальное соединение закрыто корректно, оператор recv вернет код 0, в противном случае (например, принудительное закрытие) будет возвращен код WSAECONNRESET. Параметр write_socks - указатель на набор соединителей, состояние которых контролируется на возможность записи. Если соединитель находится в процессе выполнения процедуры connect, “способность к записи” означает, что установление связи завершено. Для других соединителей это значит, что операции send или sendto будут выполнены без блокировки. Параметр error_socks - это указатель на набор соединителей, контролируемых на ошибки.

В некоторых реализациях этот аргумент идентифицирует список соединителей, помеченных как приоритетные. Соединитель помечается как приоритетный, если опция SO_OOBINLINE=FALSE. На случай ошибки оператор select отмечает соединитель, где это произошло. select работает лишь с теми соединителями, которые были выделены с помощью масок. При успешном выполнении оператор возвращает число соединителей, готовых к операциям ввода/вывода и модифицирует коды масок в соответствии с состоянием соединителей. Прикладная программа может использовать результаты вызова оператора select, анализируя полученные коды масок. Аргумент max_time определяет максимальное время, выделенное select для завершения своей работы. Для уточнения типа ошибки, возникшей при исполнении операции select, можно воспользоваться процедурой WSAGetLastError.

Другим важным оператором является closesocket(s), который закрывает канал соединителя с одной из сторон. Все описанные выше операторы (кроме socket, bind и listen) блокируют работу программы до своего завершения. Практически любая операция, непосредственно связанная с выполнением процедур ввода/вывода, может блокировать выполнение других прикладных функций winsock.

Для обслуживания прикладных процессов (например, WWW-сервера, работа с распределенными базами данных и пр.) разработано много других сервисных программ (WINSOCK.DLL), перечень которых представлен в таблице 7.1.

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

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

Для решения поставленной задачи SMTP-сервер должен знать имя конечного получателя и название почтового ящика места назначения. Аргументом команды MAIL является адрес отправителя (обратный адрес). Аргументом команды RCPT служит адрес конечного получателя. Обратный адрес используется для посылки сообщения в случае ошибки.

Все отклики имеют цифровые коды. Команды, отклики и имена ЭВМ не чувствительны к тому, строчные или прописные символы использованы при их написании. Это не всегда справедливо при написании имен и адресов получателя.

Многие почтовые системы работают только с ASCII-символами. Если транспортный канал работает с октетами, 7-битные коды будут дополнены нулевым восьмым битом. Именно здесь коренилась проблема пересылки почтовых сообщений на русском языке несколько лет назад(русский алфавит требует 8-битового представления).

Как уже было сказано, процедура отправки почтового сообщения начинается с посылки команды MAIL, которая имеет формат:

MAIL FROM: ,

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

Эта команда сообщает SMTP-получателю, что стартует новая процедура и следует сбросить в исходное состояние все статусные таблицы, буферы и т.д. Если команда прошла, получатель реагирует откликом: 250 OK.

Аргумент может содержать не только адрес почтового ящика, в общем случае является списком адресов ЭВМ-серверов, через которые пришло данное сообщение, включая, разумеется, и адрес почтового ящика отправителя. Первым в списке

стоит адрес ЭВМ-отправителя.

После прохождения команды MAIL посылается команда RCPT:

RCPT TO:

Эта команда указывает адрес конечного получателя (). При благополучном прохождении команды получатель посылает код-отклик 250 OK, и запоминает полученный адрес. Если получатель неизвестен, SMTP-сервер пошлет отклик 550 Failure reply. Команда RCPT может повторяться сколько угодно раз, если адресат не один.

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

DATA

При правильном приеме этого сообщения SMTP-сервер реагирует посылкой отклика 354 Intermediate reply (промежуточный отклик), и рассматривает все последующие строки в качестве почтового текста. При получении кода конца текста отправляется отклик: 250 OK.

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

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

1. 251 User not local; will forward to

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

2. 551 User not local; please try

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

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

Реакция на команду VRFY зависит от аргумента. Так если среди клиентов почтового сервера имеется два пользователя с именем Ivanov, откликом на команду "VRFY Ivanov" будет "553 User ambiguous". В общем случае команда VRFY Ivanov может получить в качестве откликов:

250 Vasja Ivanov Ivanov@cl.itep.ru

или:

251 User not local; will forward to Ivanov@cl.itep.ru

или:

550 String does not match anything (данная строка ничему не соответствует).

или:

551 User not local; please try Vasja@ns.itep.ru

или:

VRFY Chtozachertovchina

553 User ambiguous (несуществующее имя)

В случае пропечатки списка адресов отклик занимает несколько строк, например:

EXPN Example-People

250-Juri Semenov Semenov@ns.itep.ru

250-Alexey Sher Sher@suncom.itep.ru

250-Andrey Bobyshev Bobyshev@ns.itep.ru

250-Igor Gursky Gursky@ns.itep.ru

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

Основной задачей почты служит доставка сообщений в почтовый ящик адресата. Сходную форму услуги оказывают некоторые ЭВМ, доставляя сообщения на экран терминала (в рамках SMTP). Для посылки сообщений на экран терминала адресата предусмотрено три команды:

1. SEND FROM:

Команда SEND требует, чтобы почтовое сообщение было доставлено на терминал. Если терминал адресата не активен в данный момент, то откликом на команду RCPT будет код 450.

2. SOML FROM:

Команда Send Or MaiL (SOML) пересылает сообщение на экран адресата, если он активен, в противном случае сообщение будет уложено в его почтовый ящик.

3. SAML FROM:

Команда Send And MaiL (SAML) предполагает доставку сообщение на экран терминала адресата и занесение в его почтовый ящик.

Для открытия и закрытия коммуникационного канала используются команды:

HELO

, где - имя запрашивающего домена.

QUIT

Выражение может быть маршрутом, имеющим вид "@ONE,@TWO:VANJA@THREE", где ONE, TWO и THREE - имена ЭВМ. Что подчеркивает различие между адресом и маршрутом. Концептуально элементы из переносятся в при пересылке сообщений от одного SMTP-сервера к другому.

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

При определенных условиях и ошибках в задании прямых и обратных адресов-маршрутов возможно зацикливание сообщений об этих ошибках. Чтобы заведомо избежать этого можно выдавать команду MAIL c нулевым обратным маршрутом:

MAIL FROM:<>

Если вы или ваша программа не указали обратного адреса, не следует думать, что это помешает работе почтовой программы и она не будет знать, куда посылать отклики. Ваш обратный IP-адрес указан в каждом пакете, посылаемом адресату!

Некоторые другие команды, используемые в SMTP:

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

Команда RESET (RSET) прерывает текущую процедуру отправки почтового сообщения. Все буферы и таблицы очищаются, получатель должен послать отклик 250 OK.

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

Команда NOOP не оказывает влияния на какие-либо параметры или результаты предшествующих команд, она только вынуждает получателя послать отклик 250 OK. Может использоваться для проверки работоспособности TCP-канала.

Допустимо написание команд строчными или прописными символами, например: MAIL, Mail, mail, MaIl или mAIl.

Для того чтобы программа SMTP-сервера была работоспособна, она должна понимать следующий минимум команд: HELO, MAIL, RCPT, DATA, RSET, NOOP, QUIT.

Предельная длина имени пользователя или домена равна 64 символам. Максимальная длина или составляет 256 символов, включая разделители (пробелы, точки, запятые и пр.). Командная строка не должна быть длиннее 512 символов. Максимальный размер строки отклика не должен превышать, включая его код и , 512 символов. Максимальная длина строки составляет, включая , 1000 символов. Предельно допустимое число адресатов равно 100, последнее полезно помнить, если вы храните этот список в файле.

Схема взаимодействия субъектов протокола SET

Рисунок 4.6.2.1. Схема взаимодействия субъектов протокола SET

Покупатель инициализирует покупку. При этом покупатель выбирает продавца, просматривает его WEB-сайт, принимает решение о покупке, заполняет бланк заказа. Все это делается до вступления в дело протокола SET. Реально взаимодействие участников сделки регламентируется протоколом IOTP. SET начинает свою работу, когда покупатель нажимает клавишу оплаты. При этом сервер посылает ЭВМ-покупателя сообщение, которое и запускает соответствующую программу. Процедура эта может быть реализована с помощью PHP- или CGI-скрипта, или JAVA-аплета.

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

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

Банк проверяет действительность кредитной карточки, дешифрует запрос авторизации продавца и идентифицирует продавца.

Схема запросов/откликов snmp

Рисунок 4.4.13.1 Схема запросов/откликов snmp

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

SignedData

Рисунок 4.6.2.5. SignedData

Тип подписанного содержимого косвенно защищается включением в текст атрибута contentType (PKCS #9). Дайджест данных, который подписывается, также включает атрибут messageDigest. SignedData всегда содержит два аутентифицированных атрибута contentType и messageDigest.

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

Синхронные каналы SDH/SONET

4.3.6 Синхронные каналы SDH/SONET

Мультиплексирование потоков информации при формировании мощных региональных и межрегиональных каналов имеет два решения. Одно базируется на синхронном мультиплексировании и носит название синхронная цифровая иерархия (SDH, cм. Н.Н.Слепов, Синхронные цифровые сети SDH. ЭКО-ТРЕНДЗ, Москва, 1998), другое использует простой асинхронный пакетный обмен и носит название асинхронный режим передачи (ATM, см. предыдущую главу).

Стандарт SDH (synchronous digital hierarchy) разработан в Европе, (предназначен для замены иерархии асинхронных линий E-1/E-3) используется в настоящее время многими сетями и представляет собой модификацию американского стандарта на передачу данных по оптическим каналам связи SONET (synchronous optical network). Несмотря на свое название SONET не ограничивается исключительно оптическими каналами. Спецификация определяет требования для оптического одно- и мультимодового волокна, а также для 75-омного коаксиального кабеля CATV 75. Пропускная способность SONET начинается с 51,84 Мбит/с STS-1 (synchronous transport signal-1). Более высокие скорости передачи информации в sonet кратны этому значению. Стандартизованы следующие скорости передачи, которые кратны скорости 64 Кбит/с.

STS-1	51,840	STS-18	933,120
STS-3	155,520	STS-24	1244,160
STS-9	466,560	STS-36	1866,240
STS-12	622,080	STS-48	2488,320

Соответствие каналов SONET и SDH приведено ниже[W. Simpson RFC-1619 “PPP over SONET/SDH”] (и тот и другой могут использоваться для организации связей по схеме PPP):

sonet	sdh
STS-3c	STM-1
STS-12c	STM-4
STS-48c	STM-16

sonet (стандарт ANSI, предназначенный для замены NADH - north american digital hierarchy) использует улучшенную PDH - (plesiochronous digital hierarchy - plesios - близкий (греч.)) схему мультиплексирования каналов. В плезиохронной (почти синхронной) иерархии используется мультиплексирование с чередованием бит, а не байт. Мультиплексор формирует из N входных потоков один выходной (сети, где разные часы сфазированы с разными стандартами, но все они привязаны к одной базовой частоте называются плезиохронными). Так как скорости разных каналов могут не совпадать и нет структур, которые могли бы определить позиции битов для каждого из каналов, используется побитовая синхронизация. Здесь мультиплексор сам выравнивает скорости входных потоков путем введения (или изъятия) соответствующего числа бит. Информация о введенных и изъятых битах передается по служебным каналам. Помимо синхронизации на уровне мультиплексора происходит и формирование кадров и мультикадров. Так для канала Т2 (6312кбит/с) длина кадра равна 789 бит при частоте кадров 8 кГц. Мультикадр содержит 12 кадров. Помимо европейской и американской иерархии каналов существует также японская. Каждая из этих иерархий имеет несколько уровней. Сравнение этих иерархий представлено в таблице 4.3.6.1.

SPX-протокол

4.2.1.2 SPX-протокол

SPX (Sequence Packet eXchange) и его усовершенствованная модификация SPX II представляют собой транспортные протоколы 7-уровневой модели ISO. Это протокол гарантирует доставку пакета и использует технику скользящего окна (отдаленный аналог протокола TCP). В случае потери или ошибки пакет пересылается повторно, число повторений задается программно. В протоколе SPX не предусмотрена широковещательная или мультикастинг-адресация. В SPX индицируется ситуация, когда партнер неожиданно прерывает соединение, например из-за обрыва связи. Пакеты SPX вкладываются в пакеты IPX. При этом в поле тип пакета IPX записывается код 5. Заголовок пакета SPX всегда содержит 42 байта, включая 30 байт заголовка IPX-пакета, куда он вложен (см. Рисунок 4.2.1.2.1).

Статистическая теория каналов связи

2.10 Статистическая теория каналов связи

Данная статья имеет целью познакомить с терминологией и математическими основами статистической теории передачи данных. Именно на этой математической основе зиждятся приведенные выше теоремы Шеннона и Найквиста. Статья является компиляцией из нескольких источников (Ю.В.Прохоров, Ю.А.Розанов "Теория вероятностей. Основные понятия, предельные теоремы, случайные процессы" Наука, М. 1967; Л.Ф. Куликовский, В.В.Мотов, "Теоретические основы информационных процессов", Высшая школа, 1987; Р. Галлагер "Теория информации и надежная связь" Советское радио, 1974 и др.). Материалы, предлагаемые здесь не могут считаться исчерпывающими и призваны быть поводом для более углубленного изучения по существующим монографиям.

Канал связи предназначен для транспортировки сообщений. Математическая модель канала связи описывается некоторой совокупностью Х1 элементов х1 (X1 = {x11, x12,, …x1j}), называемых сигналами на входе канала, совокупностью Х2 элементов х2 (x2 = {x21, x22,, …x2k}), называемых выходными сигналами, и условными распределениями вероятностей p2=p2(a2

|x1) в пространстве x2 выходных сигналов x2. Если посланный сигнал (сигнал на входе) есть х1, то с вероятностью P2=P2(A2|x1) на выходе канала будет принят сигнал х2 из некоторого множества A2 М Х2 (распределения задают вероятности того или иного искажения посланного сигнала х1). Совокупность всех возможных сообщений обозначим символом x0. Предполагается, что каждое из сообщений x0О X0 может поступать с определенной вероятностью. То есть, в пространстве X0

имеется определенное распределение вероятностей P0=P0(A0 ).

Сообщения х0 не могут быть переданы по каналу связи непосредственно, для их пересылки используются сигналы x1О X1. Кодирование сообщений х0 в сигналы х1 описывается при помощи условного распределения вероятностей P1=P1(A1

|x0). Если поступает сообщение х0, то с вероятностью P1=P1(A1|x0)

будет послан один из сигналов х1, входящих в множество A1 М Х1 (условные распределения P1(A1|x0) учитывают возможные искажения при кодировании сообщений). Аналогичным образом описывается декодирование принимаемых сигналов х2 в сообщения x3. Оно задается условным распределением вероятностей P3=P3(A3|x2) на пространстве Х3 сообщений х3, принимаемых на выходе канала связи.

На вход канала связи поступает случайное сообщение x0 с заданным распределением вероятностей P0=P0(A0). При его поступлении передается сигнал x1, распределение вероятностей которого задается правилом кодирования P1=P1(A1|x0):

P{x2 О A2|x0, x1} = P2(A2|x1)

Принятый сигнал x2 декодируется, в результате чего получается сообщение x3:

P{x3 О A3|x0, x1, x2} = P3(A3| x2)

Последовательность x0 ® x1 ® x 2 ® x3 является марковской. При любых правилах кодирования и декодирования описанного типа имеет место неравенство:

I(x0,x3) Ј I(x1, x2),

где I(x0, x3) – количество информации о

x0 в принятом сообщении

x3, I(x1, x2) – количество информации о x1 в принятом сигнале

x2.

Предположим, что распределение вероятности входного сигнала x1 не может быть произвольным и ограничено определенными требованиями, например, оно должно принадлежать классу W. Величина C = sup I(( x1 , x2) , где верхняя грань берется по всем возможным распределениям P1 О W, называется емкостью канала и характеризует максимальное количество информации, которое может быть передано по данному каналу связи (теорема Шеннона).

Предположим далее, что передача сообщений x0 ® x3 должна удовлетворять определенным требованиям точности, например, совместное распределение вероятностей Px0 x1 передаваемого и принимаемого сообщений x0 и x3 должно принадлежать некоторому классу V. Величина H= inf I( x0

x3),

где нижняя грань берется по всем возможным распределениям Px0 x3 О V,

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

Если возможна передача

x0 ® x1 ® x2 ® x3 с соблюдением требований V и W, то есть существуют соответствующие способы кодирования и декодирования (существуют условные распределения P1, P2 и P3), то H Ј С.

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

Предположим, что совокупность Х0 всех возможных сообщений х0 является дискретной (имеется не более чем счетное число различных сообщений x0, поступающих с соответствующими вероятностями P0(x0), x0 О X0) и условие точности передачи v состоит в том, что принимаемое сообщение x3 должно просто совпадать с переданным сообщением x3 = x0 с вероятностью 1. Тогда

Предположим далее, что имеется лишь конечное число N

различных входных сигналов х1 и нет никаких ограничений на вероятности P{ x1 = x1}, x1 О X1. Кроме того, предположим, что передаваемые сигналы принимаются без искажений, то есть с вероятностью 1 x2= x1. Тогда емкость канала выражается формулой C = log2N, т.е. передаваемое количество информации I(x1, x

2 ) будет максимальным в том случае, когда сигналы x1 О X1 равновероятны.

Если сообщения

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

есть

группа сообщений, поступающая на кодирование с вероятностью

Пусть H<C, положим также d=(1/2)(C-H). Согласно закону больших чисел, примененному к последовательности независимых и одинаково распределенных случайных величин

с математическим ожиданием

для любого e >0 найдется такое n(e), что при всех n і n(e )

P{-H-d Ј (1/n)logP( x 0n) Ј H+d } і 1-e, где

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

относятся высоковероятные сообщения х0n, для которых P(x0n) і 2-n(H+d )

и количество которых Mn не больше чем 2n(H+d ):

Mn Ј 2n(H+d )

Ко второму классу

относятся все остальные маловероятные сообщения х0n:
="image793.gif" tppabs="http://book.itep.ru/2/image793.gif">.

Каждую группу высоковероятных сообщений х0n можно в принципе передать, закодировав ее соответствующей комбинацией сигналов

. Число всевозможных комбинаций такого вида есть Nn=2nC, и видно, что Mn<Nn. Имеется Nn различных сигналов x1n, с помощью которых можно закодировать и передать безошибочно все Mn высоковероятных сообщений x0n

Если в дополнение к этому при поступлении любого маловероятного сообщения x0n

передавать некоторый один и тот же сигнал

(отличный от сигналов, при помощи которых передаются высоковероятные сообщения x0n

, то с вероятностью, не меньшей чем 1-e, на выходе канала связи будет приниматься последовательность

При выполнении неравенства H < C оказывается возможной передача достаточно длинных сообщений

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

Количество информации I(x0, x3) для абстрактных случайных величин x0 и x3

со значениями в пространствах Х0 и Х3 может быть записано в виде:

I(x0, x

3) = Mi(x0, x3), где

- информационная плотность. Последовательность пар (x0n, x3n) называется информационно устойчивой, если при n ® Ґ

I(x0, x3) ® Ґ и

(по вероятности)

Рассмотренная выше последовательность (x0n, x3n), x3n= x0n

поступающих сообщений x 0n =(

) обладает свойством информационной устойчивости, что в конечном счете и определило возможность передачи сообщений x 0n с точностью до e. Этот факт допускает широкое обобщение. Например, если Сn – пропускная способность канала

x1n® x 2n, Hn – минимальное количество информации, необходимое для соблюдения требуемой точности передачи x0n

® x 3n, причем

(при n ® Ґ ),

и существуют информационно устойчивые последовательности пар (x0n, x3n) и (x1n, x2n), для которых одновременно

то при весьма широких предположениях для любого наперед заданного e >0 существует такое n(e), что по всем каналам связи с параметром n і n(e) возможна передача с точностью до e.

2.10.2. Канал связи с изменяющимися состояниями

Как было указано выше, канал характеризуется условными распределениями З2, задающими вероятности тех или иных искажений посылаемого сигнала х1. Несколько изменим схему канала связи, считая, что имеется некоторое множество Z возможных состояний z канала связи, причем если канал находится в некотором состоянии z и на входе возникает сигнал x1, то независимо от других предшествующих обстоятельств канал переходит в другое состояние z1. Этот переход подвержен случайностям и описывается условными распределениями P(C|x1, z) (P(C|x1, z) – вероятность того, что новое состояние z1 будет входить в множество C М Z). При этом уже считается, что выходной сигнал х2 однозначно определяется состоянием канала z1, т.е. существует некоторая функция j = j (z) на пространстве z возможных состояний канала такая, что х2= j (z1). Эта более общая схема позволяет учитывать те изменения, которые в принципе могут возникать в канале по мере его работы.

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

…., x 1(-1), x 1(0), x 1(1),…, соответствующие состояниям канала …, z (-1), z (0), z (1),…, и определяемые ими сигналы

…, x 2(-1), x 2(0), x 2(1),…, на выходе образуют стационарные и стационарно связанные случайные последовательности. Величина С=supI(x 1,x 2), где I(x 1,x 2), означает скорость передачи информации о стационарной последовательности {x1(n)} последовательностью {x 2(n)} и верхняя грань берется по всем допустимым распределениям вероятностей входной последовательности {x1(n)}, называется пропускной способностью канала связи.

Предположим, что поступающие на вход канала связи сообщения {x 0(n)}, n =…, -1, 0, 1 ,…, образуют случайную последовательность. Будем считать правило кодирования заданным, если при всех k, m и k1,…, km і k определены условные вероятности

P{x 1(k1) О B1,…, x 1

(km)О Bm|x 0(-Ґ ,k)}

Того, что при поступлении последовательности сообщений

x 0(-Ґ ,k) = …, x 0(k-1), x 0(k)

на соответствующих местах будут переданы сигналы x 1(k1),…, x 1(km), входящие в указанные множества B1, …, Bm. Эти вероятности считаются стационарными в том смысле, что они не меняются при одновременной замене индексов k и k1,…,km на k+l и k1+l,…,km+l при любом целом l. Аналогичными вероятностями p{ x 3(k1) О D1,…, x 3(km) О Dm|x 2(-Ґ ,k)}

задается правило декодирования.

Определим величину H

формулой H = inf I( x 0,x 3), где I(x 0, x 3) – скорость передачи информации о стационарной последовательности {x0(n)}

последовательностью {x3(n)}, n = …, -1, 0, 1,…

(эти последовательности предполагаются стационарно связанными), и нижняя грань берется по всем допустимым распределениям вероятностей, удовлетворяющим требованиям точности передачи {x0(n)} ® { x3(n)}.

Неравенство H Ј C является необходимым условием возможности передачи

{x 0(n)} ® {x 1(n)} ® {x 2(n)} ® {x 3(n)}.

Напомним, что каждое сообщение

x0(n) представляет собой некоторый элемент х0 из совокупности Х0. Можно интерпретировать Х0 как некоторый алфавит, состоящий из символов х0. Предположим, что этот алфавит Х0 является конечным и требование точности передачи состоит в безошибочном воспроизведении передаваемых символов:

P{x 3(k) = x 3(k)} =1 для любого целого k.

Предположим также, что имеется лишь конечное число входных сигналов х1 и состояний канала z. Обозначим состояния канала целыми числами 1, 2, …, N, и пусть p(k, x1,j) – соответствующие вероятности перехода из состояния k в состояние j при входном сигнале x1:

p(k,x1,j) = P{z (x+1) = j|z (n)=k, x 1(n+1)=x1}.

Дополнительно предположим, что любые произведения вида

p(k0,x1(1),k1)p(k1,x1(2),k2)… p(kn-1,x1(n),kn)

являются стохастическими матрицами, задающими эргодические цепи Маркова. Это условие будет выполнено, если, например, каждая из переходных матриц {p(k,x1,j)} имеет положительный коэффициент эргодичности. Тогда при выполнении неравенства H<C и соблюдении условия эргодичности стационарной последовательности {x 0(n)} сообщений на входе передача возможна с точностью до любого e >0, т.е. при соответствующих способах кодирования и декодирования принимаемая последовательность сообщений {x 3(n)} будет обладать тем свойством, что p{x3(k) № x 0(k)} < e для любого целого k.

Пусть x 1 = {x (t), t О T1} и x 2= {x (t), t О T2} – два семейства случайных величин, имеющих совместное гауссово распределение вероятностей, и пусть H1 и H2 – замкнутые линейные оболочки величин x (t), t О T1, и x (t), t О T2, в гильбертовом пространстве L2

(W). Обозначим буквами P1 и P2 операторы проектирования на пространства H1 и H2 и положим P(1) = P1P2P1, P(2) = P2P1P2. Количество информации I(x1,x 2) о семействе величин x1, содержащееся в семействе x2, конечно тогда и только тогда, когда один из операторов P(1) или P(2) представляет собой ядерный оператор, т.е. последовательность l 1, l 2,… его собственных значений (все они неотрицательны) удовлетворяет условию

. При этом

В случае, когда x 1 и x 2 образованы конечным числом гауссовых величин:

x1={x (1),…, x (m)}, x 2 = {x (m+1),…, x (m+n)}, причем корреляционная матрица B общей совокупности x (1),…, x (m+n) является невырожденной, количество информации I(x 1, x 2) может быть выражено следующей формулой:

где B1 и B2 – корреляционные матрицы соответствующих совокупностей x 1 и x 2.

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

x 1 = {x (1), …, x (m)} и x 2 = {x (m+1), …, x (m+n)}

с соответствующими корреляционными матрицами B1, B2 и B количество информации I(x 1, x 2) удовлетворяет неравенству

Пусть x = (x 1,…,x n) и h = (h 1,…,hn) – векторные случайные величины в n-мерном евклидовом пространстве X и r(x,y) – некоторая неотрицательная функция, определяющая условие близости величин x и h, которое выражается следующим соотношением:

Mr(x ,h ) Ј e .

Величину H=He, определенную как He = inf I(x, h), обычно называют e–энтропией случайной величины x (нижняя грань берется по всем случайным величинам h, удовлетворяющим указанному условию e–близости случайной величине x).

Пусть r(x,y) = r(|x-y|) и существует производная r’(0), 0< r’(0)<Ґ. Тогда при e ® 0 имеет место асимптотическая формула, в которой логарифмы берутся по основанию e:

где g() – гамма функция и h(x) – дифференциальная энтропия случайной величины x:

(px(x) – плотность распределения вероятностей, удовлетворяющая весьма широким условиям, которые выполняются, например, если плотность px(x) ограничена и h(x ) > -Ґ ).

Пусть

(a, b > 0)

Тогда

В частности, при a =2, b =1 имеет место асимптотическая формула

Пусть пара случайных процессов (x 1(t), x 2(t)) образует стационарный в узком смысле процесс, x [u,v] – совокупность значений x (t), u Ј t Ј v, и пусть

- условное количество информации о процессе x1=

, содержащееся в отрезке

процесса x2. Среднее количество указанной информации представляет собой линейно растущую функцию от t:

Фигурирующая здесь величина I(x1, x2) называется средней скоростью передачи информации стационарным процессом x2 о стационарном процессе x1 или просто – скоростью передачи информации.

Скорость передачи информации I(x1,x2)

обладает рядом свойств, аналогичных свойствам количества информации. Но она имеет и специфические свойства. Так для всякого сингулярного случайного процесса x 2, т.е. такого процесса, все значения x 2(t) которого являются функциями от совокупности величин

(t0 может быть выбрано любым), имеет место равенство I(x 1, x 2)=0.

Для всякого регулярного случайного процесса x 2 равенство I(x1,x2)=0 справедливо лишь тогда, когда случайный процесс x 1 не зависит от процесса x2 (это говорит о том, что в некоторых случаях I(x1,x2) № I(x 2,x 1) ).

При дополнительных условиях типа регулярности скорость передачи информации I(x 1,x 2)

совпадает с пределом

где

- количество информации об отрезке процесса

, заключенное в

. Так будет, например тогда, когда время меняется дискретно, а отдельные величины x1(t) и x2(t) могут принимать лишь конечное число различных значений или когда распределение вероятностей процессов x1 и x2 является гауссовым. В случае непрерывного времени t так будет для гауссовых процессов, когда спектральная плотность f(l) процесса x2(t) удовлетворяет условию

0< c Ј l 2nf(l ) Ј c < Ґ

Пусть стационарный процесс x = x (t) представляет собой последовательность величин, каждая из которых принимает значения из некоторого алфавита x, состоящего из конечного числа символов x1, x2,…,xn. Предположим, что вероятность появления на фиксированном месте определенного символа xi есть pi, а вероятность появиться за ним символу xj не зависит от предшествующих xi значений и есть pij:

P{x (t) = xi} = pi, P{x(t+1) = xi xi|x(t) = xi, x(t-1),…, } = pij

Другими словами x = x

(t) - стационарная цепь Маркова с переходными вероятностями {pij} и стационарным распределением {pi}. Тогда скорость передачи информации стационарным процессом x(t) будет

I(x,x) = -

В частности, если x = x(t) – последовательность независимых величин (в случае pij = pj), то

I(x,x) = -

Пусть x1 = x1(t) и x2 = x2(t) – стационарные гауссовы процессы со спектральными плотностями f11(l), f22(l) и взаимной спектральной плотностью f12(l) причем процесс x2 = x2(t) является регулярным. Тогда

I(x1, x2) = -

Рассмотрим следующее условие близости гауссовых стационарных процессов x1(t) и x2(t):

M|x1(t) - x2(t)|2 Јd2

Наименьшая скорость передачи информации

H = infI(x1,x2),

совместимая с указанным условием “d-точности”, выражается следующей формулой:

где

а параметр q2 определяется из равенства

Эта формула показывает, какого типа спектральная плотность f22(l) должна быть у регулярного стационарного процесса x 2(t), который несет минимальную информацию I

(x1,x 2) » H

о процессе x1(t). В случае дискретного времени, когда f11(l ) і q 2 при всех l , -p Ј l Ј p, нижняя грань H скорости передачи достигается для такого процесса x 2

(t) (со спектральной плотностью f22(l), задаваемой приведенной выше формулой), который связан с процессом x 1(t) формулой

x 2(t) = x 1(t) + z(t), где z(t) – стационарный гауссов шум, не зависящий от процесса x 2(t); в общем случае формула f22(l) задает предельный вид соответствующей спектральной плотности регулярного процесса x 2(t).

В случае, когда спектральная плотность f11(l) приближенно выражается формулой

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

, s2 = M[x(t)]2.

2.10.3. Симметричный канал без памяти

Рассмотрим симметричный канал передачи данных без памяти c конечным числом входных сигналов х1, когда передаваемый сигнал х1 с вероятностью 1-p правильно принимается на выходе канала связи, а с вероятностью p искажается, причем все возможные искажения равновероятны: вероятность того, что на выходе будет сигнал х2, равна

для любого х2 № x1, где N – общее число сигналов. Для такого канала связи пропускная способность

c = supI( x1,x2) достигается в случае, когда на вход поступает последовательность независимых и равномерно распределенных сигналов …, x 1(-1), x 1(0), x 1(1),…; эта пропускная способность выражается формулой

Рассмотрим канал связи, на входе которого сигналы образуют стационарный процесс x 1 = x1(t), M[x 1(t)]2 < Ґ.

Пусть при прохождении сигнала x 1 = x 1(t) он подвергается линейному преобразованию Aj со спектральной характеристикой j (l) и, кроме того, на него накладывается аддитивный стационарный гауссов шум z =z (t), так что на выходе канала имеется случайный процесс x 2(t) вида x 2(t) = aj x 1(t) + z (t).

Предположим также, что ограничения на входной процесс состоит в том, что M[x 1(t)]2 Ј D 2 (постоянная D2 ограничивает среднюю энергию входного сигнала). Пропускная способность такого канала может быть вычислена по формуле

(в последнем выражении интегрирование ведется в пределах -p Ј l Ј p для дискретного времени t и в пределах -Ґ <l <Ґ для непрерывного t), где fz z (l) – спектральная плотность гауссова процесса z (t), функция f(l) имеет вид

а параметр q2 определяется из равенства

Нужно сказать, что если функция f(l) представляет собой спектральную плотность регулярного стационарного гауссова процесса x 1(t), то этот процесс, рассматриваемый как входной сигнал, обеспечивает максимальную скорость передачи информации: I(x 1,x 2) = C. Однако в наиболее интересных случаях, когда время t меняется непрерывно, функция f(l) обращается в нуль на тех интервалах частот l, где уровень шума сравнительно высок (отличные от нуля значения f(l) сосредоточены в основном на тех интервалах частот l, где уровень шума сравнительно мал), и поэтому не может служить спектральной плотностью регулярного процесса. Более того, если в качестве входного сигнала выбрать процесс x 1(t) с спектральной плотностью f(l), то этот сигнал будет сингулярным и соответствующая скорость передачи информации I(x 1,x2) будет равна нулю, а не максимально возможному значению C, указанному выше.

Тем не менее, приведенные выражения полезны, так как позволяют приблизительно представить вид спектральной плотности f(l) регулярного входного сигнала x 1(t),

обеспечивающей скорость передачи I(x1, x2), близкую к максимальному значению C.

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

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

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

При этом входной сигнал x1(t), обеспечивающий скорость передачи информации I(x1, x2), близкую к максимальной, является гауссовым стационарным процессом со спектральной плотностью f(l) вида

так что параметры D2 и s2 имеют следующий физический смысл:

- энергетический уровень входного сигнала,

- энергетический уровень шума.

9 колонок кадра, исключая строку

Рисунок 4.3.6.3 Структура кадра STM-1

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

Мультиплексорный заголовок используется мультиплексорами, обеспечивая детектирование ошибок и информационный канал с пропускной способностью 576 Кбит/с. AU (administrative units) - предлагает механизм эффективной транспортировки информации STM-1. Административный блок перераспределяет информацию внутри виртуального контейнера. Начало виртуального контейнера индицируется указателем au, в котором содержится номер байта, с которого начинается контейнер. Таким образом, начала STM-1 и VC не обязательно совпадают.

Структуры данных

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

TransID

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

TransID	{LID-C, [LID-M], XID, PReqData, [PaySysID], Language}
LID-C	Локальный ID. Метка, генерируемая системой владельца карты или для нее.
LID-M	Локальный ID. Метка, генерируемая системой продавца или для нее.
XID	Глобально уникальный идентификатор
PReqData	Дата запроса покупки. Генерируется продавцом в PInitRes или владельцем карты в PReq.
PaySysID	Используется некоторыми платежными системами для пометки транзакций
Language	Естественный язык владельца карты

TransID предоставляет несколько идентификаторов для транзакций. LID-C, LID-M и PaySysID являются идентификаторами, которые присваиваются владельцем карты, продавцом и/или платежной системой. LID-M часто используется для хранения номера заказа продавца для данной транзакции. PreqData предоставляет дату запуска транзакции. XID представляет собой идентификатор транзакции, который обычно формируется системой продавца, если только нет PInitRes, в последнем случае он формируется системой владельца карты. XID представляет собой псевдослучайный 20 байтовый код, который должен быть уникальным. В таблице 4.6.2.38 рассмотрено, когда формируется и используется поле TransID в сообщениях SET.

в режиме CBC, хэш MD5,

Таблица 6.5.1

Набор	Уровень безопасности	Описание
DES-CBC3-MD5	Очень высокий	Тройной DES в режиме CBC, хэш MD5, 168-битный ключ сессии
DES-CBC3-SHA	Очень высокий	Тройной DES в режиме CBC, хэш SHA, 168-битный ключ сессии
RC4-MD5	Высокий	RC4, хэш MD5, 128-битный ключ
RC4-SHA	Высокий	RC4, хэш SHA, 128-битный ключ
RC2-CBC-MD5	Высокий	RC2 в режиме CBC, хэш MD5, 128-битный ключ
DES-CBC-MD5	Средний	DES в режиме CBC, хэш MD5, 56-битный ключ
DES-CBC-SHA	Средний	DES в режиме CBC, хэш SHA, 56-битный ключ
EXP-DES-CBC-SHA	Низкий	DES в режиме CBC, хэш SHA, 40-битный ключ
EXP-RC4-MD5	Низкий	Экспортное качество RC4, хэш MD5, 40-битный ключ
EXP-RC2-CBC-MD5	Низкий	Экспортное качество RC2, хэш MD5, 40-битный ключ
NULL-MD5	-	Без шифрования, хэш MD5, только аутентификация
NULL-SHA	-	Без шифрования, хэш SHA, только аутентификация

Шифр SSL_CK_RC4_128_EXPORT40_WITH_MD5 имеет тип RC4, где некоторые ключи сессии посылаются открыто, а остальные в зашифрованном виде. MD5 используется в качестве хэш-функции для получения MAC и ключей сессии. Этот тип шифра предлагается для поддержки "экспортных" версий (т.e. версий протокола, которые могут быть применены за пределами Соединенных Штатов) клиента или сервера.
Экспортные реализации протокола диалога SSL будут иметь длины секретных ключей не более 40 бит. Для не экспортных реализаций длины ключей могут быть больше (рекомендуется, по крайней мере, 128 бит). Клиенты и серверы могут иметь не перекрывающийся набор поточных шифров. Но это означает, что они не могут общаться.
Версия 2 протокола диалога SSL определяет, что SSL_CK_RC4_128_WITH_MD5 должен иметь длину ключа 128 бит. SSL_CK_RC4_128_EXPORT40_WITH_MD5 также имеет длину ключа 128 бит. Однако только 40 бит являются секретными (другие 88 пересылаются от клиента к серверу открыто).
Сообщение SERVER-HELLO посылается, после того как сервер получит сообщение CLIENT-HELLO, и до того как сервер пошлет SERVER-VERIFY.

SERVER-VERIFY (Фаза 1; посылается шифрованным)

Сети без гарантированной полосы пропускания

Таблица 2.9.1.1

	H.320	H.321	H.322	H.323 V1/V2	H.324
Дата принятия	1990	1995	1995	1996/1998	1996
Сеть	Узкополосная переключаемая цифровая ISDN	Широкополосная ISDN ATM LAT	Сети с гарантированной полосой пропускания	Сети без гарантированной полосы пропускания (Ethernet)	PSTN или POTS, аналоговые телефонные системы
Видео	H.261 H.263	H.261 H.263	H.261 H.263	H.261 H.263	H.261 H.263
Аудио	G.711 G.722 G.728	G.711 G.722 G.728	G.711 G.722 G.728	G.711 G.722 G.728 G.723 G.729	G.723
Мультиплексирование	H.221	H.221	H.221	H.225	H.223
Управление	H.230 H.242	H.242	H.230 H.242	H.245	H.245
Многоточечный режим	H.231 H.243	H.231 H.243	H.231 H.243	H.323
Данные	T.120	T.120	T.120	T.120	T.120
Общий интерфейс	I.400	AAL I.363 AJM I.361 PHY I.400	I.400 & TCP/IP	TCP/IP>	V.34 модем

log2 числа значащих бит сервера

Таблица 4.4.16.7

Имя поля	Уникаст/Эникаст	Мультикаст
Запрос	Отклик
LI	игнорируется	0 или 3	0 или 3
VN	1-4	копия из запроса	4
Режим	3	2 или 4	5
Слой	игнорируется	1	1
Регистрация	игнорируется	копия из запроса	log2 периода запросов
Точность	игнорируется	- log2 числа значащих бит сервера	-log2 числа значащих бит сервера
Root Delay	игнорируется	0	0
Root Dispersion	игнорируется	0	0
Идентификатор эталона	игнорируется	Идентификатор эталона	Идентификатор эталона
Reference Timestamp	игнорируется	время последней коррекции по радио-часам	время последней коррекции по радио-часам
Originate Timestamp	игнорируется	копируется из поля transmit timestamp	0
Receive Timestamp	игнорируется	время дня	0
Transmit Timestamp	(см. текст)	время дня	время дня
Аутентификатор	опционно	опционно	опционно

Наиболее важным индикатором неисправности сервера является поле LI, в котором код 3 указывает на отсутствие синхронизации. Когда получено именно это значение, клиент должен проигнорировать сообщение сервера вне зависимости от содержимого других полей.
7. Конфигурация и управление
Исходная конфигурация SNTP серверов и клиентов может быть произведена на основе конфигурационного файла, если такой файл имеется, или через последовательный порт. Предполагается, что SNTP серверы и клиенты практически не требуют какого-то конфигурирования, специфического для данного узла (помимо IP-адреса, маски субсети или адреса OSI NSAP).
Уникастные клиенты должны быть снабжены именем сервера или его адресом. Если используется имя сервера, то необходим один или несколько адресов ближайших DNS-серверов. Мультикастные серверы и эникастные клиенты должны снабжаться значением TTL, а также местным широковещательным или групповым мультикастным адресом. Эникастные серверы и мультикастные клиенты могут конфигурироваться с привлечением списков пар адрес-маска. Это обеспечивает контроль доступа, так что операции будут производиться только с известными клиентами или серверами.

Таблица

Таблица 6.1.

Каталог и имя файла	Описание
/etc/bootplog	Предназначен для документирования выполнения операций загрузки bootp
/usr/adm/errlog	Регистратор ошибок на жестком диске
/usr/adm/messages	Имя информационного файла syslog
/usr/adm/sulog	Журнал записи входов в систему суперпользователя (root)
/usr/lib/cron/log	Журнал регистрации исполнения команд cron (кто, что, когда). Могут записываться и сообщения об ошибках.
/usr/spool/mqueue/syslog	Журнал записи операций sendmail и сообщений об ошибках.

Одной из мер безопасности в локальной сети может быть кодировка всех пакетов, посылаемых с удаленных терминалов. Для реализации этого надо модифицировать все сетевое программное обеспечение или оснастить сеть специальными аппаратными средствами. Принимая во внимание, что в России используется на 99% зарубежное сетевое программное обеспечение, а денег на специальное оборудование безопасности обычно не предусмотрено в бюджете, этот путь представляется пока не самым удобным. Шифрование предполагает две процедуры - собственно кодирование информации с использованием секретного ключа и пересылка секретного ключа. Для передачи секретных ключей, паролей доступа (если их нужно пересылать) и идентификации партнеров, участвующих в обмене (а это иногда крайне важно, достаточно вспомнить посылку ложной телеграммы графом Монте-Кристо) используется схема с открытым и секретным ключами или алгоритм Диффи-Хелмана.
Схема с шифрованием проще реализовать для корпоративных сетей, т.е. для сетей принадлежащих одной фирме или отрасли (см. также раздел 6.5 и 6.6 ). Аналогичная схема может успешно использоваться между партнерами, которые заранее согласовали метод и ключи шифрования. Шифровка-дешифровка может проводиться аппаратным или программным образом для текстов или даже самих пересылаемых пакетов. Здесь предполагается наличие механизма пересылки ключей, подтверждения их получения и т.д. Шифрование не заменяет другие меры безопасности, так как несанкционированное вторжение может привести к потере или повреждению файлов, а в особо тяжелых случаях к разрушению всей операционной системы.

Таблица

Таблица 7.7.

WSACancelBlockingCall	прерывание блокирующей процедуры (без аргументов);
WSAIsBlocking	определение блокирующей операции (без аргументов);
WSASetBlockingHook	перехват блокирующего вызова, организация цикла ожидания;
WSAUNhookBlockingHook	восстановление прежней блокировки.

При необходимости прервать блокирующую операцию можно вызвать процедуру WSACancelBlockingCall, прикладная программа получит при этом сообщение об ошибке (WSAEINTR). Оператор WSAIsBlocking возвращает значение TRUE, если в данный момент реализуется блокирующая операция. Последние два оператора из четырех названных служат для построения пользовательских обработчиков сообщений.
Аппарат соединителей предполагает возникновение и исчезновение вычислительных и управляющих процессов. Новый процесс может наследовать "старые" соединители. В этом случае может возникнуть необходимость выяснить, адрес партнера, с которым взаимодействует данный соединитель. Эту задачу можно решить с помощью команды getpeername(s, destaddr, addrlen), где destaddr - указатель на структуру типа (Рисунок 7.5):

Асимметричное шифрование с гарантией целостности

Таблица 4.6.2.10. Асимметричное шифрование с гарантией целостности

Шаг	Действие
1	Инициализировать и загрузить информационные поля, зависимые от типа сообщения
2	Преобразовать информационные поля, подлежащие шифрованию, в формат DER
3	Вычислить хэш SHA-1 результата шага 2
4	Сформировать новый ключ DES
5	Зашифровать результат работы шага 2, используя ключ DES из шага 4. Используется режим DES-CBC.
6	Инициализировать буфер зашифрованных данных с помощью кода типа данных, идентификатора алгоритма DES и добавить эту информацию к результату шага 5.
7	Инициализировать буфер цифрового конверта, в зависимости от получателя (128 байт)
8	Инициализировать буфер дополнительного шифрования OAEP с использование ключа из шага 4 и хэша, вычисленного на шаге 5.
9	Применить OAEP для буфера цифрового конверта
10	Зашифровать результат шага 9, используя асимметричный общедоступный ключ объекта r
11	Инициализировать информационный буфер получателя посредством идентификатора алгоритма RSA и добавить туда результат работы шага 10
12	Инициализировать буфер PKCS#7 и положить туда результат шага 11 и 6
13	Прислать результат шага 12

Оператор симметричного шифрования EK(k,t) шифрует открытый текст группы t с привлечением ключа k. Для целей шифрования здесь могут использоваться алгоритмы DES или CDMF. Процедура симметричного шифрования представлена в таблице 4.6.2.11.

Асинхронные операторы

Таблица 7.5. Асинхронные операторы

WSAAccept*	Расширенная версия accept, которая позволяет условное подключение и формирование групп соединителей.
WSACloseEvent	Уничтожает объект события.
WSAConnect*	Расширенная версия connect, которая позволяет обмениваться данными о соединении и QoS-информацией.
WSACreateEvent	Создает объект события.
WSADuplicateSocket	Создает новый дескриптор соединителя для случая использования его несколькими процессами.
WSAEnumNetworkEvents	Выявляет сетевые события.
WSAEnumProtocols	Выдает информацию о каждом доступном протоколе.
WSAEventSelect	Связывает сетевое событие с объектом события.
WSAGetOverlappedResult	Сообщает состояние выполнения совместной операции обмена.
WSAGetQOSByName	Выдает параметры qos для заданного имени сетевой услуги.
WSAHtonl	Расширенная версия htonl
WSAHtons	Расширенная версия htons
WSAIoctl*	Версия ioctlsocket, пригодная для совмещения процедур ввода/вывода
WSAJoinLeaf*	Подключает периферийный узел к многоточечной сессии.
WSANtohl	Расширенная версия ntohl
WSANtohs	Расширенная версия ntohs
WSARecv*	Расширенная версия recv, которая позволяет совмещать по времени операции ввода/вывода, использовать многобуферную схему при работе с векторами указателей и получать флаги в качестве входных и выходных параметров.
WSARecvDisconnect	Завершает работу соединителя и выдает информацию о завершении, если соединитель был ориентирован на работу в связанном состоянии.
WSARecvFrom*	Расширенная версия recvfrom, которая позволяет совмещать по времени операции ввода/вывода, использовать многобуферную схему при работе с векторами указателей и получать флаги в качестве входных и выходных параметров
WSAResetEvent	Обнуляет объект события.
WSASend*	Расширенная версия send, которая позволяет совмещать по времени операции ввода/вывода, использовать многобуферную схему при работе с векторами указателей.
WSASendDisconnect	Инициализирует процедуру закрытия соединения и опционно посылает сообщение disconnect.
WSASendTo*	Расширенная версия sendto, которая позволяет совмещать по времени операции ввода/вывода, использовать многобуферную схему при работе с векторами указателей.
WSASetEvent	Устанавливает объект события.
WSASocket	Расширенная версия socket, которая использует структуру WSAPROTOCOL_INFO в качестве входной информации и позволяет создать соединители, работающие одновременно. Позволяет также формировать группы соединителей.
WSAWaitForMultipleEvents	Присылается, если любой или все специфицированные объекты находятся в сигнальном состоянии или когда истекает время таймаута.

<
* Программа может вызвать блокировку при работе с блокирующим соединителем.
При написании программ на персональной ЭВМ, например, на С++ или ассемблере существует возможность выбора модели памяти: small, medium, compact, large или huge. Эти модели отличаются друг от друга числом сегментов (по 64 Кбайт) памяти, выделяемой для программы и данных. Модель small предполагает, что все указатели имеют тип near, если явно не указано обратное (не записан модификатор FAR). Модель large считает по умолчанию все указатели дальними, если явно не присутствует модификатор near. В модели huge длина блока данных может превышать размер одного сегмента. С особенностями этих моделей рекомендуется ознакомиться по описаниям конкретных трансляторов. Используя те или иные модели при создании сетевых программ, нужно учитывать проблемы, которые могут возникнуть при переносе вашей программы из одной операционной среды в другую. ОС Unix, Windows NT и Windows 97 не поддерживают каких-либо моделей памяти и их система адресации скорее совместима с моделью large. Но при переносе программы из одной среды в другую об этой проблеме лучше не забывать и перед началом отладки полезно изучить особенности адресации.
При программировании под Windows 3.1 нужно учитывать то, что для доступа к процессору (ЦПУ) необходимо, чтобы программа, захватившая его раньше, прекратила свою работу и освободила ЦПУ. Этого не требуется в среде Unix, Windows 95 или Windows NT. Различие этих операционных сред особенно заметно при выполнении блокирующих процедур, рассмотренных выше, например операции сетевого ввода/вывода. Блокирующие процедуры являются потенциальным источником “повисания” программ, например, оператор recv может вечно ждать отклика, в то время как удаленный сервер будет ждать сообщения от программы, выполняющей recv. По этой причине создание не блокирующих соединителей представляется привлекательным. Такие соединители формируются путем вызова стандартного оператора socket с последующим обращением к процедуре, изменяющей режим работы соединителя (по умолчанию создается блокирующий соединитель).

После этого при вызове блокирующего оператора, например, recv при условии, что соединитель не имеет запрашиваемых данных, система возвратит флаг ошибки. Таким образом, при работе с неблокирующим соединителем, операционная система проверяет возможность немедленного выполнения процедуры, и возвращает сигнал ошибки, если это не возможно. Все операторы winsock являются асинхронными и неблокирующими. Асинхронные операции при невозможности выполнить требуемую операцию не выдают сообщения об ошибке, за тем, чтобы процедура была выполнена так как нужно, в этом случае следит операционная система. По завершении асинхронной операции ОС Windows посылает сообщение тому окну, из которого эта операция была вызвана. Но и операторы, работающие с неблокирующими соединителями Беркли, также являются неблокирующими. В то же время все операции ввода и вывода в Unix являются синхронными.
Хотя оператор WSAAsyncSelect считается аналогом select, между ними имеется существенное отличие. WSAAsyncSelect - единственный оператор, использующий дескриптор соединителя в качестве параметра. Если select контролирует состояние нескольких соединителей, для того чтобы достичь того же результата с помощью wsaasyncselect надо реализовать столько вызовов, сколько соединителей мы хотим мониторировать. Форма обращения к WSAAsyncSelect имеет вид:

WSAAsyncSelect(SOCKETs, HWND hWnd, unsigned int wMsg, long lEvent),
где s - дескриптор соединителя, состояние которого мы хотим контролировать, аргумент, hWnd - дескриптор окна-получателя сообщения; wMsg - определяет тип посылаемого сообщения (эти два параметра являются стандартными для всех функций Windows); lEvent - битовая маска, определяющая тип событий, которые нас интересуют. Возможные значения параметра lEvent приведены в таблице 7.6.

Атрибуты CertificationRequest

Таблица 4.6.2.37. Атрибуты CertificationRequest

	ССА, МСА или РСА				Геополитический центр сертификации или СА платежной системы
Атрибут SET		Сертификат подписи		Подпись CRL	Сертификат и подпись CRL
KeyUsage	X	X	X	X	X
PrivateKeyUsagePeriod	X	X		X	X
AdditionalPolicy	O	O	O	O	O
SubjectAltName	O	O	O	O	O
CertificateType	X	X	X	X	X
Tunneling			X

Х – обязательный

O - опционный

При получении CertificationRequest СА должен проверить запрос и сформировать отклик в соответствии со следующей процедурой:

Шаг

Действие

Используя процедуру, определенную платежной системой, проверить аутентичность CertificationRequest

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

Проверить, что уникальное имя субъекта (Distinguished Name) согласуется с форматом Certificate Subject Name

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

Для сертификатов подписи проверить, что запрошенный PrivateKeyUsagePeriod находится в пределах допустимого диапазона пригодности по времени для подписывающего СА, и что дата notBefore в запрошенном PrivateKeyUsagePeriod находится в пределах допустимого для подписывающего СА.

Если какая-либо из вышеперечисленных проверок не прошла, сертификат не будет сформирован.

Если верификация прошла успешно, сертификат формируется с применением атрибутов, включенных в запрос. Сформированный сертификат помещается в соответствующую секцию SignedData.

SignedData помещается в цифровой конверт и посылается отправителю запроса. Транспортные механизмы находятся вне зоны ответственности SET.

и создается соединитель. Исходный соединитель

Таблица 7.13. Базовые SPI процедуры передачи данных Winsock 2

WSPAccept	Входное соединение подтверждается и создается соединитель. Исходный соединитель возвращается в режим ожидания (listening). Эта процедура позволяет условное создание соединителей и их включение в группу.
WSPAsyncSelect	Выполняет WSPSelect в асинхронном режиме.
WSPBind	Присваивает локальное имя безымянному соединителю.
WSPCancelBlockingCall	Аннулирует блокирующую процедуру WinSock.
WSPCloseSocket	Удаляет соединитель из справочной таблицы.
WSPConnect	Инициализирует соединение для специфицированного соединителя. Эта процедура позволяет обмениваться данными о соединении и QOS.
WSPDuplicateSocket	Возвращает структуру WSAPROTOCOL_INFO, которая может быть использована для формирования нового дескриптора соединителя, используемого несколькими процессами.
WSPEnumNetworkEvents	Выявляет факт появления сетевых событий.
WSPEventSelect	Связывает сетевые события с объектами события.
WSPGetOverlappedResult	Сообщает состояние завершения процесса при совмещении операций ввода/вывода.
WSPGetPeerName	Возвращает имя партнера, подключенного к заданному соединителю.
WSPGetSockName	Возвращает локальный адрес, к которому подключен заданный соединитель.
WSPGetSockOpt	Возвращает опцию заданного соединителя.
WSPGetQOSByName	Сообщает параметры QOS на основе названия известной сетевой услуги.
WSPIoctl	Обеспечивает управление соединителем.
WSPJoinLeaf	Подключает периферийный узел к многоточечному обмену.
WSPListen	Организует процесс ожидания (Listen) на заданном соединителе.
WSPRecv	Получает данные от подключенного или неподключенного соединителя. Эта процедура реализует прием рассеянных данных или массивов для соединителей, работающих в режиме совмещения операций ввода/вывода, и использует flags в качестве параметра IN OUT.
WSPRecvDisconnect	Завершает операции приема для соединителя и возвращает информацию об отключении для соединителей, ориентированных на соединение.
WSPRecvFrom	Принимает данные от подключенного или неподключенного соединителя. Эта процедура позволяет работать с рассеянными данными в совмещенном режиме ввода/вывода, и использует flags в качестве параметра IN OUT.
WSPSelect	Выполняет синхронное мультиплексирование.
WSPSend	Посылает данные подключенному соединителю. Эта процедура позволяет работать с рассеянными данными при совмещении операций ввода/вывода.
WSPSendDisconnect	Запускает процесс отключения соединителя и опционно посылает уведомление об отсоединении.
WSPSendTo	Посылает данные в подключенному или неподключенному соединителю. Эта процедура позволяет работать с рассеянными данными при совмещенных операциях ввода/вывода.
WSPSetSockOpt	Запоминает опции, соответствующие определенному соединителю.
WSPShutdown	Прерывает частично дуплексное соединение.
WSPSocket	Процедура формирования соединителя, которая использует в качестве входной структуру WSAPROTOCOL_INFO и позволяет использовать созданный соединитель для совмещенных операций. Позволяет создавать группы соединителей.
WSPStartup	Инициализирует сервис-провайдера WinSock.
WPUCloseEvent	Ликвидирует дескриптор объекта события
WPUCloseSocketHandle	Ликвидирует дескриптор соединителя, сформированный WinSock DLL
WPUCreateEvent	Формирует новый объект события
WPUCreateSocketHandle	Создает новый дескриптор соединителя для не-IFS провайдеров
WPUGetProviderPath	Присылает путь к DLL для специфицированного провайдера
WPUModifyIFSHandle	Присылает модифицированный дескриптор IFS из WinSock DLL
WPUPostMessage	Выполняет стандартную процедуру PostMessage так, чтобы обеспечить обратную совместимость
WPUQueryBlockingCallback	Присылает указатель на вход в цикл псевдоблокировки
WPUQuerySocketHandleContext	Присылает значение контекста соединителя (только для провайдеров, не поддерживающих IFS)
WPUQueueApc	Ставит пользователя в очередь APC для указанной сессии
WPUSetEvent	Устанавливает объект события
WSCDeinstallProvider	Отмена регистрации сервис-провайдера
WSCEnumProtocols	Получение информации о доступных транспортных протоколах
WSCInstallProvider	Регистрация нового сервис-провайдера

ErrorCode

Таблица 4.6.2.16. ErrorCode

Ошибка	Описание
unspecifiedFailure	Причина неудачи не фигурирует в списке стандартных ошибок
messageNotSupported	Этот вполне корректный тип сообщения не поддерживается получателем
decodingFailure	Произошла ошибка в процессе DER-кодирования сообщения
invalideCertificate	Сертификат, необходимый для обработки сообщения, некорректен. Поле ErrorThumb идентифицирует этот сертификат.
expiredCertificate	Время действия сертификата, необходимого для обработки сообщения, иссякло. Поле ErrorThumb идентифицирует этот сертификат.
revokedCertificate	Сертификат, необходимый для обработки сообщения, отозван. Поле ErrorThumb идентифицирует этот сертификат.
missingCertificate	Сертификат, необходимый для обработки этого сообщения, отсутствует в кэше сертификатов получателя.
signatureFailure	Цифровая подпись сообщения не может быть верифицирована
badMessageHeader	Заголовок сообщения не может быть обработан
wrapperMsgMismatch	Содержимое цифрового конверта сообщения не согласуется с внутренним содержимым сообщения.
versionTooOld	Номер версии сообщения слишком стар для получателя
versionTooNew	Номер версии сообщения слишком нов для получателя
unrecognizedExtension	Сообщение или сертификат содержит критическое расширение, которое получатель не может обработать. Поле ErrorOID идентифицирует расширение. Если расширение присутствует в сертификате, поле ErrorThumb идентифицирует сертификат
messageTooBig	Сообщение слишком длинно для получателя
signatureRequired	Неподписанная версия сообщения неприемлема
messageTooOld	Дата сообщения слишком далеко в прошлом для получателя
messageTooNew	Дата сообщения слишком близка для получателя
thumbsMismatch	Оттиск, посланный в неподписанном запросе, не согласуется с тем, что прислано запрашивающей стороне
unknownXID	Получен неизвестный RRPID
challengeMismatch	Вызов, посланный в запросе, не согласуется с вызовом в отклике

Так как сообщения Error могут посылаться, в том числе и в ответ на отклик, возникает проблема при работе с протоколами, базирующимися на алгоритмах запрос-отклик (например, HTTP). В этом случае сообщение об ошибке может посылаться в качестве запроса, на который необязательна посылка отклика. На нижележащем протокольном уровне при этом может происходить таймаут.

Формат AcctData

Таблица 4.6.2.28. Формат AcctData

AcctData

{AcctIdentification, EXNonce}

AcctIdentification

Для продавца это поле уникально и определяется платежной системой карты (Brand) и получателем (банк продавца)

EXNonce

Новый код Nonce для предотвращения атак на PANData0

СА проверяет CertReq (EncX) следующим образом.

Шаг	Действие
1	Получить CertReq из входного сообщения Если RequestType соответствует новому сертификату подписи или сертификатам подписи и шифрования, то используется одна подпись CertReq. Верифицировать ее, используя новый общедоступный ключ, содержащийся в PublicKeyS. Если верификация не прошла, возвращается CertRes с CertStatusCode равным sigValidationFail. Если RequestType соответствует обновлению сертификата подписи или одновременному обновлению сертификатов подписи и шифрования, то используются две подписи (SignerInfos) для CertReq. Для SingerInfo с нулевым DN эмитента верифицируется подпись с использованием нового общедоступного ключа подписи, содержащегося в PublicKeyS. Если верификация не прошла, возвращается CertRes с CertStatusCode равным ValidationFail. Для SingerInfo c DN эмитента и серийным номером равными значениям из обновляемого сертификата подписи верификация подписи осущетствляется с использованием общедоступного ключа этого сертификата. Если верификация не прошла, возвращается сообщение Error с ErrorCode равным signstureFailure. Если RequestType соответствует новому или обновляемому сертификату шифрования, то для CertReq используется одна подпись. Верифицировать ее, используя общедоступный ключ сертификата подписи ЕЕ. Если верификация не прошла, возвращается сообщение Error с ErrorCode равным signatureFailure.
2	Из данных CertReqTBS запомнить RRPID, LID-EE, Chall-EE3, RequestType, LID-CA, Chall-CA, IDData, RegForm, CaBackKeyData, список оттисков и новые сертификаты подписи и/или шифрования
3	Проверить то, что RRPID и RequestDate соответствуют значениям, полученным из цифрового конверта сообщения. Если соответствия нет, выдается сообщение Error с ErrorCode равным unknownRRPID.
4	Проверить то, что полученный Chall-CA соответствует посланному в Me-AqCInitRes или RegFormRes. Если соответствия нет, выдается сообщение Error с ErrorCode равным challengeMismatch.
5	Проверить PAN (если он включен) в соответствии с политикой платежной системы (Brand), в противном случае проверить AcctData. Если соответствия нет, возвращается CertRes c кодом CertStatusCode равным rejectByIssuer.
6	Если RequestType соответствует обновлению, проверить, что сертификаты, подлежащие обновлению, не были до этого обновлены. Если проверка не прошла, возвращается CertRes c кодом CertStatusCode равным rejectedByCA.
7	Проверить то, что RegFormID корректен с точки зрения языка, RequestType и BIN или PAN. Если проверка не прошла, возвращается CertRes c кодом CertStatusCode равным rejectByCA.
8	Если отправителем CertReq является владелец карты, запомнить алгоритм и ключ, включенные в CABackKeyData, для шифрования CertRes, посылаемого владельцу карты.
9	Проверить невидимые пункты формы регистрации. Если некоторые пункты необходимы, но заполнены некорректно, вернуть CertRes с CertStatusCode равным rejectedByIssuer.
10	Если все предшествующие проверки прошли успешно, проверить все позиции регистрационной формы, проверить также, что длина, формат и типы символов правильны. Проверить, что все необходимые поля имеются. Если обнаружены какие-то ошибки, вернуть номер позиции и текст сообщений, где обнаружены ошибки в последовательности FailedItems в CertRes с CertStatusCode равным regFormAnswerMalformed.

<
Если верификация не прошла, СА подготавливает и отсылает сообщение CertRes c соответствующим статусом. Если обнаружены ошибки в CertReq, СА отметит эти ошибки в CertRes и приложение ЕЕ должно будет послать повторно CertReq.
При полном успехе система перейдет к аутентификации в финансовом учреждении. Здесь, прежде чем формировать сертификат, проверяется запрос CertReq. Методика этой проверки зависит от типа платежной системы (Brand) и находится за пределами спецификации SET. В зависимости от результатов проверки CertReq, CertRes будет содержать сертификат или статусный код (при неуспехе). Сообщение CertRes будет подписано и в зависимости от характера данных, уложенных в него, зашифровано. Если CertRes уведомляет владельца карты об успехе, то сообщение шифруется с использованием обычного симметричного алгоритма, поддерживаемого приложениями СА и владельца карты. Если сообщение CertRes предназначено для продавца или расчетного центра или возвращает владельцу карты статусные данные, то оно подписывается, но не шифруется.
Если CertReq аутентичен и корректен, а СА сформировал сертификат, используя представленный ключ, то будет возвращен CertRes с завершенным статусом. Если CertRes предназначен для владельца карты и содержит ключ (в CaBackKeyData) для шифрования CertRes, СA сформирует CertRes как SignedData. Осуществляется это следующим образом.

Шаг	Действие
1	CertResData формируется как: Копируется RRPID, LID-EE, список оттисков и Chall-EE3 из CertReq Генерируется или копируется из CertReq (если имеется) LID-CA Опционно заполняется CardLogo, URL, BrandLogo, URL, CardCurrency и/или CardholderMessage (CaMsg) CertStatusCode устанавливается равным “Request Complete” Формируется Nonce-CCA Вычисляются и заносятся оттиски EE-сертификатов, CertThumbs. Если BrandCRLIdentifier не специфицирован в списке оттисков CertReq, заполняется поле BrandCRLIdentifier.
2	Подписать и вложить данные в цифровой конверт, используя технику EncK-инкапсуляции, для CertResData в качестве данных, подлежащих подписке. Подписать данные посредством сертификата подписи СА Установить тип данных SignedData равным id-set-content-CertResData. Вставить новые сертификаты подписи и/или шифрования ЕЕ в сертифицированной части SignedData. Зашифровать подписанные данные, используя сгенерированный вектор инициализации, а также алгоритм и ключ, представленные CABackKeyData в CertReq. Установить тип содержимого EncriptedData равным id-set-content-CertResTBE
3	Сформировать цифровой конверт и послать EE CertRes.

<

Если СА возвращает статус в CertRes, в него для передачи данных продавцу, владельцу карты или расчетному центру включается сообщение EEMessage. Подписанное сообщение CertRes формируется следующим образом:

Шаг	Действие
1	Если СА сгенерировал сертификат, который будет включен в CertRes, выполняется формирование CertResTBS.
2	Если СА не сгенерировал сертификат, т.е. имеет статус, отличный от “Request Complete”, создается CertResData: Копируется LID-EE и Chall-EE3 из CertReq Опционно заносится EEMessage Из табл. 4.6.2.30 заносится значение CertStatusCode Если CertStatusCode установлен равным regFormAnswerMalformed, занести номера позиций (ItemNumbers) и причины (ItemReasons) для каждой ошибочной позиции (FailedItem) в регистрационной форме.
3	Сформировать цифровой конверт и послать конечному пользователю (ЕЕ) CertRes

Формат CertRes в этом случае имеет вид представленный в таблице 4.6.2.29.

Формат CapReq

Таблица 4.6.2.68. Формат CapReq

CapReq	<EncB(M, P, CapReqData, CapTokenSeq), EncBX(M, P, CapReqData, CapTokenSeq, PANToken)> CapTokenSeq является внешним “багажом”. Если имеется маркер PANToken, он должен соответствовать одному CapItem и одному CapToken в CapTokenSeq.
CapReqData	{CapRRTags, [MThumbs], CapItemSeq, [CRqExtensions]}
CapTokenSeq	{[CapToken] +} Один или более CapTokens, соответствующие один-в-один CapItems в CapItemSeq. Любой CapToken может быть опущен, т.е. может равняться нулю.
PANToken	См. табл. 4.6.2.46.
CapRRTags	RRTags. Новый RRPID и Date
MThumbs	Оттиски сертификатов, CRL и BrandCRLIdentifier, хранящиеся в кэше продавца.
CapItemSeq	{CapItem +} Один или более CapItem в упорядоченном массиве
CRqExtensions	Данные в расширении запроса платежа (capture) должны иметь финансовый характер и быть существенными для сообщения capture, посланного расчетному центру, финансовой сети или эмитенту. Данные в этом расширении относятся ко всем позициям запроса оплаты capture. Данные, относящиеся к специфическим позициям, должны помещаться в CapPayload
CapToken	Копируется из соответствующего AuthRes или AuthRevRes
CapItem	{TransIDs, AuthRRPID, CapPayload}
TransIDs	Копируется из соответствующего AuthRes или AuthRevRes
AuthRRPID	RRPID, который появляется в соответствующем AuthReq или AuthRev
CapPayload	См. табл. 4.6.2.69.

Структура данных CapPayload представлена в таблице 4.6.2.69.

Формат CertInqReq

Таблица 4.6.2.31. Формат CertInqReq

CertInqReq	S(EE, CertInqReqTBS)
CertInqReqTBS	{RRPID, LID-EE, Chall-EE3, LID-CA}
RRPID	Идентификатор пары запрос/отклик
LID-EE	Копируется из CertRes
Chall-EE3	Требование ЕЕ по поводу обновления подписи СА
LID-CA	Копируется из CertRes

Центр СА обрабатывает CertInqReq следующим образом:

Шаг	Действие
1	Из входного сообщения извлекается CertInqReq. Подпись CertInqReqTBS верифицируется также как и для CertReq. Если проверка не прошла отклик будет таким как при CertReq(EncX)
2	Проверить, что RRPID соответствует посланному в цифровом конверте. Если соответствия нет, возвращается сообщение об ошибке с ErrorCode равным unknownRRPID.
3	Используя LID-CA в качестве индекса, определяется статус CertReq.
4	Если сертификат сформирован, он посылается ЕЕ в отклике CertInqRes, в противном случае в CertInqRes возвращается актуализованный код CertStatusCode

После обработки CertInqReq СА формирует CertInqRes. Этот отклик имеет ту же структуру и формат, что и CertRes. Обработка CertInqRes происходит аналогично.

Реальный формат сертификатов определяется документом Х.509. Характеристики различных полей такого сертификата представлены в таблице 4.6.2.32.

Формат CertReq

Таблица 4.6.2.26. Формат CertReq

CertReq

<EncX(EE, CA, CertReqData, AcctInfo), Enc(EE, CA, CertReqData)>

Допускается инкапсуляция с двумя подписями. CertReqTBE и AcctInfo могут быть подписаны любым или всеми секретными ключами, соответствующими следующим сертификатам ЕЕ:

секретный ключ нового сертификата подписи

существующий сертификат подписи для запроса сертификата шифрования или

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

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

CertReqData

{RRPID, LID-EE, Chall-EE3, [LID-CA], [Chall-CA], RequestType, RequestDate, [IDData], RegFormID, [RegForm], [CABackKeyData], publicKeySorE, [EEThumb], [Thumbs]}

AcctInfo

<PANData0, AcctData>

Если отправитель запроса – владелец карты, вводится PANData0.

Если отправитель запроса – продавец или получатель, вводится AcctData

RRPID

ID пары запрос/отклик

LID-EE

Копируется из RegFormRes или Me-AqCInitRes

Chall-EE3

Обращение ЕЕ по поводу обновления подписи СА

LID-CA

Копируется из RegFormRes или из Me-AqCInitRes

Chall-CA

Копируется из RegFormRes или из Me-AqCInitRes

RequestType

Смотри таблицу 4.6.2.24

RequestDate

Дата запроса сертификата

IDData

См. табл. 4.6.2.23. Опускается, если ЕЕ является владельцем карты.

RegFormID

Идентификатор, присвоенный СА

RegForm

{ RegFormItems +}

Имена полей копируются из RegFormRes или из Me-AqCInitRes вместе со значениями, внесенными ЕЕ

CABackKeyData

{CAAIgId, CAKey}

publicKeySorE

{[ PublicKeyS], [PublicKeyE]}

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

EEThumb

Оттиск сертификата ключа шифрования, который обновляется

Thumbs

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

PANData0

См. табл. 4.6.2.27

AcctData

См. табл. 4.6.2.28

RegFormItems

{FieldName, FieldValue}

CAAlgId

Идентификатор симметричного алгоритма шифрования

CAKey

Секретный ключ, соответствующий идентификатору алгоритма

PublicKeyS

Предлагаемый для сертификации общедоступный ключ подписи

PublicKeyE

Предлагаемый для сертификации общедоступный ключ шифрования

FieldName

Одно или более имен полей, которые надо отобразить в качестве заполняемой формы в системе отправителя запроса. Это текстовые поля с текстом на языке, специфицированном в RegFormReq или Me-AqCInitReq

FieldValue

Величина, введенная ЕЕ

Формат CertRes

Таблица 4.6.2.29. Формат CertRes

CertRes

<S(CA, CertResData), EncK(CABackKeyData, CA, CertResData)>

EncK-версия этого сообщения необходима только в случае, когда в CertRes включен опционный компонент CAMsg. Эта версия используется, если в CertReq включено поле CABackKeyData

CertResData

{RRPID, LID-EE, Chall-EE3, LID-CA, CertStatus, [CertThumbs], [BrandCRLIdentifier], [Thumbs]}

CABackKeyData

Копируется из CertReq

RRPID

ID пары запрос/отклик

LID-EE

Копируется из CertReq

Chall-EE3

Копируется из CertReq. Источник запроса проверяет соответствие со значением, хранящимся в памяти.

LID-CA

Копируется из CertReq. Если в CertReq его нет, то присваивается новое значение.

CertStatus

{CertStatusCode, [Nonce-CCA], EEMessage], {CaMsg], [FailedItemSeq]}

CertThumbs

Если запрос обслужен, то это список оттисков вложенных сертификатов подписей и/или шифрования

BrandCRLIdentifier

Смотри раздел об идентификаторах списков отмененных сертификатов платежной системы.

Thumbs

Копируется из CertReq.

CertStatusCode

Нумерованный код, указывающий на статус запроса сертификата

Nonce-CCA

Присутствует, если в качестве ЕЕ выступает владелец карты. Этот код представляет собой дополнительный секретный ключ, используемый совместно владельцем карты и ССА.

EEMessage

Сообщение на естественном языке, предназначенное для отображения в системе ЕЕ

CAMsg

{[CardLogoURL], [BrandLogoURL], [CardCurrency], [CardholderMsg]}

FailedItemSeq

{FailedItem+}

CardLogoURL

URL – указатель на логотип эмитента карты

BrandLogoURL

URL - указатель на логотип платежной системы

CardCurrancy

Вид валюта, хранящейся на счете владельца карты

CardholderMsg

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

FailedItem

{ItemNumber, ItemReason}

ItemNumber

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

ItemReason

Причина неудачи. Текстовое поле на естественном языке.

Формат IDData

Таблица 4.6.2.23. Формат IDData

IDData

<MerchantAcquirerID, AcquirerID> (только для продавца и получателя)

MerchantAcquirerID

{MerchantBIN, MerchantBIN}

AcquirerID

{AcquirerBIN, [AcquirerBusinessID]}

MerchantBIN

Идентификационный номер банка для обработки транзакции продавца в его банке (Acquirer)

MerchantID

Идентификатор продавца, присвоенный ему его банком (Acquirer)

AcquirerBIN

Идентификационный номер банка для Acquirer (BIN получателя)

AcquirerBusinessID

Рабочий идентификационный номер банка продавца

Формат Me-AqCInitReq

Таблица 4.6.2.22. Формат Me-AqCInitReq

Me-AqCInitReq	{RRPID, LID-EE, Chall-EE, RequestType, IDData, BrandID, Language, [Thumbs]}
RRPID	ID пары запрос/отклик
LID-EE	Локальный ID; формируется ЕЕ-системой или для нее
Chall-EE	Обращение EE к СА по поводу пригодности подписи
RequestType	Смотри табл. 4.6.2.24
IDData	См. табл. 4.6.2.23
BrandID	BrandID запрошенного сертификата
Langauage	Желательный язык последующих текстов
Thumbs	Список оттисков сертификатов, CRL и BrandCRLIdentifier, хранимых ЕЕ

Формат поля IDData описан в таблице 4.6.2.23.

Primary Account Number) для данной

Таблица 4.6.2.27. Формат PANData0

PANData0	{PAN, CardExpiry, CardSecret, EXNonce}
PAN	Первичный номер счета ( Primary Account Number) для данной карты
CardExpiry	Дата пригодности карты
CardSecret	Предложенная владельцем карты часть секретного ключа PANSecret. Эта величина используется для генерации TransStain.
EXNonce	Новый код (Nonce) для предотвращения атак на PANData0

Формат полей CRL и ограничения для их значений

Таблица 4.6.2.36. Формат полей CRL и ограничения для их значений

Имя поля	Формат и ограничения на значение	Описание
CRL.version (версия)	Целое; V2	Определяет версию CRL. В настоящее время =2.
CRL.signature .algorithmIdentifier	OID и тип	Определяет алгоритм, использованный для подписи CRL
CRL.Issuer	Имя	Содержит DN субъекта для СА, который выпустил устаревший сертификат. Должен совпадать с именем субъекта в сертификате СА
CRL.thisUpdate	Время UTC	Определяет время, когда был сформирован CRL
CRL.nextUpdate	Время UTC	Определяет время, когда CRL устареет
CRL.revokedCertificate .certSerialNumber	Целое	Номер по порядку устаревшего сертификата
CRL. RevokedCertificate .revocationDate	Время UTC	Дата признания сертификата устаревшим
CRL. RevokedCertificate .extensions	Расширения	Не используется в SET
CRL.extensions	Расширения	В этом поле используются два расширения: CRLNumber и AuthorityKeyIdentifier

Следующие СA должны поддерживать CRL в рамках SET:

корневой СА – для поддержки незапланированной замены корневых сертификатов или сертификатов СА платежных систем.

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

геополитические СА – для поддержки незапланированной замены сертификатов CCA, MCA или PCA.

CA расчетного центра - для поддержки незапланированной замены сертификатов ключевого обмена расчетного центра.

Расширение CRLNumber содержит одно целое число. Центр СА, подписывающий CRL, должен инкрементировать это число каждый раз при выпуске нового CRL.

При получении нового CRL должны проводиться следующие проверки:

1. Сначала проверяется подпись:

Используется AuthorityKeyIdentifier расширения CRL для контроля корректности сертификата подписи.

Расширение KeyUsage в сертификате подписи указывает на CRLsign(6)

2. IssuerDN рассматриваемого сертификата должен соответствовать полю IssuerDN в CRL.

3. IssuerDN и устаревший certSerialNumber сравниваются с проверяемым сертификатом

Следующие проверки производятся для того, чтобы выяснить, не входит ли данный сертификат в список CRL:

IssuerDN рассматриваемого сертификата должен соответствовать содержимому поля IssuerDN CRL

certSerialNumber должно соответствовать значению поля revokedCertificates.certSerialNumber списка CRL.

Существующие CRL от одного и того же IssuerDN могут быть удалены, когда успешно прошел проверку CRL с более высоким значением CRLNumber.

ioctl-коды команд для соединителей (Winsock

Таблица 7.12. ioctl-коды команд для соединителей (Winsock 2)

Код операции	Тип входа	Тип выхода	Значение
FIONBIO	unsigned long	Не использ.	Разрешает или запрещает неблокирующий режим соединителя.
FIONREAD	Не используется	unsigned long	Определяет объем информации, который может быть считан с соединителя автоматически.
SIOCATMARK	Не использ.	BOOL	Определяет, будут ли считаны все приоритетные данные.
SIO_ASSOCIATE_HANDLE	Зависит от API	Не использ.	Связывает соединитель с заданным дескриптором интерфейса-партнера.
SIO_ENABLE_CIRCULAR_QUEUEING	Не использ.	Не использ.	Разрешает организацию циклической очереди.
SIO_FIND_ROUTE	struct sockaddr	Не использ.	Запрашивает маршрут до указанного адреса.
SIO_FLUSH	Не использ.	Не использ.	Аннулирует содержимое выходной очереди.
SIO_GET_BROADCAST_ADDRESS	Не использ.	struct sockaddr	Возвращает протокольно-зависимый адрес, предназначенный для использования с WSPSendTo
SIO_GET_QOS	Не использ.	QOS	Возвращает текущую спецификацию QOS для соединителя.
SIO_GET_GROUP_QOS	Не использ.	QOS	Возвращает текущую спецификацию QOS для группы, к которой принадлежит соединитель.
SIO_MULTIPOINT_LOOKBACK	BOOL	Не использ.	Определяет, будут ли данные, посланные в ходе многоточечной сессии, получены соединителем на локальной ЭВМ.
SIO_MULTICAST_SCOPE	int	Не использ.	Определяет режим мультикастинг-обмена.
SIO_SET_QOS	QOS	Не использ.	Устанавливает новую спецификацию качества сервиса для соединителя.
SIO_SET_GROUP_QOS	QOS	Не использ.	Устанавливает новую спецификацию для группы, к которой принадлежит соединитель.
SIO_TRANSLATE_HANDLE	int	Зависит от API	Возвращает соответствующий дескриптор соединителя s, который верен для контекста интерфейса.

В таблице 7.13 представлены основные характеристики базовых SPI (Service Provider Interfaces) процедур передачи данных для Winsock 2.

Коды идентификатора эталона

Таблица 4.4.16.4. Коды идентификатора эталона

ID-код	Внешний эталонный источник
LOCL	В качестве первичного эталона для субсети используются некалиброванные внутренние часы, которые не имеют внешнего источника синхронизации
PPS	Атомные часы или другой источник, выдающий импульс каждую секунду и индивидуально калиброванный с использованием национального стандарта времени
ACTS	Модемная служба NIST (работает через коммутируемую телефонную сеть)
USNO	Модемная служба USNO
PTB	Модемная служба PTB (Германия)
TDF	Радио 164 кГц (Allouis Франция)
DCF	Радио 77.5 кГц (Mainflingen, Германия)
MSF	Радио 60 кГц (Rugby, Англия)
WWV	Радио 2.5, 5, 10, 15, 20 МГц (Ft. Collins, США)
WWVB	Радио 60 кГц (Boulder, US)
WWVH	Радио 2.5, 5, 10, 15 МГц (Кауи Гавайи, США)
CHU	Радио 3330, 7335, 14670 кГц (Оттава, Канада)
LORC	Радионавигационная система LORAN-C
OMEG	Радионавигационная система OMEGA
GPS	Глобальная служба определения местоположения
GOES	Геостационарный спутник контроля за окружающей средой

Поле эталонная временная метка характеризует время, когда локальные часы были установлены или поправлены (64-битовый формат временной метки).

Поле Originate Timestamp (исходная временная метка) соответствует времени, когда клиент направил запрос серверу (64-битовый формат временной метки).

Поле Receive Timestamp характеризует время, когда запрос пришел на сервер (64-битовый формат временной метки).

Поле Transmit Timestamp соответствует времени, когда сервер послал отклик клиенту (64-битовый формат временной метки).

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

Поле дайджест хранит код аутентификации сообщения MAC (Message Authentication Code).

5. Операции клиента SNTP

Клиент SNTP может работать в мультикастном, уникастном и эникаситном режимах. В мультикастном режиме клиент не посылает никаких запросов и ждет широковещательных сообщений (режим 5) от специально выделенного мультикастного сервера.
В уникастном режиме клиент посылает запросы (режим 3) специально выделенному серверу и ожидает от него откликов (режим 4). В эникастном режиме клиент посылает запросы (режим 3) по специально выделенному местному широковещательному или мультикастному адресу и ожидает откликов (режим 4) от одного или более эникастных серверов. Клиент использует первый полученный отклик и устанавливает с соответствующим сервером связь в уникастном режиме. Последующие отклики от данного, или других серверов игнорируются. Запросы номинально посылаются с интервалом от 64 до 1024 секунд, в зависимости от стабильности частоты клиента и от требуемой точности.
Уникастные или эникастные клиенты используют заголовок сообщения NTP, посылают запрос серверу и считывают время дня из поля Transmit Timestamp отклика. Для этой цели все поля заголовка NTP могут быть установлены равными нулю, за исключением первого октета и (опционно) поля Transmit Timestamp. В первом октете поле LI устанавливается равным 0 (никаких предупреждений), а в поле режим заносится код 3 (клиент). Поле VN должно соответствовать номеру версии сервера NTP/SNTP; однако, серверы V.4 воспринимают и предыдущие версии. Серверы V.3 (RFC-1305) и версии 2 (RFC-1119) воспринимают предшествующие версии, включая версию 1 (RFC-1059). Версия 0 (RFC-959) в настоящее время уже не поддерживается.
Рекомендуется чтобы клиенты использовали последнюю версию, которую поддерживает выбранный сервер.
Чтобы вычислить полную циклическую задержку d и смещение локальных часов по отношению к серверу t, клиент устанавливает значение поля transmit timestamp в запросе равным времени дня согласно часам клиента и в соответствии с форматом временных меток NTP. Сервер копирует этот код в поле originate timestamp отклика и устанавливает поле receive timestamp и transmit timestamp в соответствии с показанием своих часов.
Когда будет получен отклик от сервера, клиент определяет значение переменной Destination Timestamp, как время прибытия по своим часам. В таблице 4.4.16.5.рассмотрены все 4 типа временных меток.

Коды операций

Таблица 7.9. Коды операций

Код операции	Input Type	Output Type	Значение
SIO_ASSOCIATE_HANDLE	зависит от API	не использ.	Связывает соединитель с заданным дескриптором интерфейса-партнера.
SIO_ENABLE_CIRCULAR_QUEUEING	не использ.	не использ.	Разрешает организацию кольцевой очереди.
SIO_FIND_ROUTE	struct sockaddr	не использ.	Запрос маршрута до заданного адреса.
SIO_FLUSH	не использ.	не использ.	Аннулирует текущее содержимое очереди на отправку.
SIO_GET_BROADCAST_ADDRESS	не использ.	struct sockaddr	Определяет протокольно-зависимый широковещательный адрес для использования в sendto/WSASendTo
SIO_GET_QOS	не использ.	QOS	Определяет текущую спецификацию соединителя.
SIO_GET_GROUP_QOS	не использ.	QOS	Определяет спецификацию группы, к которой принадлежит соединитель
SIO_MULTIPOINT_LOOKBACK	BOOL	не использ.	Определяет, будут ли данные, посланные в ходе многоточечной сессии, получены соединителем локальной ЭВМ.
SIO_MULTICAST_SCOPE	int	не использ.	Определяет режим, в котором будут осуществляться мультикастинг-обмены.
SIO_SET_QOS	QOS	не использ.	Устанавливает новую спецификацию для соединителя.
SIO_SET_GROUP_QOS	QOS	не использ.	Устанавливает новую спецификацию группы, к которой принадлежит соединитель.
SIO_TRANSLATE_HANDLE	int	зависит от API	Возвращает дескриптор для соединителя s, который соответствует контексту интерфейса-партнера.

Оператор WSAAccept устанавливает условное соединение и имеет следующую структуру параметров.

WSAAccept (

IN	SOCKET	s,
OUT	struct sockaddr FAR	addr,
IN OUT	LPINT	addrlen,
IN	LPCONDITIONPROC	lpfnCondition,
IN	DWORD	dwCallbackData

);

s	дескриптор соединителя, который находится в режиме listen.
addr	опционный указатель на буфер (структуру), где должен храниться адрес подключаемого объекта, формат адреса определяется типом протокола, заданным при создании соединителя.
addrlen	Опционный указатель на целую переменную, которая определяет длину аргумента addr.
lpfnCondition	Адрес опционной условной процедуры, которая на основе полученной информации, создает группу или подключает соединитель к уже существующей группе.
dwCallbackData	Параметр, возвращаемый приложению. Этот параметр не интерпретируется WinSock.

<
IN и OUT указывают на то, является ли данный параметр входным или выходные.
Программа извлекает очередную заявку на соединение из очереди соединителя s и проверяет с помощью специфицированной программы выполнение условий соединения. Если условия выполнены, возвращается флаг CF_ACCEPT, программа создает новый соединитель и осуществляет подключение его к группе в соответствии с параметром g, выработанным программой проверки условий. Вновь созданный соединитель имеет те же параметры, что и s, включая те, что задаются операторами контроля WSAAsyncSelect или WSAEventSelect. Если программа проверки условия вернула флаг CF_REJECT, запрос на соединение аннулируется. При невозможности принять решение немедленно, программа проверки условия должна вернуть флаг CF_DEFER, при этом никаких действий не предпринимается. Когда приложение будет готово обслужить запрос на соединение, оно снова запустит процедуру WSAAccept и пришлет либо CF_ACCEPT, либо CF_REJECT в качестве результата проверки условий.
Для соединителей, которые остаются в блокирующем режиме, когда в очереди нет запросов на соединение, WSAAccept блокирует вызывающую программу до появления заявки на соединение. Для соединителей неблокирующего типа, когда очередь пуста, оператор WSAAccept вернет флаг ошибки.
При завершении процедуры в addrlen будет записана реальная длина адреса в байтах. Если addr и (или) addrlen равны нулю, это означает, что нет никакой информации об адресе удаленного адресата. В противном случае эти параметры несут в себе реальную информацию не зависимо от результатов проверки условий. Прототип программы проверки условий имеет формат:

int CALLBACK

ConditionFunc(

IN	LPWSABUF	lpCallerId,
IN	LPWSABUF	lpCallerData,
IN OUT	LPQOS	lpSQOS,
IN OUT	LPQOS	lpGQOS,
IN	LPWSABUF	lpCalleeId,
OUT	LPWSABUF	lpCalleeData,
OUT	GROUP FAR *	g
IN	DWORD	dwCallbackData

);
ConditionFunc представляет собой указатель имени программы, которая служит для проверки условий. В 16-битной версии Windows, эта программа выполняется в рамках той же сессии, что и WSAAccept, поэтому вызов каких-либо иных WinSock операторов кроме WSAIsBlocking и WSACancelBlockingCall не возможен.

Программа проверки условий должна находиться в DLL или прикладном модуле. Для определения адреса программы проверки условий следует пользоваться оператором MakeProcInstance.
Переменные lpCallerId и lpCallerData являются параметрами, которые содержат адрес партнера и любую пользовательскую информацию, которая была прислана вместе с запросом на соединение.
lpSQOS представляет собой указатель на текущую спецификацию QOS соединителя s (по одной для каждого из концов виртуального канала), за которой следуют дополнительные параметры, заданные провайдером. Нулевое значение lpSQOS указывает на то, что вызывающая сторона не задала значения QOS.
lpGQOS - указатель на спецификацию QOS группы соединителей, созданной запрашивающей стороной (для каждого из направлений обмена), за которой следуют дополнительные параметры, заданные провайдером.
lpCalleeId представляет собой локальный адрес вызывающей стороны.
lpCalleeData используется программой проверки условий для записи результатов ее работы.
lpCalleeData первоначально содержит размер буфера, предназначенного для сервис провайдера. Положение буфера определяется указателем lpCalleeData->buf. Программа проверки условий должна скопировать lpCalleeData->len байт в lpCalleeData->buf, а затем провести актуализацию lpCalleeData->len, с тем чтобы сообщить действительное число переданных байтов.
В таблице 7.10 представлен перечень кодов-сообщений об ошибках вместе с их эквивалентами для Berkley-соединителей.

Коды ошибок

Таблица 4.4.13.3. Коды ошибок

Статус ошибки

Имя ошибки

Описание

Noerror

Все в порядке;

Toobig

Объект не может уложить отклик в одно сообщение;

Nosuchname

В операции указана неизвестная переменная;

badvalue

В команде set использована недопустимая величина или неправильный синтаксис;

Readonly

Менеджер попытался изменить константу;

Generr

Прочие ошибки.

Если произошла ошибка, поле индекс ошибки (error index) характеризует, к какой из переменных это относится. error index является указателем переменной и устанавливается объектом управления не равным нулю для ошибок badvalue, readonly и nosuchname. Для оператора TRAP (тип PDU=4) формат сообщения меняется.

Коды TRAP

Таблица 4.4.13.4. Коды TRAP

Тип TRAP	Имя TRAP	Описание
0	Coldstart	Установка начального состояния объекта.
1	Warmstart	Восстановление начального состояния объекта.
2	Linkdown	Интерфейс выключился. Первая переменная в сообщении идентифицирует интерфейс.
3	Linkup	Интерфейс включился. Первая переменная в сообщении идентифицирует интерфейс.
4	Authenticationfailure	От менеджера получено snmp-сообщение с неверным паролем (community).
5	EGPneighborloss	R$GP-партнер отключился. Первая переменная в сообщении определяет IP-адрес партнера.
6	Entrprisespecific	Информация о TRAP содержится в поле специальный код.

Для тип TRAP 0-4 поле специальный код

должно быть равно нулю. Поле временная метка содержит число сотых долей секунды (число тиков) с момента инициализации объекта управления. Так прерывание coldstart выдается объектом через 200 мс после инициализации.

В последнее время широкое распространение получила идеология распределенного протокольного интерфейса DPI (Distributed Protocol Interface). Для транспортировки snmp-запросов может использоваться не только UDP-, но и TCP-протокол. Это дает возможность применять SNMP-протокол не только в локальных сетях. Форматы SNMP-DPI-запросов (версия 2.0) описаны в документе RFC-1592. Пример заголовка snmp-запроса (изображенные поля образуют единый массив; см. Рисунок 4.4.13.3):