Google+
Журнал Плас Плас Журнал http://www.plusworld.ru/
ул. Кржижановского, д. 29, корп. 5 Москва, 117218 Россия
+7 495 961 1065 http://www.plusworld.ru/upload/templates/logo_plus_ru.png
RSS RSS RSS RSS

LEO: конструктор для разработчика карточных проектов

(Нет голосов)

23.03.1999 Количество просмотров 891 просмотр
Легко ли разработать систему лояльности или платежную систему на основе смарт-карточек? Непросто, ответит специалист. Необходимы знания, опыт, наработки по меньшей мере из следующих областей знаний: собственно карточки с интегральной микросхемой, POS-терминалы, процессинг и транспортировка транзакций, безопасность. Причем каждая из этих областей - это самостоятельный «мир» со своим огромным объемом информации, который необходимо найти, изучить и адаптировать под собственные нужды.

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

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

В основу разработки платформы LEO были положены следующие принципы:     масштабируемость (платформа может быть использована для реализации малых, средних и больших проектов);     возможность расширения функциональности системы, разработанной на основе платформы LEO;     отсутствие привязки к конкретному программному или аппаратному окружению (типу операционной системы, платежному терминалу и т. д.);     широкое использования международных стандартов (ISO) и спецификаций (EMV). Состав и функциональность Система на базе пластиковых карточек, созданная с использованием возможностей LEO, имеет следующие отличительные особенности: •    в качестве среды для хранения информационных объектов используется память карточки с интегральной микросхемой. К информационным объектам относятся «электронные кошельки», журнальные файлы и т. д. В каждом «кошельке», имеющем собственный срок действия, могут хранится деньги, призовые очки и другая информация подобного рода. На одной карточке клиента может быть создано до 8 «кошельков»; •     «Электронные кошельки» могут создаваться на карточке или удаляться с нее динамическим образом, то есть уже после ее выпуска. При создании и удалении кошельков, а также при пополнении или уменьшении их содержимого могут использоваться заранее определенные наборы правил; •    Верификация информационных объектов на карточках клиентов производится по заранее установленным правилам; •    Карточки клиентов могут защищаться PIN-кодами; •    Персонализация клиентских карточек выполняется в 2 этапа: генерация карточки (предварительная разметка ) и окончательная персонализация; •    Транзакции хранятся в терминале с последующей передачей в процессинговый центр по модемной связи; •    В системе предусмотрено использование механизмов распознавания преднамеренного или случайного искажения информации на карточке клиента.

Платформа LEO включает следующие основные компоненты (рис. 1): карточки клиентов, модули безопасности, систему генерации ключей, программное обеспечение (ПО) POS-терминала, ПО процессингового центра.

Карточки клиентов В настоящее время в качестве клиентских карточек используются карточки памяти (информационная емкость - 256 байт ) со встроенной функцией защиты от записи .

Информационные объекты, размещаемые на карте клиента, формируются в соответствии со стандартом ISO-7816/ Часть 6. На карточке размещаются объекты двух типов: статические и динамические. Статические объекты (серийный номер карты, статическая криптограмма и другие) заносятся на карточку в процессе ее подготовки к использованию в системе, защищаются криптографической контрольной суммой (криптограммой) и не подлежат изменению в процессе всего жизненного цикла карточки. Динамические объекты (предоплаченный, дебетный, кредитный, бонусный «кошельки», журнальные файлы) изменяются по мере выполнения транзакций и, как и статические объекты, могут защищаться криптограммой. На карточке может быть создано несколько «кошельков» одного типа, но с различным сроком действия, что расширяет гибкость системы. Возможно использование PIN-кода длиной 4 цифры  Наряду с карточками памяти, в дальнейшем планируется использовать в качестве клиентских карточек клиента и микропроцессорные карточки. Это существенно расширит диапазон применения платформы в сторону систем с повышенными требованиями к безопасности.

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

Задачи хранения ключей для вычисления криптограмм, а также вычисления и сравнения криптограмм в платформе LEO возложены на модуль безопасности (SAM), реализованный на основе микропроцессорной карточки. В модуле безопасности хранятся защищенные от чтения криптографические ключи, на основе которых формируется уникальный ключ для каждой карты клиента. Более того, для одной и той же карты клиента при проведении двух разных транзакций будут сформированы два разных ключа.  В платформе LEO предусмотрено использование двух типов модулей безопасности: модуль безопасности терминала (T-SAM) и модуль безопасности системы персонализации (I-SAM). Модуль безопасности терминала поддерживает использование номера версии ключа, что позволяет легко изменять ключи в случае необходимости. Доступ к модулю безопасности защищен 8 байтным кодом доступа, который распространяется отдельно от SAM и вводится в память терминала вручную. Каждый модуль T-SAM «привязывается» к конкретному терминалу, т. е. хранит идентификатор терминала и идентификатор продавца.

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

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

