Интеграция защищенных банковских ATM-систем с использованием WebSphere Message Broker

Данные банковской ATM-карты требуют очень высокой степени защиты и обрабатываются с использованием специальных устройств и программных протоколов защиты. В данной статье рассматривается использование WebSphere Message Broker для обработки защищенных данных банковской ATM-карты путем интеграции двух широко распространенных систем защиты: Host Security Module (HSM) и IST/Switch.

Хешам Султан, ИТ-архитектор, Каирский центр разработки технологий, IBM

Хешам Султан (Dr. Hesham Soultan) – фотографияХешам Султан (Dr. Hesham Soultan) работает ИТ-архитектором в Каирском центре разработки технологий в Египте. Имеет опыт разработки встраиваемого программного обеспечения для автомобильной отрасли, систем компьютерного зрения, машинного обучения и бизнес-интеграции. После прихода в группу IBM Business Integration работает над WebSphere DataPower, WebSphere Message Broker и WebSphere MQ. Связаться с ним можно по адресу hsoultan@eg.ibm.com.



20.11.2012

Введение

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

IBM имеет надежно защищенную высокопроизводительную криптографическую подсистему, которая может выполнить любое шифрование, необходимое для ATM-систем: модуль 4765 Cryptographic Security Module, соответствующий стандарту FIPS 140-2, общий уровень 4 (самый высокий уровень защиты). Хотя интеграция модуля 4765 Cryptographic Security Module выполняется просто, иногда приходится интегрировать его со сторонней системой шифрования, что требует дополнительного программирования. Однако IBM® WebSphere® Message Broker (здесь и далее – Message Broker) может помочь в этом. В данной статье в качестве ATM-системы используется IST/Switch, а в качестве аппаратуры шифрования - стороннее устройство Host Security Module (HSM).

HSM предоставляет различные функции для реализации управления ключами, управления и верификации PIN-кодов, а также обработки кода аутентификации сообщения (Message Authentication Code, MAC). Во время работы Message Broker вызывает две HSM-команды для шифрования PIN-кода и генерирования 16-цифрового PIN-блока. Затем он использует этот PIN-блок в качестве входных данных для любой дебетовой транзакции, выполняющейся в ATM-системе. На рисунке 1 показана архитектура интеграции защищенной ATM-системы.

Рисунок 1. Архитектура интеграции защищенной ATM-системы
Рисунок 1. Архитектура интеграции защищенной ATM-системы

В разделе "Интеграция HSM" рассматривается интеграция Message Broker с устройством HSM, описываются проблемы и даются рекомендации по работе с HSM. В разделе "Интеграция IST/Switch" рассматривается процесс интеграции ATM-системы (IST/Switch) и приводится информация по устранению неполадок.

1. Интеграция HSM

В качестве HSM-устройства в статье используется Thales HSM 8000. Обычно HSM выступает в роли периферийного устройства для хост-компьютера и выполняет криптографическую обработку в физически защищенной среде от его имени. HSM выполняет обработку в ответ на команды, получаемые по TCP/IP-соединению. В нашем сценарии HSM-устройство используется для шифрования PIN-кода.

В данном разделе объясняется взаимодействие с этим устройством для выполнения команд из Message Broker. Необходимо выполнить две команды для получения зашифрованного PIN-блока из 16 шестнадцатеричных цифр из незашифрованного 4-цифрового PIN-кода за два шага. На рисунке 2 показан подпоток Message Broker для выполнения одной HSM-команды.

Рисунок 2. Подпоток Message Broker для выполнения HSM-команды
Рисунок 2. Подпоток Message Broker для выполнения HSM-команды

Первый вычислительный узел в потоке подготавливает ответное сообщение на HSM-команду и преобразует его в поток битов типа BLOB для выдачи в узел TCPIP Client Output HSM. В листинге 1 приведены ESQL-выражения (Embedded SQL) для формулирования ответного сообщения.

