Платежные карты: Бизнес-энциклопедия
Шрифт:
Заметим, что во избежание клонирования DDA-карты, лучше, когда такая карта напрямую не поддерживает метод SDA (косвенно SDA поддерживается в процессе проверки сертификата ключа карты), т. е. в частности не содержит объекта signed static application data! В этом случае даже если карта не содержит элемент SDA tag list, клонировать ее на SDA-карту невозможно, поскольку для этого отсутствуют необходимые данные (signed static application data).
Следует отметить, что отсутствие прямой поддержки картой метода SDA не скажется на ее распространнености, поскольку все терминалы поддерживает DDA.
Несмотря на то, что DDA-карты при правильной персонализации
Приведем самые простые примеры возможной модификации данных. Если терминал в команде GENERATE AC запросил криптограмму TC, а карта в лице банковского чипа принимает решение транзакцию обработать в онлайновом режиме или отвергнуть в оффлайновом режиме, то чип-эмулятор меняет незащищенные данные cryptogram information data таким образом, что карта отвечает терминалу криптограммой TC. Таким образом, транзакция одобряется притом, что решением эмитента она должна быть либо отвергнута, либо передана эмитенту на авторизацию.
Другой пример. Чип-эмулятор, получив от терминала значение размера транзакции, меняет его на меньшую величину, при которой карта готова одобрить транзакцию в оффлайновом режиме авторизации.
Такой чип-эмулятор в литературе получил название wedge device. Нужно сказать, что устройство wedge device может быть внедрено не только в печатной схеме карты, но и на POS-терминале. Главное, чтобы оно выполняло функцию посредника информационного обмена между картой и терминалом.
Проблема обеспечения целостности информационного обмена карты с терминалом решается с помощью использования CDA-карт. Такие карты поддерживают целостность наиболее важной информации, циркулирующей между картой и терминалом в ходе обработки транзакции. Поэтому модифицировать информационный обмен незаметным для терминала способом нельзя.
Кроме того, CDA-карты демонстрируют более высокую производительность (меньшее время выполнения транзакции) в сравнении с DDA-картами. Это объясняется тем, что для оффлайновой аутентификации карты не используется команда INERNAL AUTHENTICATE, что сокращает обмен данными терминала с картой.
Обеспечение целостности информационного обмена с терминалом и более высокая производительность делает CDA-карты привлекательными для бесконтактных платежей. В частности, в стандарте MasterCard PayPass в качестве способа динамической аутентификации рассматривается только метод CDA.
В то же время у CDA-карт отмечается ряд слабостей. Во-первых, размер модуля ключа CDA-карты может не превышать 205 байтов. На сегодняшний день это ограничение не является обременительным, поскольку в основном используются ключи карты меньшего размера. Однако в будущем отмеченное ограничение может стать чувствительным. Платежные системы уже распространяют свои ключи размером 248 байтов (максимальный размер ключа в соответствии со стандартом EMV), давая возможность эмитентам и картам
использовать ключи сравнимых размеров.Во-вторых, при неаккуратном со стороны обслуживающего банка (платежной системы) управлении загрузкой ключей системы на терминалы может случиться так, что обслуживающий банк не загрузил (точнее, не загрузил вовремя) на своих терминалах какой-то из ключей системы. В этом случае все CDA-карты эмитентов, ключи которых сертифицированы на отсутствующем в терминале ключе системы, просто не смогут на таком терминале обслуживаться.
Действительно, получив от карты ответ на команду GENERATE AC терминал не сможет восстановить данные из signed dynamic application data и вынужден будет отклонить транзакцию. Это произойдет, даже если карта в ответе на команду GENERATE AC направит терминалу криптограмму ARQC для обработки транзакции в режиме реального времени. Без знания ключа системы невозможно восстановить криптограмму ARQC из объекта signed dynamic application data, и транзакцию придется отклонить.
Заметим, что в случае DDA-карты транзакция при отсутствии на терминале соответствующего ключа системы могла бы быть выполнена в онлайновом режиме. Метод CDA в случае провала аутентификации карты в отличие от других методов аутентификации лишает ее возможности обращаться за авторизацией к эмитенту.
Обобщая сказанное выше, перечислим ниже способы клонирования гибридной карты для ее использования в оффлайновом режиме авторизации транзакции:
1) если гибридная карта является SDA-картой, то она легко клонируется в SDA-карту;
2) если мы имеем дело с DDA/CDA-картой, поддерживающей также напрямую метод SDA (на карте присутствует объект данных signed static application data), то такую карту можно клонировать на SDA-карту:
• изменив профиль карты (объект application interchange profile), что останется незаметным для терминала, при условии отсутствия на ней объекта SDA tag list таким образом, что профиль карты будет указывать на поддержку картой только метода SDA;
• при использовании клонированной карты в терминалах, поддерживающих в нарушение правил платежных систем только метод аутентификации карты SDA или не поддерживающих никакого метода оффлайновой аутентификации;
• при использовании карты эмитированной с использованием ложного ключа системы в терминале, на который ложный ключ системы был предварительно загружен;
3) DDA-карту можно «модернизировать», создав на ее основе печатную плату, использующую наряду с чипом реальной карты второй чип-симулятор, действующий по схеме атаки двумя чипами.
Еще раз заметим, что подделка чипа практически возможна только с помощью его клонирования — переноса данных реального чипа на чип, используемый для производства мошеннической карты. Действительно, для того, чтобы изменить данные на уже персонализированном чипе можно воспользоваться двумя способами: попытаться это сделать средствами процедуры script processing или в режиме персонализации карты.
В процедуре script processing для изменения записей и отдельных объектов данных используются команды PUT DATA и UPDATE RECORD. Эти команды применяются с использованием кодов MAC и при необходимости — шифрования данных. Кроме того, эти команды чаще всего выполняются после аутентификации картой эмитента.
Поэтому во время выполнения процедуры script processing мошенничества возможны только при компрометации секретных ключей карты/эмитента, используемых для формирования криптограммы и обеспечения целостности обмена данных (формирования кодов MAC).