Что день грядущий нам готовит? (Часть II)

Продолжая анализ важнейших тенденций в мире банковских микропроцессорных карт в 2005 году, начатый в предыдущем номере нашего журнала (см. “ПЛАС” № 2/2006), мы предлагаем вашему вниманию вторую часть статьи Игоря Голдовского “Что день грядущий нам готовит”. Как вы помните, в первой части материала рассматривались вопросы развития бесконтактных платежных технологий. В этот раз речь пойдет о таких не менее значимых событиях, как появление в конце 2005 г. спецификаций Common Payment Application (CPA), разработка EMVCo единой процедуры тестирования приложения карты (EMVCo Type Approval Process for Card Application) и единых процедур оценки безопасности карт стандарта EMV – EMV Security Evaluation Process, а также о работах, ведущихся в направлении создания новой многоприкладной и многозадачной операционной системы Java Card 3.

Одним из ключевых событий 2005 г. стало появление в декабре спецификаций Common Payment Application (CPA), разработанных EMVCo вслед за выпущенными ранее (в рамках стандарта EMV версии 4.1) спецификациями Common Core Definitions (CCD).

На рисунке 1 показаны основные объекты формализации отраслевого стандарта (EMV) и приложений платежных систем. При этом стандартом EMV определены: a) Карта и ее характеристики: физические (механические и электрические) характеристики карты; файловая структура карты, минимальный набор “чиповых” элементов данных карты; протокол персонализации карты (EMV Card Personalization Specification). b) Терминал и его характеристики: физические характеристики терминала; процедура выбора приложения; процедура аутентификации карты/приложения; процедура верификации держателя карты; процедура скрипт-процессинга; процедура управления рисками на стороне терминала. c) Интерфейс “карта-терминал” / “карта-эмитент” и его характеристики: процедура инициализации карты и коммуникационный протокол обмена данными между картой и терминалом; поток сообщений/команд и механизмы обеспечения безопасности обмена данными между картой и терминалом; поток сообщений, механизмы обеспечения безопасности обмена данными, команды в интерфейсе “карта-эмитент”. d) Обмен данными между эквайером и эмитентом: набор объектов данных (chip related data), передаваемых через сеть от банка-эквайера банку-эмитенту карты (авторизация и клиринг).

Стандарт EMV определяет ряд функций в качестве опциональных. В широких пределах может варьироваться формат и содержание многих специфицированных в стандарте элементов данных. Кроме того, стандартом EMV никак не определены процедуры управления рисками, реализованные на карте (процедуры принятия картой решения по способу завершения операции), изменения в интерфейсе банка с платежной сетью, связанные с передачей чиповых данных. Эти процедуры, а также выбор обязательных функций и формата/структуры отдельных элементов данных задаются спецификациями платежных систем, которые в общем случае дополнительно определяют: a) Карта и ее характеристики: процедуры управления рисками, реализованные на карте; алгоритм анализа результатов процедуры управления рисками; дополнения к спецификациям EMV Card Personalization Specification. b) Терминал и его характеристики: параметры для анализа результатов процедуры управления рисками на терминале (элемент данных Terminal Verification Results). c) Интерфейс “карта-терминал”/ “карта-хост” и его характеристики: список обязательных функций, определенных в EMV в качестве опциональных, на стороне терминала и карты; формат чиповых данных. d) Обмен данными между эквайером и эмитентом: протокол работы (интерфейс) банка с сетью. Из всего вышесказанного становится понятно, что в результате спецификации платежных систем (в MasterCard International – M/Chip, в Visa International – VIS), несмотря на их EMV-совместимость, могут иметь (и имеют) целый ряд различий в наборе используемых чиповых данных, их формате, формате команд и ответов на команды, в наборе используемых команд, в процедурах управления рисками и т.п. Как следствие, банки-члены MasterCard International и Visa International вынуждены для каждой платежной системы использовать:

Читайте также:

Инкассаторам нужен пакет услуг — мнение экспертов

• различные приложения на карте;

• различные приложения на терминалах;

• различные авторизационные процессы на хосте эмитента, включая различные процедуры управления рисками;