Листинг 1. Код ответа для первой HSM-команды
CREATE LASTCHILD OF OutputLocalEnvironment DOMAIN('MRM'); 
SET OutputLocalEnvironment.MRM.MsgLength = X'0017'; --Длина 23 символа
SET OutputLocalEnvironment.MRM.HSMMessageHeader = SUBSTRING(rEnv.MsgUId FROM 1 FOR 4);
SET OutputLocalEnvironment.MRM.HSMCommandCode = 'BA';
SET OutputLocalEnvironment.MRM.HSMInputPIN = rEnv.CardPIN;

DECLARE Len INT LENGTH(rEnv.CardNum);
-- < Взять 12 цифр перед самой правой цифрой (контрольная цифра) >
SET OutputLocalEnvironment.MRM.HSMAccountNum = 
    SUBSTRING(rEnv.CardNum From(Len - 12) FOR 12); 

SET BlobBitstream = ASBITSTREAM(OutputLocalEnvironment.MRM 
    OPTIONS options 
    SET 'ISO_ATM_HSM_MsgSt'
    TYPE 'HSMMessage_Request1'
    FORMAT 'Text1');

Как показано выше, команда использует код BA, который соответствует команде Encrypt a Clear PIN. Первый параметр после кода команды – это чистый текстовый PIN-код, выровненный по левому краю и дополненный шестнадцатеричной цифрой F до длины зашифрованного PIN-кода. Второй параметр – это 12 самых правых цифр номера счета или номера карты, исключая контрольную цифру (самая правая цифра).

Последнее выражение в листинге 1 генерирует ответное сообщение в его окончательном формате для передачи в HSM. Оно включает в себя поток битов сообщения команды. Поток битов содержит длину (первый элемент сообщения) в шестнадцатеричном формате, а остальные элементы сообщения представлены в ASCII-кодировке (CCSID 1208).

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

Длина ответного сообщения на эту команду будет зависеть от состояния (успех или неудача), поэтому Message Broker читает его за два шага. На первом шаге он читает только первые четыре символа, представляющие собой шестнадцатеричную длину сообщения. Затем вычислительный узел Get Length присваивает эту длину соответствующей переменной среды для динамического определения длины записи, считываемой вторым узлом TCP/IP Client Input – ReceiveFromHSM2. Подробная информация о программировании принимающих TCP/IP-узлов переменной длины, а также о работе с TCP/IP-соединениями и ISO 8583 приведена в статье developerWorks Интеграция с TCP/IP при помощи WebSphere Message Broker (EN).

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

Листинг 2. Анализ HSM-ответа
CREATE LASTCHILD OF Environment.Variables.CIB.HSMResponse DOMAIN('MRM')
    PARSE(InMessageBlob 	
    SET 'ISO_ATM_HSM_MsgSt'
    TYPE Environment.Variables.CIB.HSMResponseMsgName
    FORMAT 'Text1');

Результатом этой команды является пятисимвольный зашифрованный PIN-код, основанный на четырех входных символах; этот PIN-сод используется в качестве входных данных для второй команды. Вторая команда выполняется аналогично первой с кодом команды JG. Она возвращает зашифрованный PIN-блок из 16 шестнадцатеричных символов, используемый в запросе к IST/Switch.

Проблемы и рекомендации по работе с HSM

Вот некоторые проблемы, с которыми может столкнуться разработчик во время интеграции HSM:

  • Многие параметры определяются при настройке HSM, поэтому необходимо получить их у владельца HSM для использования во время разработки. Например, длина Encrypted PIN и длина заголовка Message – два ключевых параметра практически всех команд, которые задаются владельцем HSM во время настройки HSM.
  • Форматы некоторых частей запроса и ответа не упоминаются в документации явно, и для их определения может потребоваться много времени или даже применение метода проб и ошибок.
  • Одним из основных элементов сообщения является элемент, содержащий информацию о длине и формате. Ни один из источников не содержит четкой информации по этому элементу. Исследования позволили выявить этот элементы и показали, что его длина равна двум байтам в шестнадцатеричном формате, причем эти два байта передаются по TCP/IP именно в этом формате, а не в ASCII-кодировке, как остальные параметры.

2. Интеграция IST/Switch

