Суть простейшей статической аутентификации

Выбор приложения (команда Select). Терминал запрашивает карту о том, какие приложения она поддерживает (например, Cirrus и локальное), и, если имеются совпадения с приложениями, которые поддерживает сам терминал, выбирается одно из них.
Запрос терминалом основных сведений о приложении (команда Get Processing Option). Карта выдает основную информацию о приложении (в частности, какую функциональность поддерживает и структуру хранения данных выбранного приложения).
Чтение данных приложения (команда Read Record). На основании информации о структуре файлов с данными, полученными на предыдущем шаге, терминал читает эти данные.
Аутентификация данных (Data Authentication). Терминал в режиме офлайн проверяет, истинны ли данные, прочитанные с карты, и не подвергались ли они ранее подделке или незаконному исправлению. Существуют следующие способы аутентификации: статическая (SDA), динамическая (DDA) и усовершенствование динамической - комбинированная (CDA), являющаяся клоном.
Суть простейшей статической аутентификации заключается в следующем. В процессе выпуска карт банк-эмитент создает пару несимметричных ключей. Публичный ключ отправляется в центр сертификации данной платежной системы, откуда возвращается подписанным секретным ключом системы. Пара - публичный ключ и его сертификат - загружается на карту.

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

Таким образом, последовательно терминал дважды проверяет истинность информации, прочитанной им с карты, - сначала истинность публичного ключа банка, затем истинность данных.
В процессе выполнения динамической аутентификации (DDA) и комбинированной (CDA) используются команды Internal Authentication и Generate Application Cryptogram. Суть используемого алгоритма заключается в том, что данные карты, а также динамические характеристики транзакции (такие, как показатель счетчика транзакций карты и случайное число, выдаваемое в карту терминалом) подписываются секретным RSA-ключом, индивидуальным для каждой карты. В свою очередь парный этому ключу публичный ключ подписывается секретным ключом эмитента (аналогично тому, как в SDA публичный ключ эмитента подписывается секретным ключом платежной системы). Подтвержденного центром доверия (в данном случае это банк-эмитент) знания публичного ключа карты достаточно, чтобы убедиться в правильности криптограммы.

Таким образом, в DDA и CDA по сравнению с ПО SDA возникает как бы третий (дополнительный этап). Если в SDA сначала проверяется истинность публичного ключа эмитента, а затем истинность статических данных, то в рассматриваемых случаях после проверки истинности публичного ключа эмитента убеждаемся в истинности публичного ключа карты, а затем статических и динамических данных карты и терминала.
Проверка ограничений на использование карты (Processing Restrictions). Терминал анализирует полученную ранее от карты информацию и определяет, может ли она быть обслужена в это время, в этом географическом месте, в данной торговой точке (по типу) и т.д.
Проверка полномочий владельца карты (Cardholder Verification). Среди данных, прочитанных с карты, находятся и параметры, определяющие, каким образом осуществляется проверка лица, предъявившего карту. Наряду с известными для случая магнитной карты такими методами, как подпись клиента и проверка ПИН-кода в режиме онлайн, используется также офлайн-проверка ПИН-кода.
Для обеспечения этой процедуры сначала проверяется, не превышен ли лимит неудачных попыток ввода, а затем, если все в порядке, вводится и сам ПИН (команда Verify). При этом существуют два способа ввода - обычный и шифрованный. Во втором случае ПИН шифруется с использованием публичного RSA-ключа карты с использованием случайного выданного картой числа и расшифровывается внутри карты секретным ключом.

