Алгоритм Эль Гамаля

6.4.5 Алгоритм Эль Гамаля

Алгоритм Эль-Гамаля может использоваться для формирования электронной подписи или для шифрования данных. Он базируется на трудности вычисления дискретного логарифма. Для генерации пары ключей сначала берется простое число p и два случайных числа g и x, каждое из которых меньше p. Затем вычисляется:

Архитектура сетей Ethernet

4.1.1.1 Архитектура сетей Ethernet

Не трудно видеть, что все перечисленные физические среды используют последовательный формат передачи информации. К этой разновидности относится и Ethernet (10 Мбит/с ±0,01%). Фирма Ксерокс осуществила разработку протокола Ethernet в 1973 году, а в 1979 году объединение компаний Ксерокс, Интел и DEC (DIX) предоставило документ для стандартизации протокола в IEEE. Предложение с небольшими изменениями было принято комитетом 802.3 в 1983 году. Кадр Ethernet имеет формат, показанный на Рисунок 4.1.1.1.1.

Безопасный обмен сообщениями

4.6.4.5. Безопасный обмен сообщениями

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

Формат 1 следует спецификации ISO/IEC 7816-4, где поле данных кодируется согласно BER-TLV и правилам ASN.1/ISO 8825. Этот формат задается младшим полубайтом класса команды равным 0xC. Формат предполагает также, что заголовок команды включается в вычисление MAC (Message Authentication Code).

Формат 2 не использует кодирования BER-TLV. В этом случае информационные объекты, содержащиеся в поле данных и их длины должны быть известны отправителю команды и выбранному приложению. Согласно спецификации ISO/IEC 7816-4 этот формат задается младшим полубайтом байта класса, который должен быть равен 0х4.

Поле данных команды в случае формата 1 состоит из следующих TLV (Tag Length Value) информационных объектов, как это показано на рисунке 4.6.4.13.

Блок-схема реализации алгоритма доступа к сетевой среде CSMA/CD

Рисунок 4.1.1.1.5 Блок-схема реализации алгоритма доступа к сетевой среде CSMA/CD

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

Диаграмма передачи символов по шине I/O

Рисунок 4.6.4.7. Диаграмма передачи символов по шине I/O

Перед началом передачи символа шина I/O должна находиться в состоянии H. Для передачи любого символа требуется 10 бит (смотри рисунок 4.6.4.7). Стартовый бит должен иметь уровень L и номер 1. Последний бит представляет собой бит четности (нечет). Стартовый бит детектируется путем стробирования шины I/O. Время стробирования составляет 0,2 t. Время между началами передачи последовательных символов составляет t(10±0,2) плюс время выдержки. Во время выдержки ICC и терминал должны находиться в режиме приема. (H).

Определены два протокола: символьный (Т=0) и блочный (Т=1). ICC поддерживает один из этих протоколов, терминалы поддерживают оба. Тип протокола определяется значением символа TD1. При отсутствии в ATR TD1 рабочим считается протокол Т=0. Физический уровень обмена должен согласовываться с обоими протоколами. Минимальный интервал между лидирующими битами двух последовательных символов, посылаемых ICC, равно 12t. Максимальный интервал между стартовыми битами двух последовательных символов (Work Waiting Time) не должно превышать (960хDxWI) t (параметры D и WI пересылаются с помощью символов TA1 и TC2, соответственно). Если это время будет превышено, терминал не позднее, чем спустя 960t должен начать процесс дезактивации.

В режиме T=0, если ICC или терминал детектировали при передаче/приеме символа ошибку четности, шина I/O переводится в состояние L, чтобы передающая сторона узнала об ошибке.

На транспортном уровне терминала TTL (Terminal Transport Layer) данные всегда передаются через шину I/O так, что старший байт следует первым. Будет ли первым старший бит, определяется символом TS, возвращаемым в ответ на команду сброс ATR. Такой отклик может содержать строку символов.

При отклике на сброс минимальное время между стартовыми битами последовательных символов составляет 9600t. ICC передает все символы отклика в пределах 19200 t. Это время измеряется между стартовым битом первого символа TS и после 12 t от начала последнего символа. Число символов в отклике зависит от транспортного протокола и поддерживаемых управляющих параметров.

ICC может опционно поддерживать более одного транспортного протокола, но одним из таких протоколов должен быть Т=0 или Т1. Символы, присылаемые в рамках ATR, представлены в таблице 4.6.4.6.

Диаграмма реализации “холодного” сброса

Рисунок 4.6.4.4. Диаграмма реализации “холодного” сброса

После прихода 40000-45000 тактов после Т0 шина RST переходит в состояние H. Этот момент времени называется T1. Начало отклика на Reset со стороны ICC наступает спустя 400-40000 тактов после T1 (время t1). Если за это время отклик со стороны ICC не поступает, терминал в пределах 50 мсек деактивирует контакты микросхемы на карте. Диаграмма холодного сброса ICC показана на Рисунок 4.6.4.4.

Команда сброса может поступать и в процессе обычной работы – так называемый “теплый” сброс. Временная диаграмма такого сброса показана на Рисунок 4.6.4.5.

Диаграмма статической аутентификации данных

Рисунок 4.6.4.12. Диаграмма статической аутентификации данных

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

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

Сертификат общедоступного ключа эмитента карты. Этот элемент имеет переменную длину и предоставляется центром сертификации эмитенту карты.

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

Остаток (remainder) общедоступного ключа эмитента. Опционный элемент переменной длины ICC.

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

Для поддержки статической аутентификации ICC должна содержать статические прикладные данные, подписанные секретным ключом эмитента. Общедоступный ключ эмитента записывается в ICC вместе с сертификатом общедоступного ключа. Модуль общедоступного ключа сертификационного ключа имеет NCA байт, где NCA ? 248, показатель степени этого ключа равен 2, 3 или 216+1.

Общедоступный ключ эмитента имеет модуль ключа, содержащий NЭ байт, где NЭ < 248 и NЭ < NCC. Если NЭ > (NCC - 36), модуль общедоступного ключа эмитента делится на две части. Одна часть, состоящая из NCC -36 старших байт модуля (левые цифры общедоступного ключа эмитента), и вторая часть с оставшимися NЭ - (NCC - 36) младшими байтами. Показатель степени общедоступного ключа эмитента должен быть равен 2, 3 или 216+1.

Вся необходимая информация, необходимая для статической аутентификации записывается в ICC (смотри таблицу 4.6.4.18 и 4.6.4.19). За исключением RID (Registered Application Provider Identifier), который может быть получен из AID (Application Identifier), эта информация может быть получена посредством команды READ RECORD. Если что-то из этой информации отсутствует, аутентификация терпит неудачу.

Динамическая аутентификация данных

4.6.4.4. Динамическая аутентификация данных

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