• различные сетевые интерфейсы на хостах банка-эмитента и банка-эквайера;

• различные процедуры персонализации карт.

На этом фоне, учитывая запросы своих банков-членов, Visa International и MasterCard International несколько лет назад начали процесс совместного обсуждения данной проблемы, достигнув в ходе него ряда принципиальных договоренностей в рамках EMVCo.

Как результат – EMVCo в середине 2005 г. выпустила проект стандарта, а в конце 2005 г. утвердила спецификации для единого стандарта на чиповое платежное приложение – Common Payment Application (CPA).

Ранее, в 2004г., EMVCo в рамках версии 4.1 стандарта EMV выпустила набор новых спецификаций, получивших название Common Core Definition (CCD). Спецификации CCD задают набор определений элементов данных и процессов, используемых при “диалоге” между картой и хостом эмитента. Как уже отмечалось, CCD – составная часть EMV v.4.1. В свою очередь, спецификации CPA определяют единое (признанное MasterCard International, Visa International и JCB International) CCD-совместимое приложение. Приложение CPA использует общий набор элементов данных и команд, определяет единую функциональность карты, включая процедуры управления рисками, и единые правила персонализации карт. Оно является опциональным для банков. Это означает, что каждый банк имеет возможность в рамках своего участия в конкретной платежной системе использовать как уникальное приложение этой системы (M/Chip 4 в MasterCard International или VIS 1.4 в Visa International), так и универсальное приложение CPA. Возможен вариант, когда банк даже в рамках одного BIN использует как карты с приложением платежной системы, соответствующей данному BIN, так и карты с приложением CPA. Для того чтобы объективно оценить те новые возможности, которые открываются для банков с появлением единого платежного приложения, вначале кратко остановимся на различиях между приложением CPA и приложениями платежных систем M/Chip 4 и VIS 1.4.

Card Verification Results. Card Verification Results (CVR) – важнейший элемент данных, в котором хранятся результаты выполнения картой процедуры управления рисками. На основе этих данных карта (точнее – ее эмитент) принимает решение о способе завершения операции. В VIS 1.4 размер CVR равен 4 байтам, включая байт-индикатор длины блока данных (‘03’h), хранящих результаты выполнения процедуры управления рисками. В M/Chip 4 размер CVR равен 6 байтам. Единый формат объекта данных CVR – необходимое условие для унификации процедуры принятия картой решения. Такой формат определен в CCD. В соответствии с CCD размер CVR равен 5 байтам (последний байт зарезервирован для использования).