IST/Switch от компании eFunds Canada Corporation представляет собой систему, поддерживающую большинство транзакций, необходимых для реализации сети Electronic Funds Transfer / Point of Sale (EFT/POS). Более подробная информация о IST/Switch приведена в Руководстве по EFunds OASIS Host Formatter Subsystem (EN). IST/Switch взаимодействует с хост-компьютером по TCP/IP в соответствии со стандартом ISO 8583. Дополнительная информация по ISO 8583 и использованию Message Broker для такого TCP/IP-взаимодействия приведена в статье developerWorks Интеграция с TCP/IP при помощи WebSphere Message Broker (EN).

Стандарт ISO 8583 определяет несколько классов сообщений, устанавливающих тип запрашиваемой транзакции. В данной статье был использован один из классов финансовых сообщений – сообщение со значением идентификатора MTI (Message Type Identifier), равным 0200. Это сообщение используется для запроса финансовой авторизации транзакции. Сообщение 0210 – это MTI-идентификатор ответа на сообщение 0200. На рисунке 3 показан поток Message Broker для выполнения всего процесса авторизации финансовой транзакции. Он дважды вызывает подпоток HSM для выполнения двух команд шифрования, а затем использует результат шифрования для подготовки ответного сообщения IST/switch ISO 8583.

Рисунок 3. Поток финансовой авторизации
Рисунок 3. Поток финансовой авторизации
Листинг 3. ESQL-код для создания ответного сообщения IST/Switch ISO 8583
CREATE LASTCHILD OF OutputLocalEnvironment DOMAIN('MRM'); 
--<Генерирование двоичной битовой карты с использованием списка номеров элементов>
DECLARE Items ROW ;
CREATE LASTCHILD OF Items NAME 'a';
SET Items.a[] = LIST{3,4, 7, 11, 12, 13, 18, 22, 35, 37, 41, 43, 49, 52}; 
DECLARE MessageLength CHAR '168';
DECLARE MTI CHAR '0200';
DECLARE rItems REFERENCE TO Items;
DECLARE BitmapBit BIT CAST ('00000000' AS BIT); 
CREATE LASTCHILD OF OutputLocalEnvironment.MRM NAME 'PrimaryBitmap';
DECLARE rTargetMrm REFERENCE TO OutputLocalEnvironment.MRM.PrimaryBitmap;
CALL CreateBitMaps(rItems , rTargetMrm, BitmapBit);
DECLARE BitmapBlob BLOB CAST(BitmapBit AS BLOB);
DECLARE BitmapChar CHAR SUBSTRING(CAST (BitmapBlob AS CHAR) FROM 3 FOR 16);
SET OutputLocalEnvironment.MRM.MsgLen = MessageLength;
SET OutputLocalEnvironment.MRM.MTI = MTI;
SET OutputLocalEnvironment.MRM.BinaryBitmap = BitmapChar; --Установка верного значения.
SET OutputLocalEnvironment.MRM.ProcessingCode = '303000';
SET OutputLocalEnvironment.MRM.AmountTransaction = '000000000000';
SET OutputLocalEnvironment.MRM.TransmissionDateAndTime = 
    CAST(CURRENT_TIMESTAMP AS CHARACTER FORMAT 'MMddHHmmss');
DECLARE Len INT LENGTH(rEnvesbXML.MsgUId);
SET OutputLocalEnvironment.MRM.SystemsTraceAuditNumber = 
    SUBSTRING(rEnvesbXML.MsgUId From(Len - 5) FOR 6);
SET OutputLocalEnvironment.MRM.TimeLocalTransaction = 
    CAST(CURRENT_TIME AS CHARACTER FORMAT 'HHmmss'); 
SET OutputLocalEnvironment.MRM.DateLocalTransaction = 
    CAST(CURRENT_DATE AS CHARACTER FORMAT 'MMdd'); 