Ethernet (IEEE

4.1.1 Ethernet (IEEE 802.3)

Номер раздела	Название раздела	Объем в страницах	Объем в кбайт
4.1.1	Ethernet (IEEE 802.3)	1	1
4.1.1.1	Архитектура сетей Ethernet	11	12
4.1.1.2	Fast Ethernet	10	9
4.1.1.3	Интернет в Ethernet	9	7
4.1.1.4	Повторители, мосты, мультиплексоры, переключатели и маршрутизаторы	7	7

Сеть Ethernet разработана в 1976 году Меткальфом и Боггсом (фирма Ксерокс). Ethernet совместно со своей скоростной версией Fast Ethernet занимает в настоящее время абсолютно лидирующую позицию (а на подходе еще и гигабитный Ethernet). Единственным недостатком данной сети является отсутствие гарантии времени доступа к среде (и механизмов, обеспечивающих приоритетное обслуживание), что делает сеть малоперспективной для решения технологических проблем реального времени. Определенные проблемы иногда создает ограничение на максимальное поле данных, равное ~1500 байт.

Формат для зашифрованных командных данных

Рисунок 4.6.4.14. Формат 1 для зашифрованных командных данных

Тэг, согласно спецификации ISO/IEC 7816-6 определяется характером исходных (незашифрованных данных). Четный тэг используется, если объект должен быть включен в вычисление МАС; во всех остальных случаях тэг должен быть нечетным.

В случае формата 2 поле данных команды шифруется как целое, исключение составляет MAC, если он присутствует (см. Рисунок 4.6.4.15)

Значение 1	Значение 2
Криптограмма (зашифрованные данные)	МАС (если имеется)

Формат кадра сетей ethernet (цифры в верхней части рисунка показывают размер поля в байтах)

Рисунок 4.1.1.1.1 Формат кадра сетей ethernet (цифры в верхней части рисунка показывают размер поля в байтах)

Поле преамбула содержит 7 байт 0хАА и служит для стабилизации и синхронизации среды (чередующиеся сигналы CD1 и CD0 при завершающем CD0), далее следует поле SFD (start frame delimiter = 0xab), которое предназначено для выявления начала кадра. Поле EFD (end frame delimiter) задает конец кадра. Поле контрольной суммы (CRC - cyclic redundancy check), также как и преамбула, SFD и EFD, формируются и контролируются на аппаратном уровне. В некоторых модификациях протокола поле efd не используется. Пользователю доступны поля, начиная с адреса получателя и кончая полем информация, включительно. После crc следует межпакетная пауза (IPG - interpacket gap – межпакетный интервал) длиной 9,6 мксек или более. Максимальный размер кадра равен 1518 байт (сюда не включены поля преамбулы, SFD и EFD). Интерфейс просматривает все пакеты, следующие по кабельному сегменту, к которому он подключен, ведь определить, корректен ли принятый пакет и кому он адресован, можно лишь приняв его целиком. Корректность пакета по CRC, по длине и кратности целому числу байт производится после проверки адреса места назначения. Вероятность ошибки передачи при наличии crc контроля составляет ~2-32. При вычислении CRC используется образующий полином:

G(x) = x32 + x26 + x23 + x22 + x16 + x12 + x11 + x10 + x8 + x7 + x5 + x4 + x2 + x + 1.

Алгоритм вычисления CRC сводится к вычислению остатка от деления кода M(x), характеризующего кадр, на образующий полином G(x) (Carrier Sense Multiple Access with Collision Detection (CSMA/CD) Access Method and Physical Layer Specification. Published by IEEE (802.3-1985). Wiley-Interscience, John & sons, inc.). CRC представляет собой дополнение полученного остатка R(x). CRC пересылается, начиная со старших разрядов. Схема взаимодействия различных субуровней при реализации протокола IEEE 802.3 показана на рис 4.1.1.1.2. Выше llc размещаются верхние субуровни, включая прикладной. Через AUI данные передаются с использованием манчестерского кода.

Формат mac-адреса

Рисунок 4.1.1.1.4. Формат mac-адреса

В верхней части рисунка указана длина полей адреса, в нижней – нумерация разрядов. Субполе I/G представляет собой флаг индивидуального или группового адреса. I/G=0 – указывает на то, что адрес является индивидуальным адресом сетевого объекта. I/G=1 характеризует адрес как мультикастинговый, в этом случае дальнейшее разбиение адреса на субполя теряет смысл. Субполе UL является флагом универсального или местного управления (определяет механизм присвоения адреса сетевому интерфейсу). U/L=1 указывает на локальную адресацию (адрес задан не производителем и ответственность за уникальность лежит на администраторе LAN). U/L=I/G=0 характерно для стандартных уникальных адресов, присваиваемых интерфейсу его изготовителем. Субполе OUI (organizationally unique identifier) позволяет определить производителя сетевого интерфейса. Каждому производителю присваивается один или несколько OUI. Размер субполя позволяет идентифицировать около 4 миллионов различных производителей. За корректность присвоения уникального адреса интерфейса (OUA – organizationally unique address) несет ответственность производитель. Двух интерфейсов одного и того же производителя с идентичными номерами не должно существовать. Размер поля позволяет произвести примерно 16 миллионов интерфейсов. Комбинация oui и oua составляют UAA (universally administrated address = IEEE-адрес).

Если в поле кадра протокол/тип записан код менее 1500, то это поле характеризует длину кадра. В противном случае – это код протокола, пакет которого инкапсулирован в кадр Ethernet.

Доступ к каналу Ethernet базируется на алгоритме CSMA/CD (carrier sense multiple access with collision detection). В Ethernet любая станция, подключенная к сети, может попытаться начать передачу пакета (кадра), если кабельный сегмент, к которому она подключена, свободен. Свободен ли сегмент, интерфейс определяет по отсутствию “несущей” в течение 9,6 мксек. Так как первый бит пакета достигает остальных станций сети не одновременно, может случиться, что попытку передачи совершат две или более станций, тем более что задержки в повторителях и кабелях могут достигать достаточно больших величин.
Такие совпадения попыток называются столкновениями. Столкновение (коллизия) распознается по наличию в канале сигнала, уровень которого соответствует работе двух или более трансиверов одновременно. При обнаружении столкновения станция прерывает передачу. Возобновление попытки может быть произведено после выдержки (кратной 51,2 мксек, но не превосходящей 52 мсек), значения которой является псевдослучайной величиной и вычисляется каждой станцией независимо (t= RAND(0,2min(n,10)), где n – содержимое счетчика попыток, а число 10 - backofflimit).

После выдержки станция увеличивает на единицу счетчик попыток и начинает очередную передачу. Предельное число попыток по умолчанию равно 16, если число попыток исчерпано, связь прерывается и выдается соответствующее сообщение. Передаваемый длинный кадр способствует “синхронизации” начала передачи пакетов несколькими станциями. Ведь за время передачи с заметной вероятностью может возникнуть необходимость передачи у двух и более станций. В момент, когда они обнаружат завершение пакета, будут включены таймеры IPG. К счастью информация о завершении передачи пакета доходит до станций сегмента не одновременно. Но задержки, с которыми это связано, являются также причиной того, что факт начала передачи нового пакета одной из станций не становится известным немедленно. При вовлечении в столкновение нескольких станций они могут уведомить остальные станции об этом, послав сигнал “затора” (jam - не менее 32 бит). Содержимое этих 32 бит не регламентируется. Такая схема делает менее вероятным повторное столкновение. Источником большого числа столкновений (помимо информационной перегрузки) может служить запредельная суммарная длина логического кабельного сегмента, слишком большое число повторителей, обрыв кабеля, отсутствие терминатора (50-омного согласователя кабеля) или неисправность одного из интерфейсов. Но сами по себе столкновения не являются чем-то негативным – это механизм, регулирующий доступ к сетевой среде.

Под логическим кабельным сегментом (иногда называемым областью столкновений) подразумевается один или несколько кабельных сегментов, объединенных повторителями.Анализ столкновений является одним из средств эффективной диагностики сети. Локальные столкновения (столкновения на сегменте, к которому непосредственно подключена рабочая станция) порождают укороченные пакеты-фрагменты (ведь их передача прерывается) с длиной менее 64 октетов. Большинство трансиверов и репитеров имеют на своих передних панелях индикаторы столкновений. Блок-схема реализации протокола CSMA/CD показана на Рисунок 4.1.1.1.4. Особое внимание я бы хотел обратить на влияние сигнала jam. В процессе пересылки столкнувшихся пакетов и за время передачи сигнала jam другие узлы могли захотеть что-то передать. Если таких узлов больше одного, то это приведет к синхронизации начала передачи этими узлами и к увеличению вероятности столкновения. Практически такую “синхронизацию” может осуществить любой достаточно длинный пакет. Такая синхронизация является причиной “коллапса” сети при большой загрузке.

Формат поля данных команды

Рисунок 4.6.4.15. Формат 2 поля данных команды

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

Для увеличения безопасности может использоваться PIN (Personal Identification Number). Верификация PIN осуществляется терминалом с использованием асимметричного алгоритма (общедоступный и секретный ключи).

Более полное описание технологии EMV вы можете найти по адресу (английская версия): ftp://saturn.itep.ru/~emvcard.pdf

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

Формат поля данных команды для безопасного обмена сообщениями

Рисунок 4.6.4.13. Формат 1 поля данных команды для безопасного обмена сообщениями

Данные команды, если имеются, должны быть подписаны. Если поле данных закодировано согласно BER-TLV, оно либо не должно принадлежать контекстному классу (тэг лежит вне диапазона 80-BF), либо иметь четный тэг. Вторым информационным объектом является MAC. Его тэг равен 0х8Е, а его длина лежит в диапазоне 4-8 байт.

В случае формата 2 МАС не кодируется BER-TLV и всегда является последним элементом информационного поля, а его длина лежит в пределах 4-8 байт.

Вычисление s байтов МАС (4?s?8) осуществляется согласно ISO/IEC9797 с использованием 64-битового блочного шифра ALG в режиме CBC.

Процедура формирования МАС начинается с получения ключа сессии из мастерного ключа МАС ICC. Ключ сессии KS для безопасного обмена сообщениями получается из уникальных мастерных ключей MK с привлечением непредсказуемых данных R, так что KS := F(KS)[R]. Единственным требованием к функции F является то, что число возможных ее значений достаточно велико и равномерно распределено.

При использовании формата 1 сообщение состоит из заголовка команды APDU (Application Protocol Data Unite = CLA INS P1 P2) и командной информации (если таковая имеется).

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

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

Формат зашифрованных командных данных показан на рисунке 4.6.4.14.

Тэг	Длина	Значение
T	L	Криптограмма (зашифрованные данные)

Формат записи каталога PSE

Рисунок 4.6.4.11. Формат записи каталога PSE

Содержимое полей элемент каталога характеризуется в таблицах 4.6.4.16 и 4.6.4.17.

Электронная торговля в Интернет

4.6 Электронная торговля в Интернет

Бурное развитие Интернет во всем мире и в РФ открыло ряд направлений бизнеса: предоставление услуг Интернет, электронная почта, IP-телефония и т.д. На подходе сфера сетевых развлечений и виртуальной реальности, этому способствует впечатляющий прогресс в разработке мультимедиа стандартов и протоколов MPEG-4 и MPEG-7. Банки давно использовали специализированные сети для расчетов, в последнее время они стали осваивать возможности общедоступных сетей. Реклама через Интернет стала высокодоходной деятельностью даже в России. Особое положение в этом ряду занимает электронная коммерция через Интернет. Более года назад был разработан торговый протокол IOTP, который перекрывает почти неограниченный спектр услуг, начиная от торговых сделок и оплаты, вплоть до доставки и послепродажного обслуживания, разработан целый спектр платежных протоколов, что сняло последние технические проблемы на пути внедрения торговли через сети Интернет. Одной из проблем была слабая защищенность транспортировки данных по каналам Интернет. Нельзя сказать, что в этой сфере решены все проблемы, но, тем не менее, за последние годы достигнуты впечатляющие успехи. В основном это связано с разработкой эффективных алгоритмов и программ шифрования (симметричных и асимметричных), аутентификации, электронной подписи, сертификации и безопасных каналов (например, TSL). Электронная торговля бурно развивается, прежде всего, в США, но и в России с несколькими миллионами пользователей Интернет у этого вида бизнеса неплохие шансы уже сегодня. В разделе 15, написанном Сергеем Джужей (выпускником кафедры ТСС МФТИ), приведены примеры практического воплощения подобных проектов.

В “МК” за 11-12-2001 появилась заметка “Космонавты сходили по магазинам прямо на орбите”, где сообщалось о покупках сделанных космонавтами В. Дежуровым и М. Тюриным с борта международной космической станции. Покупки были осуществлены с помощью виртуальной платежной карты VISA. Понятно, что торговля в космосе не станет в ближайшее время бурно развивающимся бизнесом, это лишь говорит о впечатляющих возможностях новых технологий.

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

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

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

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


Для россиянина это звучит как сказка. Разные торговые системы базируются на удаленном доступе типа telnet (SSH) или на технологии WEB-серверов (SSL).

Многим знакома компания, торгующая книгами amazon.com. Появились аналогичные предложения по книгам, CD, видеокассетам и другим мелочам и в России. Прогресс этой ветви бизнеса сдерживается отсутствием развитой системы электронных платежей, да и российская банковская система совершенно не отвечает своему основному назначению. По сложившейся традиции российский банкир считает деньги вкладчика своими, и в соответствии с этой концепцией строит свою финансовую политику. Скажу прямо, я не доверю российскому банкиру и рубля, солидный швейцарский, немецкий или американский банк другое дело. А ведь банковское дело не может существовать без доверия.



Основные проблемы торговли через Интернет



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

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


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

Так как современный бизнес повсеместно базируется на использовании вычислительной техники (ЭВМ, электронные кассовые аппараты, банкоматы и пр.), внедрение электронной коммерции является естественным процессом.

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

www.tolly.com).


Рекламный бизнес через Интернет в США только в 1995 году принес 55 миллионов долларов, сейчас эти объемы превзойдены более чем на порядок.

Интернет с его TCP/IP транспортом не может считаться безопасным. По этой причине разработки последних лет были ориентированы на решение этой проблемы. Разработаны протоколы STT (Secure Transaction Technology), SSL, TLS, L2TP, SHTTP, SEPP (Secure Electronic Payment Protocol) и, наконец, SET (Secure Electronic Transactions), предусмотрены специальные меры и в новом протоколе IPv6. Большинство WEB-серверов используют OS UNIX, где администратор системы (root) имеет привилегии, открывающие ему доступ ко всем каталогам и файлам. Это создает еще один источник угроз.

С начала 90-х годов началось развитие электронных платежных средств на основе кредитных карт со встроенными микропроцессорами (Integrated Circuit Card Specifications for Payment Systems). Такие карты обеспечивают более высокий уровень безопасности, так как могут предложить надежную аутентификацию самой карты и ее владельца. Процессор может использовать записанные в нем индивидуальные ключи шифрования, известные только банку эмитенту карты и/или ее пользователю. Карта имеет 8 внешних контактов (см. раздел 4.5). Стандарт на такие карты описан в документе ISO 7816 (Identification cards – Integrated circuit(s) cards with contacts). Этот стандарт базируется на нескольких более общих стандартах, имеющих отношения к идентификационным картам, – ISO 7810, ISO 7811, ISO 7812 и ISO 7813. Смарт-карта содержит ИС (20х20мм), где на одном кристалле интегрирован 8-битовый процессор, выполняющий все логические и вычислительные операции (10МГц); ROM – память, ориентированная только на чтение, запись в которую производит изготовитель ИС и где хранится операционная система и прикладные программы (16K); EEPROM – ROM с возможностью электрической перезаписи, которая предназначена для записи и хранения балансовых данных и индивидуальной информации владельца карты (8K); RAM> – оперативная память (512 байт); система ввода-вывода (приведенные цифры относятся к карте Mondex).


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

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

Объединение лидеров в этой области – Europay, MasterCard и VISA разработало спецификацию EMV (по первым буквам фирм участниц; декабрь 1993 года, в 1995-96 опубликованы улучшенные версии). Серьезным ограничением в этой области является отсутствие единого международного стандарта.