Issuer Application Data. Объект Issuer Application Data (IAD) является важным объектом данных, используемым для передачи информации от карты эмитенту, необходимой эмитенту для принятия решения о способе завершения операции. В соответствии с CCD объект IAD имеет размер ровно 32 байта (по EMV не бомы ARQC в рамках VIS1.4 /M/Chip 4 и CCD. Разница состоит в том, что в приложении CPA вместо элемента CVR используется элемент IAD, содержащий CVR.

В остальном алгоритм вычисления криптограммы в CCD остался прежним. Изменения коснулись только алгоритма формирования мастер-ключа карты со значением PAN более 16 цифр. Следует также отметить, что алгоритм вычисления древа ключей, введенный в EMV v.4.1 и ранее использовавшийся Visa International в спецификациях VIS 1.4 (формат криптограммы “Cryptogram 14”) и в спецификациях CCD, более в стандарте EMV не используется. Ему на смену пришел другой алгоритм (криптограмма версии 5), который совпадает с первым в стандарте EMV алгоритмом вычисления сессионного ключа для вывода криптограммы по номеру транзакции Application Transaction Counter и случайному числу Unpredictable Number с той лишь разницей, что в новом алгоритме значение Unpredictable Number равно “0”. Криптограмма ARPC. Криптограмма ARPC считается с помощью алгоритма 3 ISO 9797-1 вычисления MAC, примененного к последовательности Z=ARQC||CSU. В качестве криптограммы используются 4 крайних “левых” байта полученного результата. В спецификациях VIS и M/Chip используется алгоритм:

• ARC (Authorization Response Code) дополняется справа 6-ю нулевыми байтами: X:=(ARС||‘00’||‘00’||‘00’||‘00’||‘00’||‘00’);

• D:=ARQCX;

• ARPC:=DES3(SKAC)[D], т. е. к D применяется алгоритм Triple DES на сессионном ключе вывода криптограммы SKAC.

При этом Issuer Authentication Data имеет вид ARPC||ARC, т.е. размер этого элемента данных равен ровно 10-ти байтам. Issuer Authentication Data. В спецификациях CCD элемент Issuer Authentication Data имеет вид ARPC||CSU и размер 8 байтов (в CDOL2 содержится обязательный элемент Tag “91” размером 8 байтов). Эмитент может передавать карте величину Issuer Authentication Data размером 8–10 байтов (например, в VIS 1.4). В этом случае терминал сам “обрежет” “крайние правые” байты, отправив карте в команде Generate AC только 8 оставшихся “крайних левых” байтов.

Для передачи Issuer Authentication Data от терминала карте в спецификациях VIS используется команда External Authenticate, а в M/Chip 4 – команда Generate AC. В CCD в этих целях используется команда Generate AC.

Формат команд Secure Messaging. В спецификациях CCD требуется, чтобы все команды эмитента, использующие Secure Messaging, имели Формат 1 (поле данных команды представлено в формате TLV). В VIS используется Формат 2, в M/Chip – Формат 1.

Формат ответов на команды. В спецификациях CCD в ответах карты на команды требуется поддержка Формата 2 (поле данных ответа на команду представлено в формате TLV). В M/Chip поддерживается Формат 2, в VIS используется Формат 1 за исключением случая второй команды Generate AC при использовании технологии аутентификации CDA (Combined Dynamic Authentication), когда используется Формат 2.

Алгоритм формирования сессионных ключей. Как уже ранее отмечалось, криптограмма версии 4 (Cryptogram 14 в терминологии Visa International) исключена из стандарта EMV 4.1 (поддерживалась в VIS 1.4). Вместо нее появилась криптограмма версии 5, позволяющая получать сессионный ключ только по значению ATC (по аналогии с криптограммой версии 4 или в терминологии Visa International – Cryptogram 14).

Алгоритм вывода ключа карты по ключу эмитента при PAN>16. В приложении CPA в соответствии с CCD и EMV v.4.1 для вывода ключа карты по номеру карты используется предварительное хэширование значения PAN с помощью алгоритма SHA-1 с дальнейшей децимилизацией полученного результата.

Terminal velocity checking. В приложении CPA не поддерживается процедура проверки офлайновых лимитов (Terminal velocity checking) терминалом. В соответствии с CCD карта не должна передавать терминалу объекты Lower Consecutive Offline Limit (Tag ‘9F14’) и Upper Consecutive Offline Limit (Tag ‘9F23’).

Если в VIS 1.4 нет проблем с выполнением последнего требования, то в рамках M/Chip это не так: указанные выше объекты данных доступны терминалу, но терминал не может получить от карты значения ATC и LATC, что делает невозможным выполнение процедуры Terminal velocity checking.

Процедура Script Processing. В соответствии с CCD эмитент может передавать карте только один блок команд Issuer Script Template (размер блока менее 128 байтов). При этом приложение CPA поддерживает критичный и некритичный Script Processing (по аналогии с M/Chip 4, в VIS 1.4 поддерживается только некритичный Script Processing). лее 32 байтов).  На рисунке 2 используются следующие новые сокращения:

• CCI (Common Core Identifier) – элемент данных, первый полубайт которого определяет формат IAD, а второй полубайт – версию криптограммы. В настоящее время элемент CCI может принимать единственное значение ’A5’h;

• DKI (Derived Key Identifier) – элемент данных, определяющий идентификатор ключа эмитента, используемого для генерации мастер-ключа карты, с помощью которого вычисляется сессионный ключ вывода криптограммы;

• IDD (Issuer Discretionary Data) – набор значений данных, которые, по мнению эмитента, ему необходимы для принятия решения по завершении операции.