SET OutputLocalEnvironment.MRM.MerchantType = '6011'; 
SET OutputLocalEnvironment.MRM.PointOfServiceEntryMode = '901';
SET Len = LENGTH(rEnvesbXML.CardNum);
SET OutputLocalEnvironment.MRM.Track2Data.Length = Len; 
SET OutputLocalEnvironment.MRM.Track2Data.Track2Data = rEnvesbXML.CardNum; 
DECLARE text CHAR CAST(CURRENT_TIMESTAMP AS CHARACTER FORMAT 'yyDDDHH');
SET OutputLocalEnvironment.MRM.RetrievalReferenceNumber = 
    SUBSTRING(text FROM 2) || OutputLocalEnvironment.MRM.SystemsTraceAuditNumber;
SET OutputLocalEnvironment.MRM.CardAcceptorTerminalIdentification = '00000000';
SET OutputLocalEnvironment.MRM.CardAcceptorNameLocation = 
    '12345678901234567890123456123456789012eg'; 
SET OutputLocalEnvironment.MRM.CurrencyCodeTransaction = '818'; 
SET OutputLocalEnvironment.MRM.PersonalIdentificationNumberData = 
    Environment.Variables.CIB.HSMResponse.MRM.PINBlock;
SET BlobBitstream = ASBITSTREAM(OutputLocalEnvironment.MRM OPTIONS options 
    SET 'ISO_ATM_HSM_MsgSt' 
    TYPE 'ISO8583Message_64_Write' 
    FORMAT 'Text1');
SET BlobBitstream = SUBSTRING(BlobBitstream FROM 65);

Работа с IST/Switch

По аналогии с HSM запросите определение специального заголовка ISO 8583 у владельца IST/Switch. В нашем случае это четыре байта, представляющих собой длину в символах всего ответного сообщения.

Основным показателем успешного взаимодействия ISO 8583 является корректность значений битовой карты, которые должны соответствовать допустимым элементам сообщения. Это условие корректного синтаксического анализа на принимающей стороне. Для этой цели была разработана электронная таблица, автоматически преобразующая выбранные поля в шестнадцатеричную битовую карту из 16 символов для передающей стороны. Для принимающей стороны она преобразует шестнадцатеричные значения битовой карты, активируя соответствующие элементы из числа 128 элементов (в случае основной и дополнительной битовых карт) для использования при просмотре проанализированного сообщения во время разработки. Такая методика уменьшает вероятность отправки или анализа некорректных значений битовой карты на этапе исследования.

Для этапа эксплуатации в дополнение к синтаксическому анализу принятого сообщения важно разработать ESQL-код автоматизации генерирования битовых карт и ISO-запроса. В нашем случае этот код использует в качестве входных параметров индексы ISO-элементов запроса и их общую длину и генерирует соответствующую двоичную битовую карту и весь запрос в правильном формате. В листинге 3 приведена часть кода, относящаяся к сообщению запроса. Функция CreateBitMaps() создает дерево битовой карты из 64 элементов типа integer и элемент двоичной 64-разрядной битовой карты, используя индексы ISO-элементов, помещаемых в запрос.

Основной частью этого процесса является повторно используемый актив IBM, содержащий набор сообщений одной битовой карты (64 элемента сообщения). Этот набор сообщений используется при синтаксическом анализе принимаемых 64-элементных сообщений ISO 8583. Его достаточно для любого приложения, где ответы ATM-системы не будут превышать первичную битовую карту во дополнительной. В противном случае нужно использовать расширенную версию набора сообщений, содержащую две битовые карты и 128-элементное сообщение. Подробная информация о 128 элементах сообщения ISO 8583 приведена в документе Элементы данных ISO 8583 (EN).

Для отправки сообщений ISO 8583 необходимо добавить к набору сообщений еще одно сообщение. В его начале должны находиться элементы первичной (из 64 элементов типа integer) и дополнительной битовых карт, чтобы часть сообщения с потоком битов можно было легко удалить перед отправкой), поскольку они используются только как ссылки на число появлений элементов сообщения в момент создания (последнее выражение в листинге 3 удаляет эту часть). За двумя этими элементами следует собственно сообщение, которое будет отправляться в IST/Switch (см. рисунок 4).

  • Четырехсимвольный заголовок, содержащий длину всего сообщения – MsgLen.
  • MTI-идентификатор (0200 в данном случае).
  • Двоичная битовая карта, отражающая наличие различных элементов в сообщении.
  • Элементы ISO-сообщения.