За последние годы разработано много различных систем выполнения платежей: ASH, Achex, BankNet, BidPay, BillPoint, BIPS, CAFE, Cartio, CashBox, CyberCash, DebitNet, DigiCash, DigiGold, eCash, E-gold, EMV, Gmoney, HashCash, iBill, IPAY, iPIN, Kagi, MagnaCash, Mondex, PayCash, PayPal, PayWord, PCPay, PocketPass, MicroMint, Millicent, NetCard, NetCash, NetCheque, NetPay, NetChex, Qpass, QuickCommerce, SOX, SET, TeleCheck, Transfer, WebCharge, WebMoney, WiSP, WorldPay, Ziplock и т.д. (смотри, http://ganges.cs.tcd.ie/mepeirce/Project/oninternet.html), которые обеспечивают расчеты в широком диапазоне требований по надежности и безопасности.


Каждому уровню цен, товаров или услуг должен соответствовать определенный вид электронных платежей. Первой безопасной сетевой системой платежей была First Virtual (1995 г). Приведенный перечень систем платежей является достаточно случайным и неполным. Из этого списка ряд систем работают в РФ (например, WebMoney Transfer и PayCash). Разработано и используется уже десятки таких систем, которые прокладывают дорогу чисто электронным деньгам. Область использования наличных бумажных и металлических денег постепенно сужается и со временем этот традиционный вид платежей уйдет в историю (см., например, статью “Будущее денег”

http://www.businessweek.com/1995/24/b3428001.htm). Для РФ новые платежные системы, работающие без кредитных карт, особенно привлекательны, так как число граждан России, имеющих такие карты, незначительно. Внедрение электронных денег, решая многие проблемы, ставит ряд новых.

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

Как будут решаться проблемы налогов? Ведь в этом случае трудно отследить движение денег из-за его глобального характера.

Кто должен определить стандарты на электронные деньги и операции с ними?

Кто и как будет обеспечивать безопасность операций и защиту интересов покупателей-клиентов?

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


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

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

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

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

До недавнего времени программы продавались в коробках, произведенных фирмой разработчиком (практически как книги). Новейшей тенденцией является торговля программами (пока дешевыми) через Интернет. Для этого имеются все средства и предпосылки. Но эта схема порождает немало юридических и коммерческих проблем. Здесь и упомянутая проблема налогов (пока в США торговля через Интернет не облагается налогами), и нарушения авторских прав. Ведь нужно определить, кто должен платить налоги, дилер, продавший программу, или фирма разработчик, а это не безразлично, если они расположены в разных странах. Да и взаимоотношения между дилером и разработчиком нужно как-то урегулировать, так как нужен надежный контроль за проданным количеством копий программы.Где здесь место таможни (пока продавались коробки с программами, были сопроводительные бумаги, на которых можно было после оплаты сбора поставить штамп “Таможня дала добро”)? Сходные проблемы ждут разработчиков и продавцов компьютерных игр, музыкальных CD и DVD-дисков, а в перспективе очень многих других товаров.

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

Команды

4.6.4.1. Команды

Команды всегда инициируются прикладным уровнем терминала TAL (Terminal Application Layer), который посылает инструкции ICC через транспортный уровень TTL (Terminal Transport Layer). Команда содержит последовательность из 5 байт: CLA, INS, P1, P2 и P3.

Имя байта	Назначение
CLA	Класс команды (1 байт).
INS	Код инструкции (1 байт).
P1 и P2	Cодержат дополнительные специфические параметры (по 1 байту).
Р3	Указывает либо длину посылаемых в команде данных, либо максимальную длину данных, которые должны быть присланы в отклике от ICC (зависит от кода INS).

Эти 5 байт вместе с байтами данных образуют командный блок протокольной информации C-TPDU для Т=0.

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

Обнаружение ошибок

2.7 Обнаружение ошибок

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

Простейшим способом обнаружения ошибок является контроль по четности. Обычно контролируется передача блока данных (М бит). Этому блоку ставится в соответствие кодовое слово длиной N бит, причем N>M. Избыточность кода характеризуется величиной 1-M/N. Вероятность обнаружения ошибки определяется отношением M/N (чем меньше это отношение, тем выше вероятность обнаружения ошибки, но и выше избыточность).

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

Пусть А и Б две двоичные кодовые последовательности равной длины. Расстояние Хэмминга между двумя этими кодовыми последовательностями равно числу символов, которыми они отличаются. Например, расстояние Хэмминга между кодами 00111 и 10101 равно 2.

Можно показать, что для детектирования ошибок в n битах, схема кодирования требует применения кодовых слов с расстоянием Хэмминга не менее N+1. Можно также показать, что для исправления ошибок в N битах необходима схема кодирования с расстоянием Хэмминга между кодами не менее 2N+1. Таким образом, конструируя код, мы пытаемся обеспечить расстояние Хэмминга между возможными кодовыми последовательностями больше, чем оно может возникнуть из-за ошибок.

Широко распространены коды с одиночным битом четности. В этих кодах к каждым М бит добавляется 1 бит, значение которого определяется четностью (или нечетностью) суммы этих М бит. Так, например, для двухбитовых кодов 00, 01, 10, 11 кодами с контролем четности будут 000, 011, 101 и 110.
Если в процессе передачи один бит будет передан неверно, четность кода из М+1 бита изменится.

Предположим, что частота ошибок (BER) равна р=10-4. В этом случае вероятность передачи 8 бит с ошибкой составит 1-(1-p)8=7,9х10-4. Добавление бита четности позволяет детектировать любую ошибку в одном из переданных битах. Здесь вероятность ошибки в одном из 9 бит равна 9p(1-p)8. Вероятность же реализации необнаруженной ошибки составит 1-(1-p)9 – 9p(1-p)8 = 3,6x10-7. Таким образом, добавление бита четности уменьшает вероятность необнаруженной ошибки почти в 1000 раз. Использование одного бита четности типично для асинхронного метода передачи. В синхронных каналах чаще используется вычисление и передача битов четности как для строк, так и для столбцов передаваемого массива данных. Такая схема позволяет не только регистрировать но и исправлять ошибки в одном из битов переданного блока.

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

В Ethernet Вычисление crc производится аппаратно (см. также ethernet). На Рисунок 2.7.1. показан пример реализации аппаратного расчета CRC для образующего полинома B(x)= 1 + x2 + x3 +x5 + x7. В этой схеме входной код приходит слева.

Положение контактов (все контакты имеют размер мм)

Рисунок 4.6.4.2. Положение контактов (все контакты имеют размер 1,7х2,0 мм)

Всего на карте 8 контактов. На Рисунок 4.6.4.1 обязательные контакты представлены закрашенными прямоугольниками. Контакты C4 и С8 не используются и могут отсутствовать, контакт же С6 используется для программирования на фазе изготовления. Сопротивление для этого контакта по отношению к любым другим контактом должно превышать 10 Мом при напряжении 5 В.

Последовательность активации контактов ICC

Рисунок 4.6.4.3. Последовательность активации контактов ICC

Через некоторое время после подачи на ICC напряжения питания Vcc начинают поступать тактовые импульсы. В исходный момент времени (сразу после вставления карты уровень сигналов на шине I/O является низким (L). Далее уровень этой шины может быть неопределенным (обозначено на рисунке серым прямоугольником), но после прихода 200 тактов этот уровень становится высоким (H). При этом уровень на шине RST остается низким (L). Терминал IFD устанавливает свой драйвер I/O в режим приема не позднее поступления 200-го такта. После этого выполняется процедура сброса (Reset). ICC откликается на команду RESET асинхронно. Время, когда на ICC начинают поступать тактовые импульсы, называется T0. Терминал поддерживает в это время уровень шины RST в низком состоянии.

Примеры кодировки с использованием манчестерского кода

Рисунок 4.1.1.1.3 Примеры кодировки с использованием манчестерского кода

Ниже в таблице 4.1.1.1.1 приведены ограничения, налагаемые на сеть Ethernet в целом и на отдельные ее фрагменты.

Продвинутая схема системы склад-магазин

Рисунок 2.2. Продвинутая схема системы склад-магазин

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

В общем случае в электронной коммерции могут быть задействованы 5 субъектов – продавец, покупатель, банкир, агент доставки и агент обслуживания. Взаимодействие этих субъектов и документооборот между ними регламентируется протоколом IOTP.

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

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

<
/p> По специфике взаимодействия продавца и покупателя выделяются несколько областей бизнеса. К таким областям относятся взаимодействия клиент-клиент P2P (Person-to-Person), продавец-покупатель B2C (Business-to-Consumer) и бизнесмен-бизнесмен B2B (Business-to-Business). Деление это достаточно условно, один и тот же субъект в одних операциях выступает как покупатель в других как продавец.

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

Более перспективной представляется схема B2C>, именно к этому классу относятся практически все Интернет-магазины. В РФ пару лет назад возник бум создания таких структур. Даже ТВ было привлечено к рекламе некоторых из них. Пожалуй, это было несколько преждевременно. Сохранились лишь несколько книжных магазинов, торговля бытовой техникой, произведениями искусства, лекарствами и т.д.. Пытаются выжить некоторые Интернет-аукционы, которые по своей функции являются, чем-то средним между B2C и P2P. Следует обратить внимание, что почти все они не используют сетевых платежных систем. Во многих случаях отсутствие коммерческого успеха связано с тем, что такие магазины не дают сверхприбылей, но требуют получения лицензий и других начальных инвестиций. Сюда относится и отсутствие достаточного платежеспособного спроса у той части населения, которая знакома с технологиями Интернет и имеет к нему доступ, неразвитая кредитная и банковская системы.

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

Как уже отмечалось выше, торговля сопряжена не только с оплатой товара и его получением, но с немалым объемом документов (заказы, счета, чеки, накладные, расписки, платежные поручения и т.д.). В настоящее время специально для торговли через Интернет разработан открытый протокол торговли через Интернет IOTP (Internet Open Trading Protocol).

Простейшая схема системы склад-магазин

Рисунок 2.1. Простейшая схема системы склад-магазин

Расположение контактов на лицевой стороне карты

Рисунок 4.6.4.1. Расположение контактов на лицевой стороне карты

Схема динамической аутентификации данных

Рисунок 4.6.4.12. Схема динамической аутентификации данных

ICC, которая поддерживает аутентификацию динамических данных, должна содержать следующие информационные элементы.

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

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

Остаток общедоступного ключа эмитента.

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

Остаток общедоступного ключа ICC.

Показатель общедоступного ключа ICC.

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

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

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

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

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

Процедура цифровой подписи использует данные, представленные в таблицах 4.6.4.23 и 4.6.4.24. Модуль общедоступного ключа сертификационного центра содержит NCC байт, где NCC ? 248. Показатель общедоступного ключа сертификационного центра равен 2, 3 или 216+1. Модуль общедоступного ключа эмитента содержит NЭ байт, где NЭ < 248 и NЭ < NCC. Если NЭ > (NCC - 36), модуль общедоступного ключа эмитента делится на две части, одна состоит из NCC – 36 старших байт модуля (левые цифры), а вторая часть содержит остальные NЭ

- (NCC - 36) младших байт модуля (остаток общедоступного ключа эмитента). Показатель общедоступного ключа эмитента равен 2, 3 или 216+1.

Модуль общедоступного ключа ICC содержит NIC байт, где NIC ? 128 и NIC < NЭ. Если NIC > (NЭ - 42), модуль общедоступного ключа ICC делится на две части, одна – состоит из NЭ – 42 старших байт модуля (левые цифры общедоступного ключа ICC) и остальных NIC – (NЭ – 42) младших байт модуля (остаток общедоступного ключа ICC). Показатель общедоступного ключа ICC равен 2, 3 или 216+1.

Для осуществления аутентификации динамических данных терминал сначала извлекает и аутентифицирует общедоступный ключ ICC (аутентификация общедоступного ключа ICC). Вся информация, необходимая для аутентификации общедоступного ключа ICC представлена в таблице 4.6.4.25 и хранится в памяти ICC. За исключением RID, который может быть получен из AID, эта информация извлекается с помощью команды READ RECORD. Если что-то из этой информации отсутствует, аутентификация терпит неудачу.

Схема интерфейса на уровне mau

Рисунок 4.1.1.1.7. Схема интерфейса на уровне mau

Схема signal quality регистрирует коллизии и другие искажения сигнала и выдает в этом случае флаг SQE (signal quality error). sqe представляет собой сигнал CS0, посылаемый от MAU к DTE (точнее PMA к PLS, см. Рисунок 4.1.1.1.2). Сигнал SQE посылается mau также в случае завершения процесса передачи (output_idle). Узел isolate служит для блокировки передачи данных в сетевую среду, при этом DTE передает mau сигнал CS0. Суммарная емкостная нагрузка, вносимая mau, не должна превышать 4 пф. Входное сопротивление должно быть более 100 ком, а ток утечки должен лежать в пределах +2 мкА –25мкА. Выходной драйвер mau при передаче выдает в кабель –90 ±4мa (эквивалентно –2,05В на нагрузке 25 Ом). Предельное ослабление сигнала на длине 500 м не должно превышать 8,5 дБ (на частоте 10МГц).

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

Помимо столкновений в сети может быть зарегистрировано появление ложной несущей (FCE – false carrier event) – битовая последовательность не имеет байта SFD, соответствующего конкретному типу физической среды. Появление ложной несущей обычно связано с состоянием кабеля или шумами. Если фиксируется появление двух ложных несущих подряд, повторитель должен отключить порт (перевести в состояние link unstable) и послать сигнал jam во все остальные порты. Сигнал jam должен продолжаться до конца потока данных, вызвавшего появление ложной несущей. Если канал восстановлен, повторитель переводит порт в нормальное состояние. Отключение порта возможно также при возникновении множественных коллизий (ECE – excessive collision error) – более 60 коллизий подряд. После блокировки порта он будет восстановлен, если в течении 500 тактов коллизии не обнаружены или при повторном включении повторителя. Если рассмотреть зависимость пропускной способности сети L от ее суммарной загрузки Lin, мы для Ethernet получим кривую, показанную на Рисунок 4.1.1.1.8.

Схема -мегагерцного оптоволоконного Ethernet

Рисунок 4.1.1.1.9. Схема 10-мегагерцного оптоволоконного Ethernet.

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

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

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

Исторически первой появилась схема подключения к толстому 50-омному коаксиальному кабелю (сегмент 1 на Рисунок 4.1.1.1.6; Z=50 ±2 Ом) через трансивер и многожильный кабель типа AUI (attachment unit interface, максимальная длина 50 м). Трансивер подключается к кабелю методом “наколки”, то есть во внешней оплетке и изоляции сверлится с помощью специального инструмента отверстие и через него осуществляется контакт трансивера с центральной жилой кабеля и экраном. Кабель по возможности не должен содержать сросток, в противном случае его предельная длина должна быть сокращена. Кабельный сегмент должен быть согласован с обоих сторон с помощью терминаторов (50 Ом ±1%). Позднее стала популярной схема соединений через тонкий коаксиальный кабель и t-образные коаксиальные разъемы (волновое сопротивление 50 Ом). В настоящее время наибольшее применение находит схема со специальными многовходовыми повторителями-концентраторами (Hub) и подключением оконечного оборудования через скрученные пары. Для подключения используется 8-контактный разъем RJ-45 (см. приложение 10.17 Разводка разъемов). Этому способствует удешевление категорированных скрученных пар, соответствующих повторителей, а также большая надежность и лучшая ремонтоспособность таких сетей. Следует иметь в виду, что предельные длины для коаксиальных кабелей, приведенные в таблице 4.1.1.1.1 относятся к зарубежным типам, в частности в случае тонкого кабеля - это rg-58. Отечественные разновидности кабеля, например РК-50-2-11, допускают (при максимальной загрузке) длины примерно в 1,3-1,5 раз меньше. Это связано с меньшим сечением центральной жилы и большей вариацией волнового сопротивления. Если же число ЭВМ подключенных к кабельному сегменту много меньше предельного, допускается использование и запредельных длин кабельных сегментов, но это не рекомендуется. Пропускная способность сети с методом доступа csma/cd снижается по мере роста загрузки из-за увеличения вероятности столкновений. По этой причине даже использование 100-мегагерцного ethernet не может гарантировать большей пропускной способности (по сравнению с обычным, см. Рисунок 4.1.1.1.8) при условии высоких загрузок и, как следствие, высоких вероятностей столкновений. ethernet-интерфейс перед началом передачи контролирует состояние кабельного сегмента (наличие несущей), выжидает некоторое время, если сегмент занят, после чего производит попытку передачи с контролем возможности столкновения.

Если в поле адресата содержатся все единицы, адрес считается широковещательным, то есть обращенным ко всем рабочим станциям локальной сети. Пакет ethernet может нести от 46 до 1500 байт данных. Схема интерфейса на уровне mau в упрощенном виде имеет вид, показанный на Рисунок 4.1.1.1.7.

Схема взаимодействия субуровней (CSMA/CD)

Рисунок 4.1.1.1.2. Схема взаимодействия субуровней 802.3 (CSMA/CD)

Манчестерский код объединяет в бит-сигнале данные и синхронизацию. Каждый бит-символ делится на две части, причем вторая часть всегда является инверсной по отношению первой. В первой половине кодируемый сигнал представлен в логически дополнительном виде, а во второй – в обычном. Таким образом, сигнал логического 0 – CD0 характеризуется в первой половине уровнем HI, а во второй LO. Соответственно сигнал CD1 характеризуется в первой половине бит-символа уровнем LO, а во второй – HI. Примеры форм сигналов при манчестерском кодировании представлены на Рисунок 4.1.1.1.3.

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

Рисунок 4.1.1.1.11. Схема защиты для случая использования экранированных скрученных пар

Смарт-карты EMV

4.6.4 Смарт-карты EMV

Спецификация карты ICC (Integrated Circuit Card)

В основу данной спецификации легли разработки компаний Europay, MasterCard и Visa (EMV) в марте, 1998 года. Следует принимать во внимание, что данная технология будет использоваться не только для финансовых операций. Планируется ее применения для проездных билетов и контроля доступа к ЭВМ. В перспективе можно предположить, что эта техника будет использоваться для идентификации личности, например, вместо паспорта.

IEC 512-2:1979	Спецификации для электромеханических компонентов оборудования - Часть 2: Тесты сопротивления контактов, тесты проверки изоляции и перегрузок
FIPS Pub 180-1:1995	Стандарт на безопасные хэши. Спецификация терминала платежных систем для карт с интегральными схемами
ISO 639:1988	Коды названий языков
ISO 3166:1997	Коды названий стран
ISO 4217:1995	Коды валют и фондов
ISO/IEC 7811-1:1995	Идентификационные карты – Метод записи - Часть 1: Тиснение
ISO/IEC 7811-3:1995	Идентификационные карты – Метод записи - Часть 3: Положение вытисненных символов на картах ID-1
ISO/IEC 7813:1995	Идентификационные карты – Карты для финансовых операций
ISO/IEC DIS 7816-1:1998	Идентификационные карты – Карты с интегральными схемами, имеющими внешние контакты.
Часть 1:	Физические характеристики ISO/IEC DIS 7816-2:1998
Часть 2:	Размеры и положение контактов
ISO/IEC 7816-3:1989	Часть 3:	Электрические сигналы и протоколы передачи
ISO/IEC 7816-3:1992	Часть 3:	Протокол типа T=1, асинхронный полудуплексный протокол блочной передачи
ISO/IEC 7816-3:1994	Часть 3:	Выбор типа протокола
ISO/IEC 7816-4:1995	Часть 4:	Команды обмена
ISO/IEC 7816-5:1994	Часть 5:	Процедура для выработки прикладных идентификаторов
ISO/IEC 7816-6:1996	Часть 6:	Информационные элементы
ISO 8731-1:1987	Часть 1:	Алгоритмы аутентификации сообщений (DEA)
ISO 8372:1987	Обработка информации. Режимы работы для 64-битовых блочных алгоритмов шифрования/дешифрования
ISO/IEC 8825:1990	Информационная технология. Соединение открытых систем. Спецификация базовых правил кодирования для синтаксической нотации ASN.1
ISO 8583:1987	Сообщения банковских карт – Спецификации сообщений – Содержимое финансовых транзакций
ISO 8583:1993	Сообщения транзакций банковских карт – Спецификации сообщений
ISO 8859:1987	Обработка сообщений – 8-битовые графические символьные наборы
ISO/IEC 9796-2: 1997	Информационная технология – Методы безопасности – Схема восстановления сообщений с цифровой подписью. Часть 2: Механизм использования хэш-функций
ISO/IEC 9797:1994	Информационная технология - Методы безопасности – Механизм информационной целостности, использующий функцию криптографической проверки на базе алгоритма блочного шифра
ISO/IEC 10116: 1997	Информационная технология – режимы работы алгоритмов n-битовых блочных шифров
ISO/IEC 10118-3: 1998	Информационная технология - Методы безопасности – хэш-функции

Структура блока

Рисунок 4.6.4.9. Структура блока

Кодирование PCB зависит от его типа, оно представлено в таблицах 4.6.4.13-15.

Структура командного APDU

Рисунок 4.6.4.8. Структура командного APDU.

Все поля заголовка имеют по одному байту. Поле данных содержит Lc байт.

Lc	Число байт в поле данные (0 или 1 байт)
Le	Максимальное число байт в поле данных отклика (0 или 1 байт)

Если параметры Р1 и Р2 не используются, коды полей должны равняться 00.

Формат отклика APDU аналогичен показанному на 4.6.4.8.

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

Кодировка команд для полей CLA и INS представлена в таблице 4.6.4.11.

Если передача не осуществляется, состояние

Таблица 4.6.4.2

	Минимум	Максимум
VIH	0,7xVcc	Vcc
VIL	0	0,8 В
tR и tF	-	1,0 мксек

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

перечислены требования на параметры

Таблица 4.6.4.3

	Условия	Минимум	Максимум
VOH	-20мкА<IOH<0, Vcc= min	0,7xVcc	Vcc
VOL	0< IOL < 1мА, Vcc = min	0	0,4 В
tR и tF	C IN(терминала) =30пФ макс	-	1,0 мксек

В таблице 4.6.4. 4 перечислены требования на параметры тактовых импульсов. ICC может работать корректно при скважности тактовых импульсов в диапазоне (44-56)% и значении тактовой частоты от 1 до 5 МГц.

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

Таблица 4.6.4.4

	Минимум	Максимум
VIH	Vcc-0,7В	Vcc
VIL	0	0,5 В
tR и tF	-	9% тактового периода

В таблице 5 представлены характеристики сигнала сброса (RST).

Таблица

Таблица 4.6.4.1.

Контакт	Назначение	Контакт	Назначение
С1	VCC – напряжение питания	С5	GND - земля
С2	RST - сброс	С6	Не используется
С3	CLK – тактовые импульсы	С7	Вход/Выход (I/O)

VCC - напряжение питания 5 ± 0,5В при токе 50 мА при любых частотах работы микросхемы.
В таблице 4.6.4.2 представлены параметры входных информационных сигналов
VIH- Высокий уровень входного сигнала

VIL- Низкий уровень входного сигнала

VOH- Высокий уровень выходного сигнала

VOL- Низкий уровень выходного сигнала

tR- Время нарастания сигнала

tF- Время спада сигнала

ICC выдерживает уровни сигнала на

Таблица 4.6.4.5

	Минимум	Максимум
VIH	Vcc-0,7В	Vcc
VIL	0	0,6 В
tR и tF	-	1,0 мксек

ICC выдерживает уровни сигнала на шине RST от –0,3В до Vcc+0,3В. ICC откликается на сигнал сброса асинхронно. Микросхема может также противостоять импульсам тока через цепь питания до 100 мА длительностью 400 нсек и с интегральным зарядом 40 нАсек.
Любая транзакция для карты начинается с ее вставления в интерфейсное устройство IFD (Interface Device) и активации контактов карты. Далее следует сброс микросхемы ICC в исходное состояние и установление связи между ICC и IFD. Только после этого начинает реализовываться конкретная транзакция. Любая транзакция завершается дезактивацией контактов и удалением ICC из интерфейсного устройства.
После вставления карты в IFD терминал проверяет, что все сигнальные контакты находятся в состоянии L (низкий логический уровень - VOL). IFD контролирует корректность положения ICC с точностью ±0,5мм. Если карта позиционирована правильно, производится активация контактов в соответствии с порядком, представленном на Рисунок 4.6.4.3.

TC3 передают информацию, которая используется

Таблица 4.6.4.8

	b8	b7	b6	b5	b4	b3	b2	b1
Только Т=0	0	1	1	0	X	X	X	X
Только Т=1	1	1	1	0	X	X	X	X

Символы интерфейса TA1- TC3 передают информацию, которая используется при обмене между терминалом и ICC. Они определяют значения параметров F, D, I, P и N, а также IFSC, BWI (Block Waiting time Integer) и CWI (Character Waiting time Integer). Информация, содержащаяся в TA1, TB1, TC1, TA2 и TB2 будут применяться для всех последующих обменов вне зависимости от используемого протокола.
TA1 служит для передачи значений FI и DI, где FI используется для задания значения F (параметр, определяющий тактовую частоту). DI служит для задания значения D, используемого для настройки частоты следования бит. По умолчанию FI=1 и DI=1, что означает F=372, а D=1.
Если ТА1 присутствует в ATR (b5 в T0 равен 1) и TA2 прислан с b5=0, то терминал воспринимает ATR, если TA1=11, и немедленно реализует указанные F и D.

ТВ1 несет в себе значения PI1 и II, где PI1 специфицировано в битах b1-b5 и используется для программирования значения напряжения P, необходимого ICC. PI0=0 означает, что VPP не подключено к ICC. II специфицируется в битах b6 и b7 и служит для определения максимального тока, потребляемого ICC. Этот параметр не используется, если PI1 = 0.

TC1 несет в себе величину N, которая используется для задания дополнительной выдержки (guardtime) между символами. Это время будет добавлено к минимальной выдержке. N может принимать значения 0-255 t.

TD1 указывает, должны ли быть переданы еще интерфейсные байты, и содержит информацию о типе протокола. Старший полубайт используется для индикации наличия символов TA2 – TD2. Биты b5-b8 принимают значение логической единицы, если указанные выше символы присутствуют. Младший полубайт указывает протокол, который будет использован для последующих обменов.
ATR не содержит TD1, если используется только Т=0. Для T=1 TD1=81 указывает на наличие TD2.
Наличие или отсутствие TA2 говорит о работе ICC в специфическом или согласованном режиме, соответственно.

Базовый отклик ATR не содержит

Базовый отклик ATR не содержит ТА2.

ТВ2 передает PI2, который используется для определения величины программируемого напряжения Р, необходимого ICC. Если этот символ присутствует, значение, указанное в PI1 (ТВ1), заменяется на новое. По умолчанию ТВ2 отсутствует.

ТС2 специфичен для протокола типа Т=0 и несет в себе значение WI (Waiting time Integer), которое используется для определения максимального интервала между началом передачи любого символа, посланного ICC, и началом предыдущего символа, поступившего от ICC или терминала. Время выдержки вычисляется по формуле 960xDxWI. По умолчанию ТС2 отсутствует, а WI=10. Терминал воспринимает ATR, содержащий ТС2=0А. Он отвергает ATR, несущий в себе ТС2=00 или ТС2>0А.

TD2 указывает, будут ли еще переданы какие-либо интерфейсные байты, а также определяет тип протокола, используемого далее. Старший полубайт используется для указания наличия символов ТА3 – TD3. Биты b5-b8 устанавливаются в единичное состояние при наличии ТА3 – TD3. Младший полубайт указывает тип протокола, применяемый в последующих обменах. При Т=1 он равняется 1. По умолчанию при Т=0 ATR не содержит TD2, в противном случае ATR содержит TD2=31 (T=1).

ТА3 несет в себе информацию о размере поля данных для ICC (IFSI) и специфицирует длину информационного поля INF блоков, которые могут быть получены картой. Этот символ характеризует длину IFSC в байтах и может содержать коды в интервале 0х01-0хFE. Значения 0х00 и 0хFF зарезервированы на будущее. По умолчанию ATR содержит ТА3 со значение в диапазоне 0х10-0хFE, если Т=1, IFSC лежит в интервале 16-254 байта. Если ТА3 содержит недопустимый код, ATR терминалом отвергается.

ТВ3 характеризует значения CWI и BWI, используемые для вычисления CWT и BWT, соответственно. ТВ3 имеет две части. Младший полубайт (b1-b4) используется для определения значения CWI, а старший полубайт (b5-b8) – BWI. По умолчанию ATR несет в себе ТВ3, при этом младший полубайт содержит код 0-5, а старший – 0-4, если Т=1, указывая, что CWI=0-5, а BWI=0-4.Формат ТВ3 показан в таблице 4.6.4.9.

Терминал отвергает ATR, не содержащий

Таблица 4.6.4.9

	b8	b7	b6	b5	b4	b3	b2	b1
Только Т=1	0	X	X	X	0	Y	Y	Y

XXX лежит в интервале 000-100, а YYY – 000-101
Терминал отвергает ATR, не содержащий ТВ3 или указывающий на значения BWI больше 4 и/или CWI больше 5, или 2CWI<(N+1).

TC3 индицирует тип блока кода детектирования ошибки. Тип кода определяется битом b1 (b2-b8 – не используются). По умолчанию ATR не содержит ТС3. Терминал воспринимает ATR с ТС3=00, и отбрасывает любые-другие ATR, содержащие другие значения ТС3.

ТСК (контрольный символ) имеет значение, которое позволяет проверить целостность данных, пересылаемых в ATR. Значение TCK таково, что исключающее ИЛИ всех байтов от Т0 до ТСК включительно должно давать код 0. По умолчанию ATR не содержит ТСК, если используется только Т=0, во всех других случаях ТСК должен присутствовать. Терминал воспринимает ATR ICC без TCK, если только Т=0. Во всех остальных случаях терминал отвергнет ATR без, или с некорректным ТСК. Если ТСК некорректно, терминал инициирует последовательность дезактивации не позднее 480 t после начала ТСК.
Если терминал отверг холодный АТR, он не отвергает карту немедленно, а инициирует “теплый” сброс в пределах 4800t. Если терминал отверг теплый ATR, он в пределах 4800 t запускает процедуру дезактивации.
Если во время отклика на холодный или теплый сброс интервал между двумя последовательными символами превысит 9600t, терминал прерывает сессию путем инициализации дезактивации спустя 14400t после стартового бита последнего полученного символа.
Если отклик на холодный или теплый сброс не завершился в пределах 19200t , терминал спустя 24000t (от начала TS) запускает процедуру дезактивации карты.
Если терминал обнаруживает ошибку по четности при передаче символа ATR, он прерывает сессию карты и спустя 4800t инициирует процедуру дезактивации.

А Сводные данные по командам/откликам

Таблица 4.6.4.12А. Сводные данные по командам/откликам

Команда	CLA	INS	P1	P2	Lc	Данные	Le
APPLICATION BLOCK	8C/84	1E	00	00	Число байт данных	Код аутенти-фикации сообщения (MAC)	-
APPLICATION UNBLOCK	8C/84	18	00	00	Число байт данных	Компонент MAC	-
CARD BLOCK	8C/84	16	00	00	Число байт данных	Компонент MAC	-
EXTERNAL AUTHENTICATE	00	82	00	00	8-16	Issue Authentication Data	-
GENERATE APPLICATION CRYPTOGRAM	80	AE	Парам. ссылки	00	Перемен.	Данные транзакции	00
GET DATA	80	CA	9F36 9F13 9F17	9F36 9F13 9F17	-	-	00
GET PROCESSING OPTIONS	80	A8	00	00	Перемен.	Processing Option Data Object List (PDOL)	00
INTERNAL AUTHENTICATE	00	88	00	00	Длина аутент. данных	Аутентиф. данные	00
PIN CHANGE/UNBLOCK	8C/84	24	00	00, 01 или 02	Число байт данных	PIN данные	-
READ RECORD	00	B2	Номер записи	Парам. ссылки	-	-	00
SELECT	00	A4	Парам. ссылки	Опции выбора	05-10	Имя файла	00
VERIFY	00	20	00	Квали-фикатор	Перемен	PIN данные транзакции	-
GET CHALLENGE	00	84	00	00	-	-	00

Блочный протокол Т=1 предполагает передачу блоков данных между TAL (Terminal Application Layer) и ICC. Эти блоки несут в себе команды, R-APDU (Response Application Protocol Data Unit) и управляющую информацию. Структура блока показана на рисунке 4.6.4.10. Поля заголовка и эпилога (хвостовика) являются обязательными. Биты b1-b3 NAD указывают на адрес отправителя (SAD), а b5-b7 – адрес получателя (DAD). В настоящее время адресация узлов не поддерживается и по этой причине в поле NAD следует записывать код 00. Биты b4 и b8 равны нулю. Код PCB определяет тип блока. Существует три типа блоков: информационные (I-блок), готовности приема (R-блок, подтверждение) и управляющие (S-блок).

Заголовок (Prologue)			Данные	Эпилог
Адрес узла (NAD)	Управляющий протокольный байт (PCB)	Длина (LEN)	APDU или управляющая информация (INF)	EDC (код детектирования ошибки)
1 байт	1 байт	1 байт	0-254 байта	1 байт

Указывает на прямую или инверсную

Таблица 4.6.4.6. Базовый ATR для T=0

Символ	Значение	Примечания
TS	3B или 3F	Указывает на прямую или инверсную схему передачи бит
T0	6x	Присутствуют TB1 и TC1; х обозначает число исторических байтов
TB1	00	VPP не требуется
TC1	00 - FF	Указывает на необходимость дополнительного времени выдержки. FF имеет специальное назначение.

Если поддерживается только протокол типа T=1 (блочный асинхронный транспортный протокол), то используемые символы отклика ATR содержатся в таблице 4.6.4.7. Следует иметь в виду, что ICC может поддерживать более одного транспортного протокола.

Указывает на прямую или инверсную

Таблица 4.6.4.7. Базовый ATR для T=1

Символ	Значение	Примечания
TS	3B или 3F	Указывает на прямую или инверсную схему
T0	Ex	Присутствуют TB1 – TD1; х обозначает число исторических байтов
TB1	00	VPP не требуется
TC1	00 – FF	Указывает на необходимость дополнительного времени выдержки. FF имеет специальное назначение.
TD1	81	TA2 – TC2 отсутствуют; TD2 присутствует; должен работать протокол T=1
TD2	31	TA3 и TB2 присутствуют; TC3 и TD3 отсутствуют; должен работать протокол T=1
TA3	10 – FE	Возвращает IFSI, что указывает на начальное значение размера информационного поля для ICC и IFSC равное 16-254 байтам
TB3	Старший полубайт =0-4 Младший полубайт =0-5	BWI = 0-4 CWI = 0-5
TCK		Контрольный символ

Интерфейсы могут поддерживать отклики, не описанные в данной спецификации. Максимальное число символов в отклике, включая TS, не должно превышать 32.

TS служит для синхронизации терминала и для определения логической схемы интерпретации последующих символов. Инверсная логическая схема предполагает, что логической единице на шине I/O соответствует уровень L, а старший бит данных передается первым. Прямая схема предполагает, что логической единице на шине I/O соответствует уровень H, а первым передается младший бит. Первые четыре бита LHHL используются для синхронизации.

ICC может прислать ATR, содержащий TS, который имеет одно из следующих значений:

(H)LHHLLLLLLH – инверсная схема, значение 3F.

(H)LHHLHHHLLH – прямая схема, значение 3B

Последний бит этих кодов Н является битом четности (смотри Рисунок 4.6.4.7).



T0 – символ формата. Старший полубайт (b5-b8) используется для определения того, присутствуют ли последующие символы TA1-TD1. Если биты b5-b8 установлены в состояние логической единицы, TA1-TD1 присутствуют. Младший полубайт (b1-b4) содержит число опционных исторических байтов (0-15). Смотри таблицу 4.6.4.8.

Данные общедоступного ключа ICC, которые должны быть подписаны эмитентом карты

Таблица 4.6.4.24. Данные общедоступного ключа ICC, которые должны быть подписаны эмитентом карты

Имя поля	Длина (байт)	Описание
Формат сертификата	1	Шестнадцатеричное число 0х04
PAN (Primary Application Number) приложения	10	PAN дополненный справа кодами 0хF
Дата истечения времени действия сертификата	2	Дата ММГГ, после которой сертификат становится недействительным
Серийный номер сертификата	3	Двоичное число, уникальное для данного сертификата, присваиваемое эмитентом
Индикатор хэш-алгоритма	1	Индицирует алгоритм, используемый для вычисления результирующего хэша цифровой подписи
Индикатор алгоритма общедоступного ключа ICC	1	Индицирует алгоритм вычисления цифровой подписи, который должен использоваться совместно с общедоступным ключом ICC
Длина общедоступного ключа ICC	1	Идентифицирует длину модуля общедоступного ключа ICC в байтах
Длина показателя общедоступного ключа ICC	1	Идентифицирует длину показателя общедоступного ключа ICC в байтах
Общедоступный ключ ICC или левые цифры этого ключа	NЭ - 42	Если NIC ? NЭ – 42, это поле состоит из полного общедоступного ключа ICC дополненного справа NЭ – 42 - NIC байт с кодом 0хBB. Если NIC > NЭ – 42, это поле состоит из NЭ – 42 старших байтов общедоступного ключа ICC
Остаток общедоступного ключа ICC	0 или NIC - NЭ + 42	Это поле присутствует, только если NIC > NЭ – 42 и состоит из NЭ - NCС + 42 младших байт общедоступного ключа ICC
Показатель общедоступного ключа ICC	1 или 3	Показатель общедоступного ключа ICC равен 2, 3 или 216+1
Данные, подлежащие аутентификации	Переменная	Статические данные, подлежащие аутентификации согласно спецификации ICC для платежных систем

Данные общедоступного ключа эмитента, которые должны быть подписаны сертификационным центром

Таблица 4.6.4.23. Данные общедоступного ключа эмитента, которые должны быть подписаны сертификационным центром.

Имя поля	Длина (байт)	Описание
Формат сертификата	1	Шестнадцатеричное число 0х02
Идентификационный номер эмитента	4	Левые 3-8 цифр от PAN (дополняемые справа кодами 0хF)
Дата истечения времени действия сертификата	2	Дата ММГГ, после которой сертификат становится недействительным
Серийный номер сертификата	3	Двоичное число, уникальное для данного сертификата, присваиваемое центром сертификации
Индикатор хэш-алгоритма	1	Индицирует алгоритм, используемый для вычисления результирующего хэша цифровой подписи
Индикатор алгоритма общедоступного ключа эмитента	1	Индицирует алгоритм вычисления цифровой подписи, который должен использоваться совместно с общедоступным ключом эмитента
Длина общедоступного ключа эмитента	1	Идентифицирует длину модуля общедоступного ключа эмитента в байтах
Длина показателя общедоступного ключа эмитента	1	Идентифицирует длину показателя общедоступного ключа эмитента в байтах
Общедоступный ключ эмитента или левые цифры этого ключа	NCC - 36	Если NЭ ? NCC – 36, это поле состоит из полного общедоступного ключа эмитента дополненного справа NCC –36 - NЭ байт с кодом 0хBB. Если NЭ > NCC – 36, это поле состоит из NCC – 36 старших байтов общедоступного ключа эмитента
Остаток общедоступного ключа эмитента	0 или NЭ -NCC + 36	Это поле присутствует только если NЭ > NCC – 36 и состоит из NЭ - NCC + 36 младших байт общедоступного ключа эмитента
Показатель общедоступного ключа эмитента	1 или 3	Показатель общедоступного ключа эмитента равен 2, 3 или 216+1

Данные, сопряженные с

Таблица 4.6.4.18. Данные, сопряженные с общедоступным ключом эмитента, которые должны быть подписаны центром сертификации.

Имя поля	Длина (байт)	Описание
Формат сертификата	1	Шестнадцатеричное число 0х02
Идентификационный номер эмитента	4	Левые 3-8 цифр номера первичного счета PAN (Primary Account Number)
Дата истечения действительности сертификата	2	MMГГ, после которых данный сертификат не действителен
Серийный номер сертификата	3	Двоичное число уникальное для сертификата сертификационного центра
Индикатор хэш-алгоритма	1	Идентифицирует хэш-алгоритм, используемый для получения электронной подписи
Индикатор алгоритма общедоступного ключа эмитента	1	Идентифицирует алгоритм цифровой подписи, используемый с общедоступным ключом эмитента
Длина общедоступного ключа эмитента	1	Идентифицирует длину модуля общедоступного ключа эмитента в байтах
Длина показателя общедоступного ключа эмитента	1	Идентифицирует длину показателя общедоступного ключа эмитента в байтах
Общедоступный ключ эмитента или левые цифры этого ключа	NCC - 36	Если NЭ ? NCC –36, это поле состоит из общедоступного ключа эмитента дополненного справа NCC – 36 - NЭ байтами, равными BB. Если NЭ > NCC –36, это поле состоит из NCC – 36 старших байт общедоступного ключа эмитента
Остаток общедоступного ключа эмитента	0 или NЭ - NCC + 36	Это поле присутствует, только если NЭ > NCC –36, оно состоит из NЭ - NCC + 36 младших байт общедоступного ключа эмитента
Показатель общедоступного ключа эмитента	1 или 3	Показатель общедоступного ключа эмитента, равный 2, 3 или 216+1.

Динамические данные приложения, которые должны быть подписаны

Таблица 4.6.4.28. Динамические данные приложения, которые должны быть подписаны

Имя поля	Длина (байт)	Описание
Формат подписанных данных	1	Шестнадцатеричное число 0х05
Индикатор хэш-алгоритма	1	Индицируется алгоритм хэширования, используемый для получения результата
Длина динамических данных ICC	1	Идентифицирует длину LDD динамических данных ICC в байтах
Динамические данные ICC	LDD	Динамические данные, сформированные и/или записанные в ICC
Символы заполнителя	NIC - LDD - 25	(NIC - LDD – 25) байтов заполнителя, содержащего коды 0хBB
Динамические данные терминала	Переменная	Объединение информационных элементов, специфицированных DDOL

Длина динамических данных ICC LDD удовлетворяет условию 0 ? LDD ? NIC – 25. 3-9 самых левых байтов динамических данных ICC включают в себя 1 байт длины динамического числа ICC, за которым следует 2-8 байт значения этого числа (тэг 9F4C, 2-8 двоичных байтов). Динамическое число ICC формируется ICC.

Кроме данных, перечисленных в таблице 4.6.4.28, для аутентификации динамических данных необходимы информационные объекты:

Подписанные динамические данные приложения (NIC байтов; тэг 9F4B) и DDOL (тэг 9F49).

Если подписанные динамические данные приложения имеют длину отличную от длины модуля общедоступного ключа ICC, аутентификация не проходит.

Чтобы получить восстановленные данные, описанные в таблице 4.6.4.29 для подписанных динамических данных приложения используется общедоступный ключ ICC. Если хвостовик восстановленных данных не равен 0хBC, аутентификация не проходит.

Формат данных, полученных из подписанных динамических данных приложения

Таблица 4.6.4.29. Формат данных, полученных из подписанных динамических данных приложения

Имя поля	Длина (байт)	Описание
Заголовок восстановленных данных	1	Шестнадцатеричное число 0х6А
Формат подписанных данных	1	Шестнадцатеричное число 0х05
Индикатор алгоритма хэширования	1	Индицируется алгоритм хэширования, используемый для получения результата при вычислении цифровой подписи
Длина динамических данных ICC	1	Идентифицирует длину динамических данных ICC в байтах
Динамические данные ICC	LDD	Динамические данные, сформированные и/или записанные в ICC
Символы заполнителя	NIC - LDD - 25	(NIC - LDD – 25) байтов заполнителя, содержащего коды 0хBB
Результат хэширования	20	Хэш динамических данных приложения и сопряженной информации
Хвостовик восстановленных данных	1	Шестнадцатеричное число 0хВС

Далее проверяется заголовок восстановленных данных, если его код не равен 0х6А, аутентификация не проходит. Проверяется код формата подписанных данных и, если он не равен 0х05, аутентификация не проходит.

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

Формат элемента каталога ADF

Таблица 4.6.4.17. Формат элемента каталога ADF

Метка (Tag)	Длина	Значение
0х4F	5-16	Имя ADF (AID)
0х50	1-16	Метка приложения
0х9F12	1-16	Предпочитаемое имя приложения
0х87	1	Индикатор приоритетности приложения
0х73	переменная	Шаблон каталога

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

4.6.4.3. Соображения безопасности

Статическая аутентификация данных

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

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

Формат элемента каталога DDF

Таблица 4.6.4.16. Формат элемента каталога DDF

Метка (Tag)	Длина	Значение
9D	5-16	Имя DDF
73	переменная	Шаблон каталога

Формат восстановленных данных из подписанных статических прикладных данных

Таблица 4.6.4.22. Формат восстановленных данных из подписанных статических прикладных данных.

Имя поля	Длина (байт)	Описание
Заголовок восстановленных данных	1	Шестнадцатеричное число 0х6А
Формат подписанных данных	1	Шестнадцатеричное число 0х03
Индикатор хэш-алгоритма	1	Идентифицирует алгоритм хэширования, используемый для вычисления поля результат хэширования для цифровой подписи
Код данных аутентификации	2	Код, присвоенный эмитентом
Код заполнителя	NЭ - 26	Код байтов заполнителя, равный 0хBB
Результат хэширования	20	Хэш статических прикладных данных, которые должны быть аутентифицированы
Хвостовик восстановленных данных	1	Шестнадцатеричное число 0хВС

Проверяется заголовок восстановленных данных и, если он не равен 0х6A, аутентификация не проходит.

Проверяется формат подписанных данных и, если его код не равен 0х03, аутентификация не проходит.

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

Таблица 4.6.4.26. Формат восстановленных данных из сертификата общедоступного ключа эмитента.

Имя поля	Длина (байт)	Описание
Заголовок восстановленных данных	1	Шестнадцатеричное число 0х6А
Формат сертификата	1	Шестнадцатеричное число 0х02
Идентификационное число эмитента	4	Левые 3-8 цифр из PAN, дополненные справа кодами 0хF
Дата истечения времени действия сертификата	2	Дата ММГГ, после которой сертификат становится недействительным
Серийный номер сертификата	3	Двоичное число, уникальное для данного сертификата, присваиваемое центром сертификации
Индикатор хэш-алгоритма	1	Индицирует алгоритм, используемый для вычисления результирующего хэша цифровой подписи
Индикатор алгоритма общедоступного ключа эмитента	1	Индицирует алгоритм вычисления цифровой подписи, который должен использоваться совместно с общедоступным ключом эмитента
Длина общедоступного ключа эмитента	1	Идентифицирует длину модуля общедоступного ключа эмитента в байтах
Длина показателя общедоступного ключа эмитента	1	Идентифицирует длину показателя общедоступного ключа эмитента в байтах
Общедоступный ключ эмитента или левые цифры этого ключа	NCC - 36	Если NЭ ? NСС – 36, это поле состоит из полного общедоступного ключа эмитента, дополненного справа NСС – 36 - NЭ байтами с кодом 0хBB. Если NЭ > NСС – 36, это поле состоит из NСС – 36 старших байтов общедоступного ключа эмитента
Результат хэширования	20	Хэш общедоступного ключа эмитента и сопряженных данных
Хвостовик восстановленных данных	1	Шестнадцатеричное число 0хВС

Проверяется то, что идентификационный номер эмитента соответствуют 3-8 цифрам PAN. Если соответствия нет, аутентификация отвергается.

Проверяется срок действия сертификата и, если он истек, аутентификация отвергается.

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

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

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

Для того чтобы получить данные, специфицированные в таблице 4.6.4.27, используется сертификат общедоступного ключа ICC и общедоступный ключ эмитента. Если хвостовик восстановленных данных не равен 0хВС, аутентификация не проходит.

Если при проверке код заголовка восстановленных данных не равен 0х6А, аутентификация не проходит.

Если код формата сертификата не равен 0х04, аутентификация также не проходит.

Таблица 4.6.4.27. Формат восстановленных данных из сертификата общедоступного ключа ICC.

Имя поля	Длина (байт)	Описание
Заголовок восстановленных данных	1	Шестнадцатеричное число 0х6А
Формат сертификата	1	Шестнадцатеричное число 0х04
PAN приложения	10	PAN, дополненный справа кодами 0хF
Дата истечения времени действия сертификата	2	Дата ММГГ, после которой сертификат становится недействительным
Серийный номер сертификата	3	Двоичное число, уникальное для данного сертификата, присваиваемое центром сертификации
Индикатор хэш-алгоритма	1	Индицирует алгоритм, используемый для вычисления результирующего хэша цифровой подписи
Индикатор алгоритма общедоступного ключа ICC	1	Индицирует алгоритм вычисления цифровой подписи, который должен использоваться совместно с общедоступным ключом ICC
Длина общедоступного ключа ICC	1	Идентифицирует длину модуля общедоступного ключа ICC в байтах
Длина показателя общедоступного ключа ICC	1	Идентифицирует длину показателя общедоступного ключа ICC в байтах
Общедоступный ключ ICC или левые цифры общедоступного ключа ICC	NЭ - 42	Если NIC ? NЭ – 42, это поле состоит из полного общедоступного ключа ICC, дополненного справа NЭ – 42 - NIC байтами с кодом 0хBB. Если NIC > NЭ – 42, это поле состоит из NЭ – 42 старших байтов общедоступного ключа ICC
Результат хэширования	20	Хэш общедоступного ключа ICC и сопряженных с ним данных
Хвостовик восстановленных данных	1	Шестнадцатеричное число 0хВС

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

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

После получения общедоступного ключа ICC терминал выдает команду INTERNAL AUTHENTICATE для объединения информационных элементов DDOL (Dynamic Data Authentication Data Object List). ICC может нести в себе DDOL, но терминал имеет значение DDOL по умолчанию, специфицированное платежной системой на случай отсутствия этих данных в ICC. DDOL должен содержать непредсказуемое число, формируемое терминалом (тэг 0х9F37, четыре двоичных байта).

ICC генерирует цифровую подпись для данных, специфицированных в таблице 4.6.4.28 с использованием секретного ключа (SIC) ICC. Результат называется подписанными динамическими данными приложения.

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

Таблица 4.6.4.21. Формат восстановленных данных сертификата общедоступного ключа эмитента

Имя поля	Длина (байт)	Описание
Заголовок восстановленных данных	1	Шестнадцатеричное число 0х6A
Формат сертификата	1	Шестнадцатеричное число 0х02
Идентификационный код эмитента	4	Левые 3-8 цифр РАN, дополняемые справа кодами 0хF
Дата истечения действия сертификата	2	Дата ММГГ, после которой сертификат становится недействительным
Серийный номер сертификата	1	Двоичное число уникальное для сертификата, выданного центром сертификации
Индикатор хэш-алгоритма	1	Идентифицирует хэш-алгоритм, используемый для получения кода поля результата хэширования при вычислении электронной подписи
Индикатор алгоритма общедоступного ключа эмитента	1	Идентифицирует алгоритм цифровой подписи, который должен быть использован совместно с общедоступным ключом эмитента
Длина общедоступного ключа эмитента	1	Идентифицирует длину модуля общедоступного ключа эмитента в байтах
Длина показателя общедоступного ключа эмитента	1	Идентифицирует длину показателя степени общедоступного ключа эмитента в байтах
Общедоступный ключ эмитента или левые цифры общедоступного ключа эмитента	NCC - 36	Если NЭ ? NCC – 36, это поле состоит из полного общедоступного ключа эмитента, дополненного справа NCC – 36 - NЭ байтами, содержащими код BB. Если NЭ > NCC – 36, это поле состоит из NCC – 36 старших байт общедоступного ключа эмитента
Результат хэширования	20	Хэш-код общедоступного ключа эмитента и сопряженной с ним информации
Хвостовик восстановленных данных	1	Шестнадцатеричное число 0хВС

Проводится проверка заголовка восстановленных данных и, если он не равен 0х6А, аутентификация аннулируется.

Проверяется поле формат сертификата и, если его код не равен 0х02, аутентификация отвергается.

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

Результат данного объединения подвергается хэшированию согласно заданному алгоритму. Полученный результат сравнивается со значением поля результат хэширования (см. табл. 4.6.4.21). Если совпадения нет, аутентификация не состоялась.
Проверяется, что идентификационный номер эмитента соответствует левым цифрам 3-8 PAN. При несоответствии аутентификация отвергается.
Проверяется, не закончился ли срок действия сертификата. Если срок истек, аутентификации не происходит.
Проверяется то, что объединение RID, индекса общедоступного ключа центра сертификации, серийного номера сертификата является корректным, в противном случае аутентификация не проходит.
Если не распознан индикатор алгоритма общедоступного ключа эмитента, аутентификация также не пройдет. Если все предыдущие проверки прошли успешно, то производится объединение левых цифр общедоступного ключа эмитента и его остатка (если таковой имеется) с целью получения модуля общедоступного ключа эмитента, после чего процесс переходит в следующую фазу проверок подписанных статических прикладных данных.
Если подписанные статические прикладные данные имеют длину, отличную от длины модуля общедоступного ключа эмитента, аутентификация не состоится.
Для того чтобы получить данные, представленные в таблице 4.6.4.22, берутся подписанные статические прикладные данные и общедоступный ключ эмитента. Если хвостовик восстановленных данных окажется не равным BC, аутентификация отвергается.

Информационные объекты, необходимые для аутентификации статических данных

Таблица 4.6.4.20. Информационные объекты, необходимые для аутентификации статических данных

Метка (Tag)	Длина	Значение
-	5	Зарегистрированный идентификатор провайдера приложения (RID)
0х8F	1	Индекс общедоступного ключа сертификационного центра
0х90	NCC	Сертификат общедоступного ключа эмитента
0х92	NЭ - NCC + 36	Остаток общедоступного ключа эмитента (если присутствует)
0х9F32	1 или 3	Показатель общедоступного ключа эмитента
0х93	NЭ	Подписанные статические прикладные данные
-	Переменная	Статические данные, которые должны быть аутентифицированы

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

Если сертификат общедоступного ключа эмитента имеет длину отличную от модуля общедоступного ключа сертификационного центра, то аутентификация не пройдет.

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

Таблица 4.6.4.25. Информационные объекты, необходимые для аутентификации общедоступного ключа

Метка (Tag)	Длина (байт)	Описание
-	5	Зарегистрированный идентификатор провайдера приложения (RID)
0х8F	1	Индекс общедоступного ключа центра сертификации
0х90	NCC	Сертификат общедоступного ключа эмитента
0х92	NЭ - NCC + 36	Остаток общедоступного ключа эмитента (если имеется)
0х9F32	1 или 3	Показатель общедоступного ключа эмитента
0х9F46	NЭ	Сертификат общедоступного ключа ICC
0х9F48	NIC - NЭ + 42	Остаток общедоступного ключа ICC (если он имеется)
0х9F47	1 или 3	Показатель общедоступного ключа ICC
-	Переменная	Данные, подлежащие аутентификации

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

Если сертификат общедоступного ключа эмитента имеет длину отличную от длины модуля общедоступного ключа сертификационного центра, аутентификация динамических данных не проходит.

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

Проверяется заголовок восстановленных данных и, если он не равен 0х6А, аутентификация отвергается.

Проверяется код формата сертификата и, если он не равен 0х02, аутентификация отвергается.

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

Кодирование командного байта

Таблица 4.6.4.11. Кодирование командного байта

CLA	INS	Назначение
8х	1Е	APPLICATION BLOCK (Заблокировать приложение)
8х	18	APPLICATION UNBLOCK (Разблокировать приложение)
8х	16	CARD BLOCK (Заблокировать карту)
0х	82	EXTERNAL AUTHENTICATE (Внешняя аутентификация)
8х	АЕ	GENERATE APPLICATION CRYPTOGRAM (Сформировать прикладную криптограмму)
0х	84	GET CHALLENGE (Получить вызов)
8х	СА	GET DATA (Получить данные)
8х	А8	GET PROCESSING OPTIONS (Получить опции обработки)
0х	88	INTERNAL AUTHENTICATE (Внутренняя аутентификация)
8х	24	PERSONAL IDENTIFICATION NUMBER (PIN) CHANGE/UNBLOCK – изменение/разблокировка персонального идентификатора
0х	В2	READ RECORD (Прочесть запись)
0х	А4	SELECT (Выбор)
0х	20	VERIFY (Проверка)
8х	Dx	RFU для платежных систем
8х	Ex	RFU для платежных систем
9х	Xx	RFU производителя для кодирования INS собственника
Ех	xx	RFU эмитента для кодирования INS собственника

Статусные байты SW1 и SW2 указывают TTL, что обработка команды завершена. Значения этих байт интерпретируются в зависимости от обрабатываемой команды. Коды и значения полей SW1 и SW2 представлены в таблице 4.6.4.12.

Кодирование PCB I-блоков

Таблица 4.6.4.13. Кодирование PCB I-блоков

b8	0
b7	Номер по порядку
b6	Цепочка (есть еще данные)
b5-b1	Зарезервировано на будущее

Кодирование PCB R-блоков

Таблица 4.6.4.14. Кодирование PCB R-блоков

b8	1
b7	0
b6	0
b5	Номер по порядку
b4-b1	0 – Отсутствие ошибки 1 – EDC и/или ошибка четности 2 – другие ошибки остальные коды зарезервированы

Кодирование PCB S-блоков

Таблица 4.6.4.15. Кодирование PCB S-блоков

b8	1
b7	1
b6	0 – запрос 1 - отклик
b5-b1	0 – запрос повторной синхронизации 1 – запрос размера поля данных 2 – запрос абортирования 3 – расширение BWT-запроса 4 – VPP-ошибка остальные коды зарезервированы

Поле LEN определяет размер информационного поля и может равняться 0-254. R-блоки не имеют поля данных. Блоки I- и S-типов нумеруются по модулю 2, их число может равняться 0 или 1 (первый блок имеет номер 0). Счетчик нумерации сбрасывается в 0 после ресинхронизации.

Поле EDC представляет собой объединение всех байт блока, начиная с NAD и кончая последним байтом поля INF (если это поле присутствует), с помощью операции исключающее ИЛИ.

Максимальный размер поля данных ICC (IFSC) блока определяется параметром ТА3, присылаемым ICC в отклике на сброс. IFSI может принимать значения 10-FE, что означает для IFSC диапазон 16-254 байта. Максимальный размер поля данных терминала (IFSD) составляет 254 байта.

Время ожидания блока BWT (Block Waiting Time) в общем случае вычисляется согласно следующей формуле. Реально BWT может лежать в диапазоне (971-15371)t.

Когда отправитель намерен передать объем данных больше, чем это определено параметрами IFSC или IFSD, он должен разбить эту последовательность байтов на несколько I-блоков. Передача этих блоков осуществляется с привлечением механизма цепочек. Для объединения I-блоков в цепочку используется бит b6 в PCB (смотри табл. 4.6.4.13). Если b6=0, то это последний блок в цепочке. Если же b6=1, далее следует как минимум еще один блок. Получение любого I-блок с b6=1 должно быть подтверждено R-блоком. Последний блок цепочки, посланный терминалом, подтверждается I-блоком, если получен безошибочно, или R-блоком, при обнаружении ошибки. В случае ICC получение последнего блока цепочки подтверждается R-блоком при обнаружении ошибки. Если ошибки не было, терминал просто посылает очередной I-блок, если должна обрабатываться очередная команда. Передача цепочки возможна в одно и тоже время только в одном направлении.
Когда терминал является получателем, он воспринимает цепочки I-блоков, передаваемых ICC, если длина блоков ? IFSD. Если получателем является ICC, карта воспринимает цепочку I-блоков, посланных терминалом и имеющих длину LEN=IFSC, за исключением последнего блока, длина которого может лежать в диапазоне (1-IFSC). Если длина блока > IFSC, ICC такой блок отвергает, послав R-блок с битами b4-b1 в PCB, равными 2.

4.6.4.2. Элементы данных и файлы

Приложение в ICC содержит набор информационных элементов. Терминал может получить доступ к этим элементам после успешного выбора приложения. Информационным элементам присваиваются имена, они имеют определенное описание содержимого, формат и кодирование. Информационный объект состоит из метки (tag), кода длины и значения. Метка однозначно идентифицирует объект в рамках данного приложения. Поле длина определяет число байт в поле значение. Объекты могут объединяться, образуя составные объекты. Определенное число простых или составных объектов могут образовывать записи. Присвоение меток регламентируется документами ISO/IEC 8825 и ISO/IEC 7816. Записи, содержащие информационные объекты, хранятся в файлах ICC. Структура файла и метод доступа зависят от назначения файла. Организация файлов определяется приложениями платежной системы PSA (Payment System Application). Проход к набору PSA в ICC разрешается с помощью выбора среды платежной системы PSE (Payment System Environment). Когда PSE присутствует, файлы, относящиеся к PSA, доступны для терминала через древовидную структуру каталога. Каждая ветвь этого дерева является файлом определения приложения ADF (Application Definition File) или файлом определения каталога DDF (Directory Definition File). ADF является входной точкой одного или нескольких прикладных первичных файлов AEF (Application Elementary File). ADF со стороны терминала воспринимается как файл, содержащий информационные объекты, которые инкапсулированы в FCI (File Control Information). Информационные файлы состоят из последовательности пронумерованных записей.


Каждому файлу присваивается короткий идентификатор SFI (принимает значения 1-10), с помощью которого можно обращаться к файлу. Чтение каталога осуществляется с помощью команды READ RECORD.
Когда PSE присутствует, ICC поддерживает структуру каталога для списка приложений в пределах PSE (определяется эмитентом карты). Каждому приложению присваивается идентификатор AID (Application Identifier; ISO/IEC 7816-5). К любому ADF или DDF в карте обращение производится посредством имени DF (Dedicated File). DF для ADF соответствует AID и для данной карты должно быть уникальным. Формат записи каталога PSE показан на рисунке 4.6.4.11.

Метка 70

Длина данных (L)

Метка 61

Длина элемента 1 каталога

Элемент каталога 1 (ADF или DDF)

… … …

Метка 61

Длина элемента N каталога

Элемент каталога N (ADF или DDF)

Состояние постоянной памяти не изменилось;

Таблица 4.6.4.12. Кодирование статусных байтов SW1, SW2

SW1	SW2	Значение
90	00	Нормальная обработка Процесс завершился успешно
62 63 63	83 00 Сх	Обработка с предупреждением Состояние постоянной памяти не изменилось; выбранный файл некорректен Состояние постоянной памяти изменилось; аутентификация не прошла Состояние постоянной памяти изменилось; счетчик задан “x” (0-15)
69 69 69 6А 6А 6А	83 84 85 81 82 83	Контроль ошибок Команда не разрешена; метод аутентификации блокирован Команда не разрешена; запрошенные данные некорректны Команда не разрешена; условия использования не выполнены Неверные параметры Р1 Р2; функция не поддерживается Неверные параметры Р1 Р2; файл не найден Неверные параметры Р1 Р2; запись не найдена

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

Таблица 4.6.4.10. Отклик терминала на процедурный байт

Значение процедурного байта	Действие терминала
Байт равен INS	Все остальные байты данных будут переданы TTL, или TTL будет готов принять все остальные байты от ICC
Байт равен дополнению INS	Следующий байт данных будет передан TTL или TTL будет готов принять следующий байт от ICC
60	TTL введет дополнительное время выдержки (Work Waiting Time)
61	TTL будет ждать следующий процедурный байт, затем пошлет ICC команду GET RESPONSE с максимальной длиной “xx”, где хх равно значению второго процедурного байта
6C	TTL будет ждать следующий процедурный байт, после чего немедленно повторно пошлет ICC предыдущий командный заголовок, используя длину “xx”, где хх равно значению второго процедурного байта

Во всех случаях после реализации операции TTL ждет прихода процедурного байта или статусного сообщения.

Командное сообщение, посылаемое от прикладного уровня, и сообщение-отклик ICC называются APDU (Application Protocol Data Unit). Формат APDU показан на рисунке 4.6.4.8.

Сопротивление кабеля по

Таблица 4.1.1.1.2 Сопротивление кабеля по постоянному току

(Handbook of LAN Cable Testing. Wavetek Corporation, California)

Коаксиал		Ом/сегмент	Максимальная длина сегмента
10base5		5	500 м
10base2		10	185 м
Скрученная пара	Ом/100 м
24 awg	18,8
22 awg	11,8

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

Помимо уже описанных модификаций сетей ethernet в последнее время получили распространение сети для частот 100 Мбит/с, которые базируются на каналах, построенных из скрученных пар или оптоволоконных кабелей. Оптические связи используются и в обычном 10-мегагерцном ethernet (10base-FL, стандарт разработан в 1980 году, см. Рисунок 4.1.1.1.9).

Оптоволоконная версия ethernet привлекательна при объединении сегментов сети, размещенных в различных зданиях, при этом увеличивается надежность сети, так как ослабляется влияние электромагнитных наводок, исключается влияние различия потенциалов земли этих участков сети. Облегчается переход от 10- к 100-мегагерцному Ethernet, также можно использовать уже имеющиеся оптоволоконные каналы, ведь они будут работать и на 100 Мбит/с (возможна реализация сетей со смешанной структурой, где используется как 100- так и 10-мегагерцное оборудование). На программном уровне 10- и 100-МГц ethernet не различимы. Требования к параметрам опто-волоконных кабелей не зависят от используемого протокола (FDDI, Token Ring, Fast Ethernet и т.д.) и определяются документом EN 50173 (European norm). Это утверждение не относится к топологии кабельных связей, которые в общем случае зависят от используемого протокола. При работе с оптоволоконными системами необходимы специальные тестеры, способные измерять потери света и отражения методом OTDR (рефлектометрия с использованием метода временных доменов). При пассивной звездообразной схеме длины оптоволоконных сегментов могут достигать 500 метров, а число подключенных ЭВМ - 33. Для передачи сигналов используются многомодовые волокна (MMF) с диаметром ядра 62,5 микрон и клэдинга 125 микрон. Длина волны излучения равна 850 (или 1350) нанометров при ослаблении сигнала в кабельном сегменте не более 12,5 дБ. Обычный кабель имеет ослабление 4-5 дБ/км. Оптические разъемы должны соответствовать требования стандарта ISO/IEC BFOC/2,5 и вносить ослабление не более 0,5 - 2,0 дБ. Количество используемых mau в логическом сегменте не должно превышать двух.

Статическая прикладная информация, подписываемая эмитентом

Таблица 4.6.4.19. Статическая прикладная информация, подписываемая эмитентом

Имя поля	Длина (байт)	Описание
Формат подписанных данных	1	Шестнадцатеричное число 0х03
Индикатор хэш-алгоритма	1	Идентифицирует алгоритм хэширования, используемый для вычисления поля результат хэширования для цифровой подписи
Код аутентификации данных	2	Код, присвоенный эмитентом
Код заполнителя	NЭ - 26	Код байта заполнителя, равный 0хBB
Статические данные, подлежащие аутентификации	Перемен-ная	Статические данные, которые подлежат аутентификации согласно требованиям приложения ICC

Возможности различных схем реализации ethernet

Таблица 4.1.1.1.1. Возможности различных схем реализации ethernet

Тип кабеля	Толстый (10base5)	Тонкий (10base2)	Скрученная пара (10baset)
Максимальная длина сети (м)	2500	900	-
Максимальная длина кабельного сегмента (м)	500	185	100
Максимальное число подключений к сегменту	100	30	1
Минимальное расстояние между точками подключения (м)	2.5	0.5	-
Максимальное удаление узлов	5 сегментов и 4 повторителя	5 сегментов и 4 повторителя	5 сегментов и 4 повторителя

Из таблицы видно, что максимальная задержка в сети ethernet складывается из:

4*tr (задержка, вносимая повторителями, при их максимальном числе =4; tr - задержка сигнала в репитере, ~20 бит-тактов)

4,5нсек/м*5*500м (задержка пяти кабельных сегментов)

4нсек/м*2*50м (задержка, вносимая двумя кабелями aui, первого и последнего сегментов)

задержки сетевых интерфейсов и трансиверов (~2*20 бит-тактов)

В сумме это соответствует ~220 бит-тактам. Минимальная длина пакета должна быть больше удвоенного значения этой задержки (выбрано 64 байта = 512 тактов). Если размер пакета меньше 64 байт, добавляются байты-заполнители, чтобы кадр в любом случае имел соответствующий размер. При приеме контролируется длина пакета и, если она превышает 1518 байт, пакет считается избыточным и обрабатываться не будет. Аналогичная судьба ждет кадры короче 64 байт. Любой пакет должен иметь длину, кратную 8 бит (целое число байт). Если в поле адресата содержатся все единицы, адрес считается широковещательным, то есть обращенным ко всем рабочим станциям локальной сети. Пакет ethernet может нести от 46 до 1500 байт данных. Формат адреса получателя или отправителя (MAC) показан на Рисунок 4.1.1.1.4. Для передачи данных на физическом уровне используется манчестерский код.

Временная диаграмма дезактивации контактов ICC

Рисунок 4.6.4.6. Временная диаграмма дезактивации контактов ICC

Исходная длительность такта на шине I/O определяется как:

t = 372/f секунд,

где f частота в Гц. В общем случае t определяется как:

t = F/(Df),

где f частота в Гц, F и D параметры, которые могут варьироваться, но обычно F=372, а D=1. f лежит в пределах (1-5) МГц.

Временная диаграмма “теплого” сброса

Рисунок 4.6.4.5. Временная диаграмма “теплого” сброса

Следует учитывать, что при теплом сбросе напряжение питание Vcc имеет рабочий уровень, шина RST имеет уровень H, состояние шины I/O может быть любым. После перехода шины RST в состояние L (момент времени T0’) на шине I/O не позднее чем через 200 тактов должен установиться уровень H. В момент Т1’ шина RST переходит в состояние H, после чего завершается процедура сброса аналогично “холодному” варианту.

Процедура деактивации контактов ICC показана на Рисунок 4.6.4.6. В момент начала этой процедуры напряжение питание Vcc имеет рабочий уровень, шина RST имеет уровень H, состояние шины I/O может быть любым. Сигналом к началу процесса является переход шины RST в низкое состояние. Через некоторое время состояние шины I/O должно стать низким, прекращается подача тактовых импульсов, после чего с небольшой задержкой напряжение питания Vcc

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

Зависимость пропускной способности lin сети со схемой доступа CSMA/CD от суммарной загрузки l

Рисунок 4.1.1.1.8. Зависимость пропускной способности lin сети со схемой доступа CSMA/CD от суммарной загрузки l

Вначале эта зависимость линейна и на участке А пропускная способность удовлетворительна. Но при больших входных загрузках из-за коллизий сначала наступает насыщение, а затем и резкий спад (Ethernet collapse). Это свойство сетей с CSMA/CD дает определенные преимущества сетям с маркерным доступом: Token Ring, FDDI и др..

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

Зоны заземлений

Рисунок 4.1.1.1.12. Зоны заземлений

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

---

---