Список данных, значения которых составляют содержание IDD, определяется эмитентом карты. В IDD могут входить Terminal Verification Results (TVR), ICC Dynamic Number (IDN), Data Authentication Code (DAC), Issuer Script Results (результаты выполнения процедуры скрипт-процессинга), CVM Results (результаты выполнения процедуры верификации держателя карты) идр. В спецификациях VIS объект данных Issuer Application Data имеет вид. К VISA Discretionary Data относятся CVN (Cryptogram Version Number, 1 байт), DKI (Derivation Key Indicator, 1 байт) и CVR (4 байта).

Объект IAD является для эмитента карты идентификатором того обстоятельства, что используемое для выполнения операции приложение карты является CPA. Используемое приложение является CPA тогда и только тогда, когда первый и семнадцатый байты поля данных объекта IAD равны ‘0F’h, а размер поля данных составляет 32 байта.

Card Status Update. Объект Card Status Update появился как развитие элемента ARPC Response Code, используемого в спецификациях M/Chip 4, и имеет размер 4 байта. Структура двух первых байтов представлена на рис. 4 (остальные байты зарезервированы или выделены под данные, определенные эмитентом). Принятие картой решения о способе завершения операции осуществляется на основе данных CVR. При этом критерии принятия решения оформляются в M/Chip 4 и VIS 1.4 различными способами. В M/Chip 4 используются объекты Card Issuer Action Code (CIAC), в VIS – объект Application Default Action (ADA, размером 2 байта). В картах с приложением CPA выбрана модель CIAC.

• Application Interchange Profile/Application File Locator;

• CIAC; 

• счетчики (количество последовательных офлайновых операций, аккумуляторные счетчики, циклические аккумуляторные счетчики);

• специальные опции эмитента (логирование операций, счетчик максимального количества дней, прошедших с момента совершения последней офлайновой операции, и т. п.).

Криптограмма ARQC демонстрирует разницу между данными, используемыми при вычислении криптограмCard International для передачи чиповых данных от банка-участника в сеть и назад из сети в банк в сообщении Interchange используется поле DE 55, в котором размещены все необходимые чиповые данные в кодировке TLV. Минусом такого подхода является увеличение длины сообщения, связанное с избыточностью кодировки TLV. Очевидный плюс использования поля DE 55 – простота реализации обмена данными и обработки сетевых сообщений. В сети VisaNet для размещения чиповых данных используется третья карта: поля 129–192 сообщения Interchange, из которых стандарт VIS использует поля 130–149. Отметим, что это делается вопреки стандарту ISO 8583, допускающему использование только двух карт (сообщения содержат до 128 полей). В рамках стандарта CCD требуется применение поля DE 55. К 1 апреля 2008 г. все банки-эквайеры (а значит, и банки-эмитенты) Visa International в регионе CEMEA должны перейти на использование поля DE 55.

Уточнения, не требующие изменений в приложениях VIS и M/Chip. Ниже перечислены уточнения, принятые в приложении CPA и не требующие изменений в алгоритмах приложений VIS 1.4 и M/Chip 4: • если на CCD-карте поддерживается директория Payment System Environment (PSE), то она представляет собой единственный DDF-файл на карте. При этом поддерживается выбор приложения по укороченному имени директории приложения карты (выбор приложения по не менее чем 5-ти старшим байтам DF Name и поддержка индикатора Next в команде Select);

• фиксированы значения 3-го и 5-го битов первого байта объекта AIP: bit3=0, т. е. для аутентификации эмитента используется вторая команда Generate AC; bit5=1, т. е. карта поддерживает верификацию своего держателя;

• в элементе данных Cryptogram Information Data (CID), содержащемся в ответе карты на команду Generate AC, указывается на факт отсутствия поддержки сообщения уведомления (advice message) – карта не может передать эмитенту уведомление. С появлением спецификаций CPA впервые появилась возможность разработки единой процедуры тестирования приложения карты. EMVCo взяла обязательства выпустить спецификации EMVCo Type Approval Process for Card Application (2006г.) до конца 2006г. Появление данных спецификаций значительно упростит жизнь производителям карт.

