Как украсть деньги с бесконтактной карты и Apple Pay
В статье разбираются популярные мифы и сценарии мошенничества с бесконтактными системами оплаты на примере настоящего POS-терминала, карт PayPass/payWave и телефонов с функцией Google Pay/Apple Pay.
Рассматриваемые темы:
- Можно ли НА САМОМ ДЕЛЕ украсть деньги, прислонившись POS-терминалом к карману? — мы попытаемся полностью воспроизвести этот сценарий мошенничества от начала до конца, с использованием настоящего POS-терминала и платежных карт в реальных условиях.
- В чем разница между физическими и виртуальными картами Apple Pay? — как происходит связывание физической карты и токена Apple Pay, и почему Apple Pay во много раз безопаснее обычной карты.
- Используем аппаратный NFC-сниффер (ISO 14443A) — воспользуемся устройством HydraNFC для перехвата данных между POS-терминалом и картой. Рассмотрим, какие конфиденциальные данные можно извлечь из перехваченного трафика.
- Разбираем протокол EMV — какими данными обменивается карта с POS-терминалом, используемый формат запросов, механизмы защиты от мошенничества и replay-атак.
- Исследуем операции без карты (CNP, MO/TO) — в каких случаях на самом деле (!) можно украсть деньги с карты, имея только реквизиты, считанные бесконтактно, а в каких нельзя.
Внимание!
В статье подробно описывается гипотетическая схема мошенничества, от начала и до конца, глазами мошенника, с целью покрыть все аспекты, в которых культивируются мифы и заблуждения. Несмотря на провокационный заголовок, основной вывод статьи — бесконтактные платежи достаточно безопасны, а атаки на них трудоемки и невыгодны.
Материалы в статье представлены исключительно в ознакомительных целях. Все сцены демонстрации мошенничества инсценированы и выполнены с согласия участвующих в них лиц. Все списанные деньги с карт были возвращены их владельцам. Воровство денег с карт является уголовным преступлением и преследуется по закону.
Для начала рассмотрим базовые понятия: любые движения денег с использованием платежных карт возможны только через посредников, подключенных к платежной системе, например VISA или MasterCard. В отличие от переводов между физическими лицами, списание денег с карты доступно только юридическому лицу (мерчанту), имеющему договор эквайринга с банком.
Этапы транзакции при оплате через POS-терминал
На иллюстрации выше изображена классическая схема оплаты через POS-терминал. Именно эта последовательность действий происходит, когда после оплаты на кассе вы ожидаете подтверждения на терминале.
- Покупатель прикладывает/проводит/вставляет карту в POS-терминал;
- POS-терминал по интернету передает данные в банк-эквайер;
- Банк-эквайер через международную платежную систему (МПС) обращается в банк-эмитент и запрашивает, может ли конкретный держатель карты оплатить покупку;
- Банк-эмитент подтверждает или отклоняет покупку, после чего печатается слип (второй чек).
Бывают исключения из этой схемы, например оффлайн транзакции, их мы рассмотрим далее. Также, если банк-эквайер и банк-эмитент являются одним и тем же банком, шаги 2 и 4 выполняются внутри одного банка.
Продавец (Merchant) — лицо или организация, предоставляющая товары или услуги
Банк-эквайер (Acquiring bank) — банк, который предоставляет продавцу услуги приема платежей через банковские карты. В этом банке, обычно, находится расчетный счет продавца, куда зачисляются списанные с карты деньги.
Банк-эмитент (Issuing bank) — банк, выпустивший карту. В нем находится счет владельца карты, у которого списываются деньги.
Международная платежная система (МПС) — международная система-посредник между банками по всему миру, позволяющая банкам производить расчеты между собой без заключения договора с каждым банком по отдельности. Все банки, подключенные к МПС, соглашаются работать по одним правилам, что значительно упрощает взаимодействие. Например, Visa, MasterCard, UnionPay, American Express, МИР (нет, МИР не работает заграницей).
Владелец карты (Cardholder) — человек, заключивший с банком-эмитентом договор обслуживания карты.
Процедура привязки банковской карты к системе Apple Pay или Google Pay из-за непонятности процесса часто порождает заблуждения даже у профессионалов в IT. Мне приходилось слышать много разных мифов об этой технологии.
Популярные мифы об Apple Pay
- Карта копируется в телефон
Это не так, в микропроцессорной карте содержится защищенная область памяти с криптографической информацией, которая после выпуска карты не может быть извлечена. Из-за этого чипованную карту нельзя скопировать, никак, вообще. Справедливости ради нужно сказать, что подобные атаки возможны, но стоимость их превышает суммарное количество денег, которые потратят за всю жизнь большинство читателей этой статьи. - Телефон каждый раз подключается к интернету во время оплаты
Google Pay/Apple Pay не подключаются к интернету во время оплаты через POS-терминал. Вся нужная информация хранится локально в телефоне. - На каждую оплату генерируется новый номер карты (PAN)
Так может показаться, если читать пресс-релизы Apple о технологии Apple Pay. Но это ошибочное трактование понятия токена. На самом деле, реквизиты виртуальной карты остаются неизменными достаточно долго, вы можете это проверить по последним цифрам номера карты в слипе (банковском чеке) при оплате покупок. - При оплате через Apple Pay/Google Pay взымается дополнительная комиссия
Это не так, вы заплатите ровно столько, сколько указано на ценнике, и согласно условиям вашего договора с банком-эмитентом, чью карту вы привязали. - Деньги могут списаться два раза
Этот миф касается не только Google Pay/Apple Pay, но и обычных банковских карт. Полагаю, что он появился из-за систем оплаты общественного транспорта, в которых терминал списывает деньги с проездного билета каждый раз при поднесении, так что можно списать средства два или более раз, если неаккуратно поднести карту. В случае с POS-терминалами этого риска не существует, так как терминал прекращает обмен с картой, как только получил нужны данные.
Связывание физической карты с «токеном» в телефоне
Системы, подобные Apple Pay, работают на основе EMV Payment Tokenisation Specification. Процедура связывания физической карты и телефона с Apple Pay не описана публично, поэтому разберем процесс на основе известных данных:
- Поставщик (Google, Apple, Samsung) получает информацию о карте;
- Через МПС поставщик запрашивает, поддерживает ли данная карта (данный банк-эмитент) работу с EMV Tokenisation;
- На стороне МПС генерируется виртуальная карта (токен), который загружается в защищенное хранилище в телефоне. Мне неизвестно, где именно генерируется приватный ключ от виртуальной карты, передается ли он по интернету или генерируется локально на телефоне, в данном случае это не имеет значения.
- В телефоне появляется сгенерированная виртуальная карта-токен, операции по которой банк-эмитент интерпретирует как операции по первой физической карте. В случае блокировки физической карты, токен тоже блокируется.
Your browser does not support HTML5 video.
Apple Pay позволяет считать реквизиты виртуальной карты. PAN номер и expire date отличаются от привязанной карты российского Альфа-Банка. По BIN виртуальной карты (480099) определяется MBNA AMERICA BANK.
При оплате телефоном, POS-терминал видит обычную карту VISA или MasterCard, и общается с ней точно так же, как и с физической картой. Виртуальная карта-токен содержит все атрибуты обычной карты: PAN-номер, срок действия и прочее. При этом номер виртуальной карты и срок действия отличаются от привязанной оригинальной карты.
Сценарий 1 — обычный POS-терминал
Мошенник, вооруженный POS-терминалом
Самый популярный сюжет мошенничества в головах обывателей: к ним в толпе прижимается мошенник с включенным терминалом и списывает деньги. Мы попытаемся воспроизвести этот сценарий в реальности.
Условия следующие:
- У мошенника полностью рабочий обыкновенный POS-терминал, подключенный к банку-эквайеру, такой же, как в магазинах и у курьеров. Прошивка терминала не модифицирована. В нашем случае — Ingenico iWL250. Это портативный POS-терминал с GPRS модемом, который поддерживает бесконтактную оплату, работает от батарейки и полностью мобилен.
- Мошенник не использует дополнительные технические средства, только POS-терминал
- Списанные средства зачисляются на расчетный счет мошенника, по всем правилам банковских систем
Юридическое лицо
Для начала нам потребуется юридическое лицо с расчетным счетом и подключенным эквайрингом. Мы, как настоящие мошенники, не будем ничего оформлять на свое имя, а попытаемся купить готовое юр. лицо на сайте для таких же мошенников. Для этого посмотрим объявления с первой страницы гугла по запросу «купить ип» и «купить ооо».
Предложения о продаже готовых компаний от мошенников
Цена компании на черном рынке с расчетным счетом колеблется от 20 до 300 тысяч рублей. Мне удалось найти несколько предложений ООО с POS-терминалом от 200 тысяч рублей. Такие компании оформлены на подставных лиц, и покупатель получает весь пакет документов, вместе с «кеш-картой» — это банковская карта, привязанная к расчетному счету подставной компании. С такой картой мошенник может обналичивать деньги в банкомате.
Для простоты будем считать, что ООО + расчетный счет + эквайринг и POS-терминал обойдутся мошеннику в 100 000 рублей. На самом деле больше, но мы упростим жизнь нашему гипотетическому мошеннику, снизив себестоимость атаки. Ведь чем ниже себестоимость атаки, тем проще ее реализовать.
Идем воровать деньги
Итак, мошенник получил POS-терминал и готов отправиться в людное место, чтобы прислоняться к жертвам и воровать деньги из карманов. В нашем эксперименте все жертвы были предварительно проинструктированы о наших намерениях, и все попытки списания денег проводились с их согласия. В случаях, когда испытуемые не имели собственных бесконтактных банковских карт, им предлагалось положить в кошелек нашу карту. Предварительно у испытуемых выяснялось, где именно и как они хранят свои карты, поэтому мошенник заранее знал, где в сумке/кармане находится бесконтактная карта.
Your browser does not support HTML5 video.
Видео: мошенник разбушевался в торговом центре
В случае успешного списания, транзакция отменялась через меню терминала, и деньги возвращались на счет испытуемых. За все время эксперимента мы попытались «украсть» деньги у 20 испытуемых в здании торгового центра и на улице. Результат испытаний описан далее.
Лимит на максимальную сумму операции без подтверждения ПИН-кодом может быть установлен как на самом POS-терминале (CVM Required Limit), так и на стороне банка. В России это ограничение равно 1000₽.Справедливости ради нужно заметить, что в некоторых случаях мне удавалось обойти ограничение и выполнить бесконтактную оплату на сумму больше 1000₽ без ввода ПИН-кода. Однако это требует нестандартной настройки профиля рисков на POS-терминале (Terminal Risk Management) и нестандартных настроек на стороне банка эмитента карты.
Наш мошенник принимает решение списывать по 999.99 рублей за раз. Если будет запрошена повторная попытка списания суммы ниже лимита в короткий временной промежуток, будет также запрошен ввод ПИН-кода и, в большинстве случаев, не получится несколько раз подряд списать по 999.99 рублей. Поэтому наиболее оптимальной стратегией будет не более одного списания с одной карты.
В России максимальная сумма списания без PIN-кода равна 1000 руб.
В действительности, множество списаний с суммой 999.99 рублей за короткий промежуток времени могут спровоцировать срабатывание антифрод-системы на стороне банка-экваера, поэтому такая стратегия не является оптимальной для мошенника. Так что, в реальной жизни ему бы пришлось выбирать более разнообразные суммы, тем самым снижая потенциальный доход.
Кстати, во многих статьях по данной теме на русском языке говорится, что можно вручную установить собственный лимит на бесконтактные операции без ПИН-кода. Мне не удалось найти такой опции в основных российских банках. Может, вы знаете о такой возможности? Речь именно о бесконтактных платежах, а не любых chip&pin-транзакциях.
Проблема: Несколько карт в кошельке
Это важный момент в данном сценарии атаки, потому что в реальности почти никто не носит одну единственную карту в кармане. В большинстве случаев, карта хранится в кошельке вместе с другими бесконтактными картами, такими как проездные билеты или другие банковские карты.
Конкретно мой терминал Igenico iWL250 при обнаружении в поле действия более одной карты с SAK, обозначающим поддержку протокола 14443–4, возвращает ошибку: «предъявите одну карту».
Но так поступают не все терминалы. Например, сбербанковские POS-терминалы VeriFone выбирают случайную карту из нескольких. Некоторые терминалы просто игнорируют все карты, если их более одной, не показывая сообщений об ошибке.
Your browser does not support HTML5 video.
Попытка считать несколько карт в кошельке. POS-терминал возвращает ошибку.
Антиколлизии ISO 14443–3
Чтение одной конкретной карты из нескольких — непростая задача на физическом уровне. Для решения этой проблемы существует механизм антиколлизий. Он позволяет выбрать одну карту, если был получен ответ от нескольких карт сразу. Это самый первый этап установления связи с бесконтактной картой в протоколе ISO-14443A. На данном этапе считыватель не в состоянии выяснить, какая из представленных карт банковская. Единственный вариант — выбрать более-менее похожую на банковскую карту, на основании ответа SAK (Select Acknowledge).
Значение бит в ответе SAK
Так, например, используемая в московском общественном транспорте карта «Тройка» (стандарта Mifare) имеет значение SAK=0×08 (b00001000), в котором шестой бит равен нулю. В то время как у всех банковских карт в ответах SAK шестой бит равен 1, что означает поддержку протокола ISO 14443–4.
Поэтому все, что может сделать терминал при обнаружении нескольких карт одновременно — исключить карты, не поддерживающие ISO 14443–4, и выбрать одну из похожих на банковскую. Поддержка протокола ISO 14443–4, кстати, не гарантирует, что эта карта будет банковской, однако вероятнее всего, в кошельке обычного человека не будет карт другого типа, поддерживающих ISO 14443–4.
Блок-схема работы протокола антиколлизий
Из личного опыта: несмотря на наличие протокола антиколлизий, при наличии в кошельке хотя бы трех бесконтактных карт, считать успешно нужную карту КРАЙНЕ тяжело. Большинство попыток заканчивается ошибками чтения. Тем более сложно это сделать на бегу, прижимаясь к чужим карманам и сумкам.
Однако мы будем считать, что нашему мошеннику очень везёт, и это ограничение его не беспокоит.
Оффлайн vs Онлайн транзакции
В устрашающих сюжетах новостей рассказывают о мошенниках с POS-терминалами в вагонах метро, которые прямо в пути списывают у вас из карманов деньги. В этих сюжетах не упоминается, откуда у мошенника мобильный интернет в вагоне метро. Возможно, его терминал поддерживает оффлайн-транзакции?
Спецификации EMV допускают оффлайн-транзакции. В таком режиме списание происходит без онлайн-подтверждения со стороны банка-эмитента. Это работает, например, в общественном транспорте в Москве и Санкт-Петербурге. Чтобы не занимать очередь на входе в автобус, пока терминал выполнит онлайн-подтверждение, вас пропускают сразу, не проверяя, достаточно ли у вас денег на счету для оплаты проезда. В конце дня, когда на терминале появляется интернет, подписанные транзакции отправляются в банк-эмитент. Если окажется, что в этот момент у вас нет денег на оплату проезда, карта будет добавлена в стоп-лист на всех терминалах в городе. Долг можно погасить через личный кабинет по номеру карты. Подробнее об оплате проезда в автобуса Санкт-Петербурга: www.avtobus.spb.ru/for-passengers/oplata-bez-kontakta/
Лично мне не удалось получить POS-терминал, поддерживающий такую функцию, поэтому в сценарии с обычным «гражданским» POS-терминалом мы не будем рассматривать возможность оффлайн-списаний. Это ничего не меняет, кроме того, что атакующему потребуется наличие интернета на терминале, поэтому атака, например, в метро, значительно усложняется.
Существуют модели терминалов, поддерживающие WiFi, и в теории наш мошенник мог бы использовать WiFi в метро, предварительно позаботившись о покупке доступа без рекламы для MAC-адреса своего POS-терминала, чтобы не нужно было выполнять аутентификацию через captive portal, так как на POS-терминале это сделать нельзя.
Подсчитываем прибыль
В нашем сценарии себестоимость атаки была 100 000 рублей. Это значит, что для того, чтобы хотя бы вернуть вложения, нашему герою нужно выполнить минимум 100 транзакций по 1 тысяче рублей. Представим, что он был достаточно проворным и весь день бегал по городу, прижимаясь ко всем подряд, так, что к концу для сделал 120 успешных списаний. Мы не будем учитывать комиссию эквайринга (в среднем 2%), комиссию на обналичивание (4–10%) и другие комиссии.
Может ли он успешно обналичить деньги, используя карту, привязанную к расчетному счету?
В реальности не все так просто. Зачисление денег на счет мошенника произойдет только через несколько дней! За это время, наш мошенник должен надеяться, что никто из ста двадцати жертв не оспорит транзакцию, что крайне маловероятно. Поэтому в реальности, счет мошенника будет заблокирован еще до зачисления на него денег.
Если человек заметил, что по его карте была проведена покупка, которую он не совершал, ему следует обратиться к банку-эмитенту и подать претензию. На рассмотрение спорных операций на территории России уходит до 30 дней, а по операциям, совершенным за рубежом — до 60 дней. За это время банк-эмитент направляет запрос банку-эквайеру, и если банк-эквайер подтверждает факт совершения сомнительных операций, то блокируется терминал и средства на расчетном счете владельца терминала.
Александр Падерин, управляющий директор центра информационной безопасности Уральского банка реконструкции и развития (УБРиР)
Вывод
Себестоимость атаки в нашем сценарии — 100 000р. В действительности, она будет в несколько раз выше, поэтому мошеннику потребуется намного больше усилий для того, чтобы получить прибыль.
В нашем сценарии мошенник всегда списывает по 999.99 рублей, что, вероятнее всего, повлечет за собой срабатывание системы антифрода на стороне банка-эквайера. В реальности мошеннику потребуется списывать меньшие суммы.
Чтобы хотя бы окупить вложения, мошеннику потребуется обработать несколько сотен жертв. Если даже десяток из них обратится банк-эмитент и оспорит транзакцию, счет мошенника, скорее всего, будет заблокирован. Сценарий, в котором банк-эквайер находится в сговоре с мошенником маловероятен, потому как лицензия для работы с МПС стоит сильно больше, чем любые потенциальные прибыли от такого вида мошенничества.
Из 20 испытуемых только у трех удалось списать деньги с карты, что составляет 15% успеха от всех попыток. Это были те искусственные случаи, когда в кармане находилась одна единственная карта. В случаях же с кошельком и несколькими картами, терминал возвращал ошибку. В сценарии с терминалом, который использует модифицированную прошивку и реализует механизм антиколлизий, процент успешных списаний, возможно, будет выше. Однако, даже в случае использования антиколлизий, в реальных условиях на бегу, считать одну карту из нескольких настолько сложно, что успешное списание в таких условиях можно считать везением. В реальности, доля успешных списаний будет едва ли выше 10% от числа попыток.
Итак, несмотря на то, что в теории такая атака возможна, на практике она оказывается невыгодна и крайне тяжело осуществима. Шанс получить хоть какую-либо прибыль настолько мал, что лишает смысла всю затею.
Сценарий 2 — злой POS-терминал
Допустим, наш мошенник работает на кассе в магазине или курьером с мобильным POS-терминалом. В таком случае, у него появляется возможность вылавливать данные карты, которых, в некотором случае, может быть достаточно для оплаты в интернете.
Для начала разберемся, как именно выглядит бесконтактная транзакция, и какими данными обменивается карта с POS-терминалом. Так как нам лень читать тысячи страниц документации EMV Contactless Specifications, мы просто перехватим обмен на физическом уровне с помощью сниффера HydraNFC.
Есть некоторая разница между EMV-спецификацией для MasterCard PayPass и Visa payWave. Это разница в формате подписи и некоторых данных. Но для нас это несущественно.
NFC-сниффер
HydraNFC — полностью опенсорсный автономный сниффер ISO-14443A, который сохраняет перехваченные APDU-команды на SD-карту. Антенна сниффера размещается между терминалом и картой, и пассивно захватывает всю передаваемую информацию.
Сайт о HydraBus и шилде HydraNFC: hydrabus.com
Исходники прошивки: github.com/hydrabus/hydrafw
Your browser does not support HTML5 video.
Демонстрация перехвата обмена между POS-терминалом и телефоном с Apple Pay
Забегая вперед, нужно сказать, что на этом уровне оплата телефоном и обычной пластиковой картой не отличается. Для POS-терминала это обычная карта VISA. Однако, оплата телефоном намного безопаснее, чем физической картой, и дальше мы разберем, почему.
Разбор протокола EMV
Вот как выглядит записанный дамп при оплате шоколадки и бутылки воды общей стоимостью 142.98 рублей с помощью Apple Pay:
Кассовый чек и слип от транзакции (кликабельно)
R (READER) — POS-терминал
T (TAG) — карта (в нашем случае телефон)R>> 52
R>> 52
R>> 52
R>> 52
R>> 52
R>> 52
R>> 52
T<< 04 00
R>> 93 20
T<< 08 fe e4 ec fe
R>> 93 70 08 fe e4 ec fe dd 6e
T<< 20 fc 70
R>> 50 00 57 cd
R>> 26
R>> 52
T<< 04 00
R>> 93 70 08 fe e4 ec fe dd 6e
T<< 20 fc 70
R>> e0 80 31 73
T<< 05 78 80 70 02 a5 46
R>> 02 00 a4 04 00 0e 32 50 41 59 2e 53 59 53 2e 44 44 46 30 31 00 e0 42
T<< 02 6f 23 84 0e 32 50 41 59 2e 53 59 53 2e 44 44 46 30 31 a5 11 bf 0c 0e 61 0c 4f 07 a0 00 00 00 03 10 10 87 01 01 90 00 4b b3
R>> 03 00 a4 04 00 07 a0 00 00 00 03 10 10 00 bc 41
T<< 03 6f 31 84 07 a0 00 00 00 03 10 10 a5 26 9f 38 18 9f 66 04 9f 02 06 9f 03 06 9f 1a 02 95 05 5f 2a 02 9a 03 9c 01 9f 37 04 bf 0c 08 9f 5a 05 60 08 40 06 43 90 00 1d 66
R>> 02 80 a8 00 00 23 83 21 36 a0 40 00 00 00 00 01 42 98 00 00 00 00 00 00 06 43 00 00 00 00 00 06 43 18 09 18 00 e0 11 01 03 00 f9 14
T<< 02 77 62 82 02 00 40 94 04 18 01 01 00 9f 36 02 02 06 9f 26 08 d6 f5 6b 8a be d7 8f 23 9f 10 20 1f 4a ff 32 a0 00 00 00 00 10 03 02 73 00 00 00 00 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 9f 6c 02 00 80 57 13 48 00 99 72 50 51 17 56 d2 31 22 01 00 00 05 20 99 99 5f 9f 6e 04 23 88 00 00 9f 27 01 80 90 00 af c8
R>> 03 00 b2 01 1c 00 c9 05
T<< 03 70 37 5f 28 02 06 43 9f 07 02 c0 00 9f 19 06 04 00 10 03 02 73 5f 34 01 00 9f 24 1d 56 30 30 31 30 30 31 34 36 31 38 30 34 30 31 37 37 31 30 31 33 39 36 31 36 37 36 32 35 90 00 a7 7b
Разберем каждую строку строку из перехваченного дампа в отдельности.
R>> — данные, переданные POS-терминалом
T>> — данные, переданные картой (в нашем случае телефон с Apple Pay)
14443-A Select
В начале обмена терминал устанавливает соединение с картой на канальном уровне. Для тех, кто знаком с сетями и моделью OSI, будет удобно представить это в качестве уровня L2, а UID (Unique Identifier) карты как MAC-адрес узла.
В терминологии стандарта ISO-14443:
PCD (proximity coupling device) — название считывателя, в нашем случае это POS-терминал
PICC (proximity integrated circuit card) — карта, в нашем случае эту роль выполняет телефон
Важное отличие обычной платежной карты от Apple Pay в том, что в карта всегда доступна для считывания и никак не позволяет управлять процессом считывания. Ее можно бесконтрольно считать через одежду, в то время как телефон, попадая в поле действия считывателя, предлагает пользователю активировать виртуальную карту. До подтверждения пользователя телефон не передает никакие данные, и считыватель даже не знает, что рядом находится виртуальная карта.
R>> 52 // WUPA (wake up)
R>> 52 // WUPA
R>> 52 // WUPA
R>> 52 // WUPA
R>> 52 // WUPA
R>> 52 // WUPA
R>> 52 // WUPA
T<< 04 00 // ATQA (Answer To Request type A)
R>> 93 20 // Select cascade 1 (Anti Collision CL1 SEL)
T<< 08 fe e4 ec fe // UID (4 bytes) + BCC (Bit Count Check)
R>> 93 70 08 fe e4 ec fe dd 6e // SEL (select tag 0x9370) + UID + CRC16
T<< 20 fc 70 // SAK (Select Acknowledge 0x20) + CRC16
R>> 50 00 57 cd // HALT (Disable communocaion 0x5000) + CRC16
R>> 26 // REQA
R>> 52 // WUPA
T<< 04 00 // ATQA
R>> 93 70 08 fe e4 ec fe dd 6e // SELECT
T<< 20 fc 70 // SAK
R>> e0 80 31 73 // RATS (Request Answer to Select 0xE080) + CRC16
T<< 05 78 80 70 02 a5 46 // ATS (Answer to select response)
Терминал постоянно передает команду 0×52 Wake-up (WUPA), и как только в поле действия появляется карта, она отвечает командой Answer To Request type A (ATQA), в нашем случае это 0×04 0×00. Ответ ATQA может различаться в зависимости от производителей чипа.
Получив ответ ATQA, терминал начинает процедуру выявления коллизий, чтобы определить, есть ли в поле действия более одной карты. Команда 0×93 0×20 Select cascade level 1 (SEL CL1) запрашивает у всех карт в поле действия сообщить первую часть своих идентификаторов UID.
Карта отвечает 0×08 0xFE 0xE4 0xEC 0xFE, первые четыре байта — UID виртуальной карты Apple Pay и контрольная сумма 0xFE Bit Count Check (BCC) в конце.
Получив идентификаторы карт, считыватель обращается к конкретной карте командой 0×93 0×70 (SELECT). За командой следует UID карты 0×08 0xfe 0xe4 0xec + 0xfe BCC + 0xdd 0×6e CRC16.
Карта отвечает 0×20 Select Acknowledge (SAK) + 0xfc 0×70 CRC16.
Если на этом шаге получено несколько ответов SAK, ридер может уменьшить длину UID в команде SELECT, пока не ответит единственная карта. Однако, как показано выше, некоторые POS-терминалы отказываются продолжать, если на этом этапе выявлены коллизии, то есть присутствие нескольких карт одновременно.
Длина UID может быть 4, 7 или 10 байт. У всех банковских карт, что я встречал, в том числе и в Apple Pay, UID был равен 4 байтам. Интересно, что Apple Pay генерирует разный UID на каждое считывание, в отличие от физических карт, где UID обычно постоянный. Уверен, что это сделано для того, чтобы айфоны не использовали в качестве примитивных карт доступа, так как системы СКУД на основе UID до сих пор очень популярны.
Ридер посылает команду 0×50 0×00 HALT + 0×57 0xcd CRC16. Это команда завершения связи.
Дальше процедура повторяется заново, ридер снова пробуждает карту (WUPA), но уже без проверки коллизий, сразу выполняется SELECT. Зачем так сделано — не знаю, возможно, это какой-то более надежный способ определения коллизий.
Во второй раз ридер уже посылает команду 0xE0 0×80 Request Answer to Select (RATS) + 0×31 0×73 CRC16.
Карта отвечает 0×05 0×78 0×80 0×70 0×02 Answer to select response (ATS) + 0xA5 0×46 CRC16.
Answer to select — ответ аналогичный Answer To Reset (ATR) для контактных карт.
В нем содержится информация о максимальном размере кадра и параметрах канального уровня.
На этом этапе «канальный» уровень завершен, далее начинается обмен на более высокоуровневом протоколе, в зависимости от приложения, содержащегося на карте. Операция SELECT одинакова для всех бесконтактных карт стандарта ISO 14443A, в том числе NFC-меток, билетов на общественный транспорт, и т.д.
Запрос доступных приложений — SELECT PPSE
Официальное описание: EMV Contactless Specifications — PPSE and Application Management for Secure Element
Начало общения с EMV-картой всегда происходит с чтения PPSE (Payment System Environment). Терминал спрашивает у карты, какие платежные приложения на ней есть.
Чаще всего это одно приложение, как в нашем примере — VISA. Однако бывают карты с несколькими платежными приложениями, например, есть специальные отечественные карты МИР с двумя платежными приложениями внутри. Так как платежная система МИР не работает заграницей, в карту интегрируется второе платежное приложение, по сути вторая карта. Это может быть приложение платежной системы JCB или UnionPay. Такие карты называются кобейджинговыми.
APDU-команда SELECT PPSE
'00 A4 04 00 0E 32 50 41 59 2E 53 59 53 2E 44 44 46 30 31 00'
00 A4 04 00 // команда select
0E // длина command data (14 байт)
32 50 41 59 2E 53 59 53 2E 44 44 46 30 31 // command data 2PAY.SYS.DDF01
00 // завершающий маркер
Ответ на SELECT PPSE
'6F 23 84 0E 32 50 41 59 2E 53 59 53 2E 44 44 46 30 31 A5 11 BF 0C 0E 61 0C 4F 07 A0 00 00 00 03 10 10 87 01 01 90 00'
Для удобства проанализируем ответ с помощью онлайн-парсера формата TVL iso8583.info/lib/EMV/TLVs. Тот же ответ, обработанный парсером:
Из всего этого нас интересует только идентификатор платежного приложения (AID). В данном случае, это значение A0000000031010, означающее Visa International.
AID помечается маркером 4F. Вторым битом после маркера следует длина данных, в нем содержащихся. Несмотря на то, что длина AID может варьироваться от 5 до 16 байт, в большинстве случаев она равна 7 байтам.
Большой список AID: eftlab.co.uk/knowledge-base/211-emv-aid-rid-pix
Некоторые популярные AID
A0000000031010 Visa International
A0000000032020 Visa International
A0000000041010 Mastercard International
A0000000043060 Mastercard International United States Maestro (Debit)
Application Priority Indicator — указывает приоритет платежных приложений. Например, в кобейджинговых картах МИР, имеющих внутри несколько платежных приложений, это поле указывает, какое из двух приложений приоритетнее. Так как у нас только одно приложение Visa International, оно указывает на него, и приоритет отсутствует.
Запуск платежного приложения — SELECT AID
'00 A4 04 00 07 A0 00 00 00 03 10 10'
00 A4 04 00 // команда select
07 // длина command data (7 байт)
A0 00 00 00 03 10 10 // AID Visa International
Выбрав нужное платежное приложение, терминал запускает его.
PDOL (Processing Options Data Object List)
'6f 31 84 07 a0 00 00 00 03 10 10 a5 26 9f 38 18 9f 66 04 9f 02 06 9f 03 06 9f 1a 02 95 05 5f 2a 02 9a 03 9c 01 9f 37 04 bf 0c 08 9f 5a 05 60 08 40 06 43 90 00'
Разберем ответ парсером
В ответ на запуск платежного приложения карта сообщает набор параметров, которые ожидает получить от терминала — PDOL (Processing Options Data Object List). Терминал обязан ответить в строгом соответствии с этой последовательностью.
PDOL у разных карт может различаться. Общее число параметров PDOL — несколько десятков. Полный список параметров PDOL можно посмотреть здесь: eftlab.co.uk/index.php/site-map/knowledge-base/145-emv-nfc-tags.
Разберем PDOL внимательнее. Длина, указанная после маркера — строго ожидаемая длина ответа от терминала на данный запрос. Пустой ответ заполняется нулями до нужной длины.
Разбор запроса PDOL:
9F 38 18 // Маркер начала PDOL. Длина 18 (24 байта)
9F 66 (длина 04) // Terminal Transaction Qualifiers (TTQ). Набор поддерживаемых терминалом протоколов.
9F 02 (длина 06) // Сумма списания
9F 03 (длина 06) // вторая сумма
9F 1A (длина 02) // Код страницы в формате ISO3166-1
95 (длина 05) // Terminal Verification Results
5F 2A (длина 02) // Код валюты, в которой работает терминал, в формате ISO4217
9A (длина 03) // Дата в формате YYMMDD
9C (длина 01) // Тип транзакции
9F 37 (длина 04) // Случайное число
До этого момента все передаваемые данные идентичны для любых транзакций по этой карте.
Запрос на списание — GET PROCESSING OPTIONS
'80A8000023832136A0400000000001429800000000000006430000000000064318091800E011010300'
80 A8 00 00 // Команда GET PROCESSING OPTIONS (GPO)
23 // длина всего запроса (35 байт)
83 // маркер PDOL-ответ
21 // длина PDOL-ответа (33 байта)
36 A0 40 00 // Terminal Transaction Qualifiers (TTQ)
00 00 00 01 42 98 // Сумма списания (142,98 рублей)
00 00 00 00 00 00 // Вторая сумма
06 43 // Код страны экваера (643 - россия)
00 00 00 00 00 // Terminal Verification Results (TVR)
06 43 // Валюта (643 - russian ruble)
18 09 18 // дата (18 сентября 2018 года)
00 // тип транзакции
E0 11 01 03 // Случайное число
В этом ответе наглядно видно, как терминал, который находится в России, запрашивает списание с карты на сумму 142,98 рублей. Обращаем внимание на случайное число в конце (E0110103). Это параметр 9F37 Unpredictable Number. Это первое упоминание криптографии. В дальнейшем это число вместе с данными транзакции карта должна будет подписать криптографической подписью. Это дает терминалу контроль над актуальностью подписи от карты и защищает от replay атак.
Ответ карты на GET PROCESSING OPTIONS
'7762820200409404180101009F360202069F2608D6F56B8ABED78F239F10201F4AFF32A00000000010030273000000004000000000000000000000000000009F6C02008057134800997250511756D23122010000052099995F9F6E04238800009F2701809000'
В данном ответе содержатся специфичные для VISA поля данных, поэтому я использовал парсер c поддержкой VISA Contactless Payment Specification (VCSP)
Application Interchange Profile (AIP) — содержит информацию о параметрах платежного приложения. В нашем случае AIP равен 00 40. Рассмотрим значения данного параметра из EMV 4.3 Book 3.
В нашем случае установлен один бит во втором байте, который, если верить этой таблице, Reserved For Future Use (RFU). Что это значит, и какой смысл в это вкладывает Apple Pay, я не знаю.
В AIP содержится важная информация о поддерживаемых методах аутентификации (SDA, CDA, DDA) платежа. Почему в моем случае все эти флаги равны нулю — я не понимаю.
Application File Locator (AFL) — Содержит информацию о расположении записей (SFI range of records) в конкретном AID. На основании этого ответа терминал сформирует запрос READ RECORD.
Разберем ответ AFL подробн