Последнее время все больше и больше банковских карт содержат на себе не только магнитную полосу, но и микропроцессор. Чиповые карты международных платежных систем (VISA, MasterCard, JCB) соответствуют единому стандарту - EMV. EMV спецификации построены на основе стандарта ISO-7816. Поэтому с помощью любой программы, позволяющей работать с картой напрямую через PC/SC-устройство, можно исследовать и даже модифицировать данные карты.

Среди всех EMV карт выделим те, информацию с которых действительно интересно прочитать. В частности, в этой статье мы разберемся как получить OFF-LINE баланс и журнал операций карт MasterCard Maestro MPAD (MasterCard Preauthorized Debit). Примечательно то, что для выполнения этих операций Вам не нужно будет вводить ПИН-код, как того требуют банкоматы или торговые терминалы.

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

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

Спецификации стандарта EMV открыты и доступны по ссылке http://www.emvco.com/cgi_bin/0200_specifications.pl. Их объем слишком велик, а уровень изложения достаточно сложен для неподготовленного читателя .

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

Персонализированная EMV-карта выполняет следующие команды, не требующие знания какой-либо ключевой информации:

Команда Cla Ins Примечание GENERATE APPLICATION CRYPTOGRAM 0x80 0xAE Получение криптограммы аутентификации (для OFF-LINE операций - аналог дебетования электронного кошелька) GET CHALLENGE 0x00 0x84 Получение случайного числа GET DATA 0x80 0xCA Предоставление определенных данных приложения (перечень данных зависит от приложения и постоянно расширяется) GET PROCESSING OPTIONS 0x80 0xA8 Начало платежной операции, получение от приложения карты управляющей информации READ RECORD 0x00 0xB2 Чтение записи из файла SELECT 0x00 0xA4 Выбор приложения VERIFY 0x00 0x20 Проверка ПИН-кода

EMV спецификации определяют минимальные и максимальные требования к EMV карте, необходимые и достаточные для ее обслуживания в EMV терминале. Несмотря на то, что каждая EMV-карта поддерживает перечисленные команды, реализации этих команд на разных картах могут отличаться друг от друга. Различия обусловлены аппаратными возможностями микропроцессора карты и представлениями банка-эмитента карты о том, как данная карта должна использоваться. Опции карты, которые эмитент предполагает использовать, задаются при ее персонализации. На самой карте эта информация представляется в виде файлов, содержащих данные в BER TLV формате (формат определен в ISO 8825).

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

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

Наиболее активно, в рамках инициативы MasterCard OneSmart Club, предлагает свое решение для преавторизованного дебета платежная система MasterCard, поэтому вероятность что у вас в руках окажется именно карта MPAD (Mastercard PreAuthorized Debit) больше. Ею и займемся. Как уже было сказано выше, EMV карты задумывались в первую очередь как идентификатор доступа к банковскому счету, более защищенный, чем карта с магнитной полосой. По этой причине реализация преавторизованного дебета на EMV картах обладает рядом недостатков. В этой статье мы рассмотрим и воспользуемся одним из них.

Разработчики EMV спецификаций не предусмотрели возможности закрытия доступа к той или иной информации на карте по предъявлению ПИН-кода держателем карты. Таким образом, все данные, которые карта позволяет прочитать терминалу, предоставляются без предъявления ПИН. В том числе и OFF-LINE баланс, и журнал операций. Хотя в терминале или в банкомате Вас просят ввести ПИН-код для просмотра OFF-LINE баланса и даже проверяют этот ПИН-код, ниже мы убедимся, что сама карта готова отдать этот Ваш маленький секрет "практически даром".

Спецификации EMV предполагают автоматическую обработку ответов карты со статус байтами 61XX и 6CXX аппаратным EMV Terminal Transport Layer. Найти PC/SC-картридер, реализующих в себе подобную возможность, автору пока не удалось. Поэтому в дальнейшем будем исходить из предположения, что Вы используете обычный, совместимый с ISO 7816 ридер смарт-карт. В этом случае нам потребуется самим "забирать" ответ карты при получении статус байтов 61XX или 6CXX. В первом случае это реализуется командой GET RESPONSE (хотя формально ее и нет в списке команд EMV-карты, но реальными картами она поддерживается), во втором случае - повторным выполнением команды с указанием увеличенного размера буфера для ответа.

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