Рисунок 4. Модель сообщения ISO 8583 для написания ISO-запроса
Рисунок 4. Модель сообщения ISO 8583 для написания ISO-запроса

Использование типа сообщений ISO 8583 с двойной битовой картой (128 полей сообщения) для синтаксического анализа ответного сообщения будет некорректным. Дело в том, что MRM-анализатор не может вычислить количество появлений для элементов, относящихся к дополнительной битовой карте, поскольку оно зависит от соответствующего битового значения битовой карты, а сама битовая карта (дополнительная) имеет нулевое число появлений (отключена). Решением этой проблемы является использование типа сообщений из 64 полей для анализа принимаемых сообщений с одной битовой картой и типа из 128 полей для анализа сообщений с двойной битовой картой (см. динамический выбор типа сообщения в листинге 4).

В листинге 3 функция stretchBitMap проверяет каждый бит в двоичной битовой карте, принятой из IST/Switch, и заполняет значение соответствующего элемента integer комплексного типа данных битовой карты сообщения, где каждый элемент integer этого локального объекта битовой карты соответствует биту двоичной битовой карты. Это отображение двоичной битовой карты на элементы integer позволяет использовать их как ссылки на число появлений элементов сообщения.

Листинг 4. Код синтаксического анализа ответа IST/Switch ISO 8583
CREATE LASTCHILD OF OutputLocalEnvironment DOMAIN ('MRM');
DECLARE rTargetMrm REFERENCE TO OutputLocalEnvironment.MRM;
SET BlobBitstream = stretchBitMap(rTargetMrm, BitmapBit, 'PrimaryBitmapS');
DECLARE MsgType CHAR 'ISO8583Message_64'; -- 64-элементное сообщение
IF OutputLocalEnvironment.MRM.Bit1 = 1 THEN -- Если разрешена дополнительная битовая карта
    SET MsgType = 'ISO8583Message_128';    -- 128-элементное сообщение
    SET readLen =16; 
    SET tmpMap = CAST(CAST(SUBSTRING(InMessageBlob FROM readIndx FOR readLen) 
        AS CHAR CCSID 1208) AS BLOB);
    SET readIndx = readIndx + readLen;
    SET BitmapBit = CAST(tmpMap AS BIT);
    SET OutputLocalEnvironment.MRM = NULL;
    CREATE LASTCHILD OF OutputLocalEnvironment DOMAIN('MRM');
    DECLARE rTargetMrm REFERENCE TO OutputLocalEnvironment.MRM;
    SET BlobBitstream = BlobBitstream || stretchBitMap(rTargetMrm, BitmapBit, 
        'SecondaryBitmapS');
END IF;
SET BlobBitstream = BlobBitstream || SUBSTRING(InMessageBlob FROM readIndx);
CREATE LASTCHILD OF Environment DOMAIN('MRM') PARSE(BlobBitstream 
    SET 'ISO_ATM_HSM_MsgSt'  
    TYPE MsgType
    FORMAT 'Text1');

Заключение

В статье рассматривались защищенные ATM-системы обработки банковских дебетовых карт с точки зрения бизнес-интеграции и было продемонстрировано использование мощных возможностей Message Broker для создания защищенных ATM-систем путем интеграции систем HSM и IST/Switch. Были рассмотрены важные потоки сообщений Message Broker, относящиеся к коду интеграции, а также важные фрагменты соответствующего ESQL-кода. Также в статье были упомянуты передовые методики, основанные на практическом опыте, помогающие разработчикам процессов интеграции, техническим руководителям, проектировщикам и бизнес-аналитикам, принимающим участие в интеграции аналогичных защищенных ATM-систем, избегать потенциальных проблем.

Ресурсы

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


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

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



При первом входе в developerWorks для Вас будет создан профиль и Вам нужно будет выбрать Отображаемое имя. Оно будет выводиться рядом с контентом, опубликованным Вами в developerWorks.

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=WebSphere
ArticleID=846585
ArticleTitle=Интеграция защищенных банковских ATM-систем с использованием WebSphere Message Broker
publish-date=11202012