С целью уменьшения трудоемкости разработки терминального ПО в платформе LEO использованы следующие решения:     разделение ПО терминала на две подсистемы: подсистема, ответственная за выполнение транзакций (Application Task), и коммуникационная подсистема (Communication Task);     использование концепции драйверов ввода-вывода для выделения аппаратно-зависимых частей ПО;     обеспечение разработчика т. н. «виртуальным терминалом». Платформа предоставляет разработчику набор программных модулей в виде исходного текста для разработки законченного ПО терминала, включая задачу проведения транзакций и задачу обмена информацией с процессинговым центром. Структура ПО терминала приведена на .

Основным инструментом разработки ПО терминала является «виртуальный терминал». Это Windows-приложение моделирует типовые компоненты реального POS-терминала: конфигурируемые разработчиком дисплей, клавиатуру и принтер. Используя «виртуальный терминал», разработчик имеет возможность отладить на PC все интересующие его части программ. При этом работа с карточкой клиента и модулем безопасности может осуществляться двумя способами:  - подключением к компьютеру картридера и использованием реальных карт (карты клиента и SAM) или  - моделированием карточки клиента двоичным файлом на диске, а модуля безопасности - значением ключа и функцией формирования криптограммы.

После завершения процесса разработки и отладки ПО терминала при переходе на реальную аппаратную платформу необходимо будет заменить только следующие аппаратно-зависимые программные блоки:     вывод на дисплей;     ввод с клавиатуры;     вывод на принтер;     работа с карточкой клиента;     работа с T-SAM;     работа с модемом. Заключительным этапом разработки отлаженного ПО терминала будет перекомпиляция исходных программ под конкретный тип терминала.

В настоящее время в составе платформы LEO имеются отлаженные модули для работы терминалами МСТ 5000 производства фирмы ORGA Kartensysteme GmbH (Германия) и OMNI 1200 производства фирмы VeriFonе (США). Планируется разработать ПО для терминалов серии Elite (Ingenico).

Процессинговый центр Основными компонентами процессингового центра  являются:     модуль сбора-передачи информации FEP (Front End Processing), отвечающий за прием-передачу информации между процессинговым центром и терминалами;     модуль анализа транзакций, проверяющий все транзакции, фильтрующий дубликаты и ведущий учет последовательности транзакций;     модуль ведения счетов (booking);     административный модуль . Процессинговый центр выполнен в виде последовательности ActiveX- серверов, работающих под управлением Windows NT. Все сервера используют единую базу данных платформы LEO посредством ODBC. В исходной версии платформы реализована база данных Microsoft Access, но для средних и крупных проектов рекомендуется использовать Microsoft SQL.

Функциями модуля сбора-передачи информации являются сбор данных о выполненных транзакциях с терминалов (off-line транзакции, блокированные карточки) и рассылка информации по терминалам (изменения в конфигурации терминалов, стоп-листы). В рамах выполнения этих функций система решает следующие задачи:     установление соединения с терминалом (инициировать сеанс связи может как сам терминал, так и Front-end processor);     выполнение on-line транзакции (например, загрузка «кошелька»);     прием файла транзакций;     обработка off-line транзакций;     формирование стоп-листа;     рассылка конфигурационных данных терминала или стоп-листов;     обновление стоп-листов;     проверка расписания сеансов связи с терминалами;     сбор данных о транзакциях с терминалов;     предварительная проверка транзакций. Результатом работы системы сбора-передачи информации является временный файл транзакций, используемый модулем анализа транзакций.

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

Модуль ведения счетов решает задачи ведения карточных счетов, счетов терминалов и т. д. *** В заключение следует остановиться на организационных аспектах и имеющемся опыте использования платформы LEO. Поставка платформы разбита на две части: оценочная часть (Evaluation Kit) и активирующая часть (Activation Kit). В комплект поставки первой части платформы водят:     карточный терминал;     2 модуля безопасности;     50 карточек клиента;     программное обеспечение;     детальная документация;     техническая поддержка. Имея первую часть платформы, системный интегратор в состоянии не только изучить все возможности платформы, но и разработать проект, который можно продемонстрировать Заказчику.

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

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

Комментарии (0):

Добавлять комментарии могут только зарегистрированные Пользователи


Читайте в этом номере:
обновить

а вы знаете, что...

… в Океании раковины каури (моллюсков) сохранились как платежное средство ограниченного оборота до наших дней? В настоящее время среди всех архипелагов Океании раковины моллюсков действительно распространены в качестве не декоративной, а реальной расчетной единицы на Соломоновых островах.