Еще одно важное направление работы компании EMVCo в нынешнем 2006 году – разработка единых процедур оценки безопасности карт стандарта EMV – EMV Security Evaluation Process. Разрабатываемые процедуры гарантируют выполнение картой требований EMVCo к безопасности карточных EMV-продуктов. Процедуры оценки безопасности станут едиными в мировой платежной индустрии и позволят производителям карт избежать необходимости прохождения сертификаций в различных лабораториях для того, чтобы выполнить требования безопасности различных платежных систем. Таким образом, EMVCo станет единым центром сертификации всех карточных продуктов с точки зрения их безопасности, и эти результаты сертификации будут признаваться платежными системами MasterCard International, Visa International и JCB International. Процедуры сертификации могут использовать некоторые результаты тестирования, полученные из альтернативных схем оценки безопасности карточных продуктов, например, в соответствии со стандартом Common Criteria.

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

• решение проблемы слабых телекоммуникационных возможностей смарт-карты, связанных с поддержкой не менявшихся уже в течение более 15 лет низкоскоростных полудуплексных асинхронных протоколов связи;

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

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

В основе большинства таких проектов лежит концепция создания сетевой карты, которая подразумевает реализацию на карте стэка современных сетевых протоколов общего пользования. Это сделает возможным непосредственное общение карты с серверами и персональными компьютерами, подключенными к сети. Говоря о стэке протоколов, речь идет в первую очередь о протоколах TCP/IP и других Интернет-протоколах. При этом два крупнейших мировых поставщика карт – Gemplus и Axalto – обещали выпуск такой сетевой карты уже в самое ближайшее время. Однако, вероятно, самая значимая работа в этом направлении сейчас ведется компанией Sun Microsystems в рамках Java Card Forum. Результатом этого проекта должен стать выпуск карты нового поколения к 2007г. Данная карта получила название Java Card 3, поскольку она явится развитием сегодняшнего стандарта Java Card 2.2, принятого Sun Microsystems в 2002г. Иногда ее называют также Java Card.Net, для того чтобы подчеркнуть сетевой характер этой карты.

Карта Java Card 3 сможет одновременно исполнять несколько приложений и использоваться в персональных компьютерах и сотовых телефонах без какого-либо дополнительного приложения на этих устройствах. С помощью такой карты ее держатель сможет, например, одновременно загружать игру на свой сотовый телефон и оплачивать эту игру, оставляя голосовой канал телефона свободным. При использовании карты Java Card 3 в качестве SIM-карты ее держатель сможет устанавливать безопасное подключение к ресурсу Интернета, значительно расширяя возможности инструментария SIM Toolkit и идя гораздо дальше него в этом направлении.

Пользователь Интернета, применяя карту Java Card 3, сможет связать карту непосредственно с сервером торговой точки, используя свой персональный компьютер лишь в качестве терминала, имеющего клавиатуру для ввода команд, и модем либо сетевую карту для организации физического соединения с сервером. Это станет возможным благодаря поддержке Java Card 3 протокола TCP/IP и других интернетовских протоколов. Концепция сетевой карты в значительной степени решает и еще одну важную проблему. Несмотря на появление открытых платформ, к которым относится, например, операционная система Java Card, многомиллионная армия программистов до сих пор не подключилась к написанию приложений для смарт-карт. В значительной степени это связано с тем, что для написания таких приложений нужно иметь достаточное представление об используемых в смарт-картах коммуникационных протоколах. Поскольку знание этих протоколов весьма ограничено даже в программистской среде, сегодня главными разработчиками приложений для смарт-карт остаются их поставщики. С внедрением на картах широко известных открытых протоколов, например, TCP/IP, в значительной степени удастся решить упомянутую проблему. Специфика написания программ для смарт-карт, обусловленная небольшими объемами памяти RAM, конечно, остается, но это уже больше вопрос искусности программиста, чем наличия у него узкоспециализированных знаний и навыков. Растущая потребность в одновременном исполнении смарт-картой нескольких приложений исходит главным образом из телекоммуникационного сектора. Использование SIM-карты для предоставления дополнительных услуг владельцу сотового телефона иногда приводит к конфликту при исполнении базовой функции SIM-карты – аутентификации держателя карты. Например, в момент загрузки владельцем телефона звукового сопровождения входящего звонка с помощью меню SIM Toolkit может случиться так, что сеть “захочет” повторно аутентифицировать владельца телефона, как, собственно, это периодически и происходит. В таком случае телефон может терять соединение с сетью. Очевидно, многозадачность предъявляет повышенные требования к памяти RAM. Поэтому вопрос значительного увеличения объемов RAM при внедрении концепции сетевой карты является важнейшим. Эксперты определили, что только для поддержки протокола TCP/IP и протокола сетевой безопасности SSL, широко используемого в Интернете, а также высокоскоростного USB-интерфейса потребуется около 6 Кб памяти RAM. Всего же для реализации концепции сетевой карты, по их мнению, понадобится как минимум 16 Кб памяти RAM. При этом некоторые эксперты говорят о необходимости иметь 24, 32 и даже 64 Кб RAM.