TLV - это аббревиатура словосочетания Tag Length Value. Каждая единица информации определяется своим тегом. Непосредственно за тегом указывается длина данных, а сразу за полем длины идет информационная часть. В рамках взаимодействия с картой нам будут попадаться однобайтные и двухбайтные теги. Отличить второй байт тега от поля длины можно по первому байту тега - если младшие пять бит первого байт тега установлены в 1 (он как бы заканчивается на 0x1F), то следующий байт является продолжением тега, а не длиной данных. Длина данных объекта у нас всегда будет помещаться в один байт.

Необходимо также упомянуть о составных TLV объектах (иначе - template или шаблон). Составные объекты содержат не данные, а простые TLV объекты. В первом байте тега составного TLV объекта установлен бит 00100000. Уровень вложенности составных объектов не ограничен.

Итак, запускаем программу, позволяющую работать с картой на уровне команд APDU, например Smart Card ToolSet PRO, вставляем карту в устройство и проверяем, включилась ли карта и вернула ли ATR.

Убеждаемся в том, что это действительно карта с приложением MPAD

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

Cla Ins P1 P2 P3/Lc Le Data In 00 A4 04 00 07 A0 00 00 00 04 30 60

В ответ мы должны получить статус байты 61 XX (от "настоящих" EMV картридеров возможно сразу получить данные о приложении со статусом 90 00, в этом случае следующий шаг делать не надо). В качестве статус байтов карта также может вернуть 6A XX. Не вдаваясь в подробности, это означает что с этой картой ничего нижеследующего сделать не получится.

Для обычных ридеров потребуется дополнительное усилие для получения ответа карты (команда GET RESPONSE).

Cla Ins P1 P2 P3/Lc Le Data Out 00 C0 00 00 XX 6F 1C 84 07 A0 00 00 00 04 30 60 A5 11 50 07 4D 61 65 73 74 72 6F BF 0C 05 9F 4D 02 0B 14 90 00

Карта вернула нам данные о приложении (так называемый FCI, File Control Information).

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

В FCI нас интересует TLV объект Log Entry с тегом '9F4D'. В качестве тренировки в разборе TLV сообщений, Вы можете убедиться в том, что Log Entry входит в составной TLV-объект с тегом 'BF0C', который в свою очередь входит в шаблон с тегом 'A5', который в свою очеред входит в корневой шаблон с тегом '6F'. Ленивые могут положиться на теорию вероятности, гласящую, что вероятность двухкратного появления последовательности байт '9F4D02' в выходном буфере подобного размера практически равна нулю. Таким образом, ищите '9F4D02' и следующие два байта и есть искомые данные. Мы воспользуемся ими при чтении журнала.

Отсутствие TLV объекта Log Entry в FCI говорит о том, что Ваша карта не хранит журнал операций.

Смотрим баланс карты

В памяти EMV карты содержится структура файлов/каталогов ISO-7816. (MF-DF-EF). Тем не менее, адресация к данным карты осуществляется косвенно - либо использованием команды GET DATA в параметрах которой указывается TLV-тег интересующего нас объекта, либо получением идентификатора файла (SFI, Short File Identifier) в рамках TLV-ответа на одну из других команд карты.

В нашем случае, OFF-LINE баланс предоставляется картой в ответ на команду GET DATA, а журнал операций придется читать из файла (командой READ RECORD). Поскольку, в общем случае, мы не знаем - какого размера ответ вернет карта, то GET DATA выполняем два раза - первый раз для того, чтобы определить размер ответа, а второй, чтобы считать данные.

Делаем:

Cla Ins P1 P2 P3/Lc Le Data Out 80 CA 9F 50 00 6C XX