При этом возможно использование пары ключей для DDA, а возможно и наличие отдельной пары для ПИН-шифрования.
Понятно, что и DDA, и шифрованный ПИН предъявляют к карте одинаковые требования, а именно, поддержку RSA-шифрования. Таким образом, оба этих функционала связаны - если карта не может поддержать DDA, нечего говорить о шифровании ПИН, и т.д.
Проверка рисков (Terminal Risk Management). Терминал проверяет, не находится ли карта в черном списке, не превышен ли floor limit превышает ли величина транзакции лимит по обслуживанию карты в режиме офлайн, требуется ли обязательно послать онлайн-запрос и т.д.
Принятие терминалом решения о дальнейших действиях (Terminal Action Analysis). На основании приведенных ранее операций (аутентификации данных, проверки ограничений на использование, офлайн-проверки ПИН-кода, проверки рисков) терминал принимает решение, как ему поступить с транзакцией. Имеются три варианта: отклонить транзакцию, послать транзакцию за авторизацией в режиме онлайн, принять транзацию офлайн. Терминал предлагает карте (команда Generate Application Cryptogram - АС) вычислить 3DES-криптограмму переданного запроса.

В соответствии с перечисленными вариантами решений имеются и три типа криптограмм - Application Authentication Cryptogram (AAC), Authorization Request Cryptogram (ARQC), Transaction Certificate (TC).
Принятие картой решения о дальнейших действиях (Card Action Analysis). На основании заданной эмитентом логики поведения и значений параметров, получив запрос на криптограмму, карта сначала сама анализирует принятые риски. При этом решение, предложенное терминалом, картой может быть только ужесточено. То есть решение послать онлайн-запрос может быть либо подтверждено, либо пересмотрено на отклонение транзакции сразу, решение терминала о принятии транзакции в офлайн-режиме может быть принято или заменено на отклонение транзакции или на онлайн-запрос.

В соответствии с решением карты формируются криптограммы типа AAC, ARQC или ТС.
Авторизация карты в режиме онлайн (Online Processing). Если терминал и карта приняли решение послать эмитенту онлайн-запрос, то терминал по линиям связи передает криптограмму ARQC и данные карты и транзакции, использованные при ее получении. Хостовая система банка-эмитента проверяет корректность криптограммы (используя уникальный SDES-ключ карты), принимает решение по данной транзакции и посылает ответ с критограммой типа Authorization Response Cryptogram (ARPC), используя тот же ключ карты.

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

Если аутентификация не прошла, то следующие транзакции будут отправлены в онлайн до успешного сравнения ARPC. Эмитент имеет возможность установить на карте параметр, отклоняющий транзакцию в случае неудачной аутентификации.
Изменение параметров карты (Issuer-to-Card Script Processing). Эмитент имеет возможность путем посылки в авторизационном ответе специальных скриптов изменить параметры карты, используемые при работе в офлайн, а также ПИН-код и число попыток его предъявления, заблокировать или разблокировать приложение, заблокировать карту. Скрипты подписываются с использованием специального SDES-ключа карты, новое значение ПИН шифруется таким же ключом.
Завершение процесса (Completion). На основании информации, полученной от эмитента, транзакция либо принимается, либо отклоняется. Соответственно формируются криптограммы ТС или ААС.
На рынке существует достаточно широкая номенклатура сертифицированных карт, удовлетворяющих спецификациям EMV и международных платежных систем. Попробуем классифицировать эти предложения. Обратим внимание на тот факт, что если достаточно полно описаны поведение карты в бою (при работе с терминалом), то вопросы (и команды), касающиеся персонализации карты, отданы на откуп разработчикам чипов и самих карт.
Существуют два типа карт - карты с закрытыми операционными системами (так называемые proprietary- или native-карты) и карты с открытыми операционными системами.
Как правило, операционные системы (маски) для native-карт разрабатывают сами производители смарт-карт, в первую очередь такие крупные, как Gemlpus, Axalto, Oberthur, GD. В этих картах приложение - это двухуровневая структура данных (аналог персонального компьютера - файлы внутри директории). По своим функциональным возможностям данные карты можно разделить на карты с одним EMV-приложением (VSDC или M/Chip Lite) и многофункциональные карты.

Преимущество первых - относительная дешевизна, вторых - возможность использования дополнительных приложений.

Интересные записи

Содержание раздела