Повышенные требования предъявляются и к памяти ROM. Это связано с очевидной необходимостью обеспечить обратную совместимость (backward compatibility) карты Java Card 3 с версией Java Card 2.2 (любое приложение, написанное для карты Java Card 2.2, должно работать на карте Java Card 3). Данное требование фактически приведет к удвоению памяти ROM, поскольку в ней придется держать расширенную версию операционной системы карты плюс все программные интерфейсы API, написанные для обеих версий операционной системы.

Увеличение памяти RAM и ROM связывается главным образом с внедрением новых технологий изготовления микросхем. Уже говорилось о том, что внедрение проектной нормы 0,13 мкм позволяет увеличить память RAM микросхемы до 16 Кб. Сейчас производители микросхем ведут активные работы по внедрению технологий с использованием меньших проектных норм. Ожидается, что в будущем году появятся микросхемы, выпущенные с использованием проектных норм 0,10 мкм, а к 2009г. производители чипов научатся изготавливать микросхемы с использованием проектной нормы 0,07 мкм! Следует отметить, что компания Sun Microsystems является противником быстрого внедрения карты Java Card 3, считая, что слишком поспешное внедрение этой версии операционной системы может привести к конфликтам, связанным с отсутствием надежной обратной совместимости для приложений, написанных для Java Card 2.2.

Другим ожидаемым противником сетевой карты является банковское сообщество, которое по вполне очевидным причинам традиционно выступает против частой смены версий ОС Java Card. Сейчас банки используют приложения, функционирующие под управлением предыдущих версий операционной системы, – Java Card 2.1 и Java Card 2.2. Эти приложения прошли процесс трудоемкой и дорогостоящей сертификации, определенной MasterCard International и Visa International. C появлением очередной новой версии ОС придется заново проходить процесс сертификации применяемых банками приложений на новой платформе. Это стоит и средств, и времени. А главное – сегодня банки не ощущают острой потребности в концепции сетевой карты. Сегодняшнее зависимое положение карты от терминала их вполне устраивает.

Сегодня мы все еще находимся в самом начале процесса освоения новых смарткарточных технологий. Микропроцессорная карта становится универсальным, безопасным и мобильным аппаратно-программным средством, с помощью которого решается самый широкий спектр задач человеческой деятельности: идентификация/аутентификация владельца сотового телефона, проведение безналичных платежей, в том числе в рамках так называемой универсальной коммерции (U-commerce), реализация масштабных идентификационных/аутентификационных программ, включая электронные паспорта, создание инфраструктуры PKI, развитие различных социальных программ и т. п. В течение последних 15 лет чиповые карты с технологической точки зрения развивались очень медленно. В то же время возникновение новых бизнес-задач наряду с успехами в технологиях изготовления микросхем в последнее время привели к появлению новых видов чиповых карт и проектов по их дальнейшему развитию. Бесконтактные карты, сетевые карты, стандартизация приложений – лишь яркие примеры развития технологии чиповых карт, о которых автору хотелось рассказать в рамках данной статьи.

Игорь Голдовский, генеральный директор ЗАО “Платежные технологии”

Текст статьи читайте в журнале ПЛАС №3 за 2006 год