В ответ мы должны получить либо статус байты 6C XX, либо ошибку 6A XX (скорее всего это будет 6A 88 - требуемые данные не найдены), означающую, что все таки Ваша карта не является MPAD картой.

Повторяем, модифицируя размер ожидаемого ответа:

Cla Ins P1 P2 P3/Lc Le Data Out 80 CA 9F 50 XX 9F 50 06 00 00 00 00 01 00 90 00

Напоминаю, что ответ, который получите Вы, будет другим. Скорее всего, размер ответа будет таким же (т.е. Le будет равно 0C). Но надеюсь, что размер OFF-LINE баланса будет значительно больше :-).

Что же мы получили от карты? Тег '9F50' указывает, что карта действительно вернула нам информацию об OFF-LINE балансе. Размер поля суммы OFF-LINE баланса - 6 байт. Содержание - 000000000100, что в представлении данных n12 означает наличие 100 условных OFF-LINE единиц. Зная валюту счета, понимаем, что это... 1 рубль или гривня или евро.

Смотрим журнал операций

Чтение журнала операций возможно в случае, если в ответе на команду SELECT (см. раздел "Убеждаемся в том, что это действительно карта с приложением MPAD") есть тег '9F4D' (Log Entry). В этом TLV объекте хранится информация об SFI файла журнала (в старшем байте данных) и числе записей в журнале (в младшем байте). Помимо этого, нам потребуется информация о формате записи в файле-журнале. Формат запрашиваем с помощью уже известной GET DATA:

Cla Ins P1 P2 P3/Lc Le Data Out 80 CA 9F 4F 00 6C XX

В ответ мы должны получить статус байты 6C XX.

Повторяем, модифицируя размер ожидаемого ответа:

Cla Ins P1 P2 P3/Lc Le Data Out 80 CA 9F 4F XX 9F 4F … 90 00

Буфер ответа содержит перечень и размер полей в записях журнала. Например ответ карты 9F4F0B9A039F21039F02065F2A02 означает, что формат записей в файле журнала операций таков: ДАТА_3байта + ВРЕМЯ_3байта + СУММА_6байт + ВАЛЮТА_2байта, а общий размер записи - 14 байт.

Как видно из примера, в TLV объекте Log Format ('9F4F') хранится перечень тегов с указанием длин, позволяющий в дальнейшем отформатировать записи журнала.

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

Тег Размер (в байтах) Описание Представление данных 9A 3 Дата операции n6, ГГММДД, т.е. буфер '060113' означает выполнение операции 13 января 2006 года 9F21 3 Время операции n6, ЧЧММСС, т.е. буфер '215005' означает выполнение операции в 21 час 50 минут 5 секунд 9F02 6 Сумма операции n12, в копейках/центах, т.е. буфер '000012345678' означает сумму операции в 123456.78 условных единиц 5F2A 2 Код валюты операции n3, в соответствии с ISO 4217 (например, '0810' - рубль, '0980' - гривня, '0978' - евро) 9F36 2 Счетчик операций приложения (ATC) b, в прямой кодировке, т.е. буфер '010F' означает порядковый номер операции 256 + 15 = 271 9F27 1 Тип криптограммы, возвращенной картой при выполнении операции (CID) b, фактически признак того - выполнялась ли операция в OFF-LINE (0x40) или в ONLINE (0x80), или не прошла вообще (0x00).

Читаем данные из файла журнала на основании ранее полученного SFI с помощью команды READ RECORD. Так как размер записи мы уже вычислили, то и укажем его в качестве Le (в нашем случае Le должен быть 0E).

Cla Ins P1 P2 P3/Lc Le Data Out 00 B2 01 5C XX 06 01 13 21 50 05 00 00 12 34 56 78 09 78 90 00

P2 здесь: SFI << 3 + 0x40 = 5C. Если в ответ на команду, карта вместо данных вернула статус 6C XX - проверьте правильность вычислений размера записи и параметра P2. Продолжаем выдавать команду READ RECORD столько раз - сколько было указано в '9F4D', увеличивая каждый раз параметр P1 на единицу. Записи в журнале отсортированы так, что информация по последним операциям будет предоставлена картой в начале.

Разберем одну из записей журнала в соответствии с указанным в '9F4F' форматом. Как видно, в журнале информация хранится не в TLV формате, а в виде записей фиксированной структуры. Итак, разбиваем буфер на части:

060113
215005
000012345678
0978

Эта запись означает проведение операции на 123456.78 евро в 21 час 50 минут 5 секунд 13 января 2006 года (указывается локальное время терминала).

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

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

Спор о том, где, как и когда впервые была создана система преавторизованного дебета оставим для историков. Но очевидно, что наибольшее развитие подобные системы получили на просторах необъятного СССР. Основной причиной этого являются проблемы с коммуникациями, которые не позволяют использовать западные технологии в чистом виде. Главным требованием для "наших" платежных систем была возможность выполнения платежей без связи с банком (т.е. в режиме OFF-LINE). С другой стороны, карты должны были быть именными, а банковский счет автоматически пополняться заработной платой держателя карты.

Исторически сложилось, что почти все реализации преавторизованного дебета построены с использованием карт GemPlus MPCOS. Перечень этих реализаций приведен http://www.gemplus.ru/ru/fs/index.html. Карты MPCOS безусловно соответствуют стандартам ISO-7816. Но помимо предусмотренных в ISO-7816-4 команд карты, одноименная операционная система карты поддерживает ряд операций с электронным кошельком. К сожалению для энтузиастов смарт-карт, спецификации MPCOS, как и спецификации построенных с ее использованием продуктов, являются закрытыми, поэтому сделать "что-то полезное" с картами Золотой Короны, СБЕРКАРТой и т.п. затруднительно.

Первые спецификации EMV (EuroPay-MasterCard-Visa) увидели свет в 1996 году. Главной причиной их возникновения стал угрожающий рост мошенничества с использованием карт с магнитной полосой. Основной задачей разработчиков спецификаций было обеспечение безопасности платежей на новой для международных платежных систем платформе смарт-карт. Очевидно, что речь шла в первую очередь об использовании приложений типа дебет/кредит, традиционных для данных платежных систем. Со временем выяснилось, что перевод всей инфраструктуры эквайеров на обслуживание смарт-карт и выпуск более дорогих карт эмитентами не окупает снижение уровня мошенничества даже в среднесрочной перспективе. В связи с этим, спецификации EMV расширялись для охвата все больших и больших предметных областей. Так они и добрались до "нашего" преавторизованного дебета и стали preauthorized debit.

Несмотря на то, что спецификации EMV являются общими для MasterCard и Visa, каждая из платежных систем разработала свое приложение на карте для поддержки в том числе и преавторизованного дебета. Сами приложения карты называются соответственно MChip4 и VSDC+. Кроме того, в случае использования преавторизованного дебета этим приложениям присваивается специальный идентификатор (AID, Application Identifier).

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

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

Искренне надеюсь, что в Ваших руках таки оказались одновременно смарт-карта MasterCard Maestro с приложением MPAD, PC/SC-совместимый карт-ридер и эта статья. Как минимум баланс, доступный в OFF-LINE, Вам посмотреть удалось. Если же Вы не поленились и разобрались с журналом операций, честь Вам и хвала! В качестве "самостоятельной работы" Вы можете попробовать предъявить карте незашифрованный OFF-LINE ПИН-код (карта MPAD должна поддерживать подобный режим). В любом случае, теперь с EMV-картами Вы на "ты"!

Область применения EMV карт расширяется с каждым днем. Многие банки Западной Европы, где платежные смарт-карты получили наибольшее распространение, планируют использовать эти же карты для защиты доступа к банковскому счету через Internet (так называемое приложение CAP, Chip Authentication Program). Для бесконтактных платежей так же планируется использовать EMV карты, причем именно в режиме преавторизованного дебета.

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

Удачи Вам!