stihl не предоставил(а) никакой дополнительной информации.
NFC-сниффер

Для просмотра ссылки Войди
→ Для просмотра ссылки Войди
→ Для просмотра ссылки Войди
Демонстрация перехвата обмена между POS-терминалом и телефоном с Apple Pay
Забегая вперед, нужно сказать, что на этом уровне оплата телефоном и обычной пластиковой картой не отличается. Для POS-терминала это обычная карта VISA. Однако, оплата телефоном намного безопаснее, чем физической картой, и дальше мы разберем, почему.
Разбор протокола EMV
Вот как выглядит записанный дамп при оплате шоколадки и бутылки воды общей стоимостью 142.98 рублей с помощью Apple Pay:
Сырые данные, полученные со сниффера (раскрыть спойлер)
Разберем каждую строку строку из перехваченного дампа в отдельности.
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)
Терминал постоянно передает команду 0x52 Wake-up (WUPA), и как только в поле действия появляется карта, она отвечает командой Answer To Request type A (ATQA), в нашем случае это 0x04 0x00. Ответ ATQA может различаться в зависимости от производителей чипа.
Получив ответ ATQA, терминал начинает процедуру выявления коллизий, чтобы определить, есть ли в поле действия более одной карты. Команда 0x93 0x20 Select cascade level 1 (SEL CL1) запрашивает у всех карт в поле действия сообщить первую часть своих идентификаторов UID.
Карта отвечает 0x08 0xFE 0xE4 0xEC 0xFE, первые четыре байта — UID виртуальной карты Apple Pay и контрольная сумма 0xFE Bit Count Check (BCC) в конце.
Получив идентификаторы карт, считыватель обращается к конкретной карте командой 0x93 0x70(SELECT). За командой следует UID карты 0x08 0xfe 0xe4 0xec + 0xfe BCC + 0xdd 0x6e CRC16.
Карта отвечает 0x20 Select Acknowledge (SAK) + 0xfc 0x70 CRC16.
Если на этом шаге получено несколько ответов SAK, ридер может уменьшить длину UID в команде SELECT, пока не ответит единственная карта. Однако, как показано выше, некоторые POS-терминалы отказываются продолжать, если на этом этапе выявлены коллизии, то есть присутствие нескольких карт одновременно.
Длина UID может быть 4, 7 или 10 байт. У всех банковских карт, что я встречал, в том числе и в Apple Pay, UID был равен 4 байтам. Интересно, что Apple Pay генерирует разный UID на каждое считывание, в отличие от физических карт, где UID обычно постоянный. Уверен, что это сделано для того, чтобы айфоны не использовали в качестве примитивных карт доступа, так как системы СКУД на основе UID до сих пор очень популярны.
Ридер посылает команду 0x50 0x00 HALT + 0x57 0xcd CRC16. Это команда завершения связи.
Дальше процедура повторяется заново, ридер снова пробуждает карту (WUPA), но уже без проверки коллизий, сразу выполняется SELECT. Зачем так сделано — не знаю, возможно, это какой-то более надежный способ определения коллизий.
Во второй раз ридер уже посылает команду 0xE0 0x80 Request Answer to Select (RATS) + 0x31 0x73 CRC16.
Карта отвечает 0x05 0x78 0x80 0x70 0x02 Answer to select response (ATS) + 0xA5 0x46 CRC16.
Для просмотра ссылки Войди
На этом этапе «канальный» уровень завершен, далее начинается обмен на более высокоуровневом протоколе, в зависимости от приложения, содержащегося на карте. Операция SELECT одинакова для всех бесконтактных карт стандарта ISO 14443A, в том числе NFC-меток, билетов на общественный транспорт, и т.д.
Запрос доступных приложений — SELECT PPSE
Официальное описание: Для просмотра ссылки Войди
Начало общения с 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 Для просмотра ссылки Войди

Из всего этого нас интересует только идентификатор платежного приложения (AID). В данном случае, это значение A0000000031010, означающее Visa International.
AID помечается маркером 4F. Вторым битом после маркера следует длина данных, в нем содержащихся. Несмотря на то, что длина AID может варьироваться от 5 до 16 байт, в большинстве случаев она равна 7 байтам.
Большой список AID: Для просмотра ссылки Войди
Некоторые популярные 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 можно посмотреть Для просмотра ссылки Войди
Разберем 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). Это параметр Для просмотра ссылки Войди
Ответ карты на GET PROCESSING OPTIONS
'7762820200409404180101009F360202069F2608D6F56B8ABED78F239F10201F4AFF32A00000000010030273000000004000000000000000000000000000009F6C02008057134800997250511756D23122010000052099995F9F6E04238800009F2701809000'
В данном ответе содержатся специфичные для VISA поля данных, поэтому я использовал парсер c поддержкой Для просмотра ссылки Войди

Application Interchange Profile (AIP) — содержит информацию о параметрах платежного приложения. В нашем случае AIP равен 00 40. Рассмотрим значения данного параметра из Для просмотра ссылки Войди

В нашем случае установлен один бит во втором байте, который, если верить этой таблице, Reserved For Future Use (RFU). Что это значит, и какой смысл в это вкладывает Apple Pay, я не знаю.
В AIP содержится важная информация о поддерживаемых методах аутентификации (SDA,CDA,DDA) платежа. Почему в моем случае все эти флаги равны нулю — я не понимаю.
Application File Locator (AFL) — Содержит информацию о расположении записей (SFI range of records) в конкретном AID. На основании этого ответа терминал сформирует запрос READ RECORD.
Разберем ответ AFL подробнее:
Short File Identifier (SFI) равно 0x18. Этот параметр кодируется пятью битами вместо восьми. Соответственно значение 0x18 (b00011000) преобразовываем в b00000011, и получаем 0x3.
First record = 1
Last record = 1
Т.е. в «папке» №3 есть записи с 1 по 1, то есть одна запись.
Application Transaction Counter (ATC) — инкрементный счетчик транзакций, который увеличивается каждый раз на единицу при запросе GET PROCESSING OPTIONS. Под достижению значения 0xFFFF или 0x7FFF, платежное приложение безвозвратно заблокируется. Полагаю, что это сделано для защиты от брутфорса приватного ключа карты. В нашем случае видно, что данный айфон с Apple Pay использовался для оплаты уже 518 (0x206) раз.
Application Cryptogram (AC) — криптографическая подпись, которая вычисляется картой с использованием ее приватного ключа. Данная подпись передается вместе с остальными данными банку-эмитенту, и на ее основании проверяется подлинность транзакции. Так как приватный ключ карты невозможно (доступными средствами) извлечь из карты, это позволяет исключить возможность копирования карты.
Issuer Application Data (IAD) — Содержит проприетарные данные, специфичные для VISA. Я не осилил разбор этой структуры, помогите.
Card Transaction Qualifiers (CTQ) — специфичный для VISA cписок поддерживаемых картой спецификаций. Например, можно ли использовать эту бесконтактную карту для операций в банкомате или нет, и какие подтверждения при этом потребуются.

Track 2 Equivalent Data — Оппа! В этом поле содержится номер карты и expiration date, подробнее эта информация будет разобрана далее.
Form Facto Indicator (FFI) — специфичное для VISA поле. Описывает форм-фактор и характеристики платежного устройства. В нашем случае видно, что это мобильный телефон.
Cryptogram Information Data (CID) — Я не осилил разбор этой структуры, помогите.
Запрос READ DATA RECORD
'00 b2 01 1c 00'
Терминал посылает запрос на чтение записей, полученных из AFL:

В данном случае, начиная с байта 0x1C следует читать как два значения, где первые пять бит равны 0x18 (b000011), и составляют SFI, а последующие три бита равны 0x04 (d100), и составляют номер записи.
Ответ на READ RECORD
'70375F280206439F0702C0009F19060400100302735F3401009F241D5630303130303134363138303430313737313031333936313637363235'

Application Usage Control (AUC) — определяет, разрешено ли платить картой заграницей, и разрешенные виды операций.
9F19 — что-то непонятное, судя по всему — устаревший Dynamic Data Authentication Data Object List (DDOL)
EMV Tokenisation, Payment Account Reference (PAR) — специфичный для токенезированных (виртуальных) карт параметр. Я не осилил разбор этой структуры, помогите.
Что можно извлечь из перехваченой транзакции?
Мы разобрали один конкретный пример перехваченного трафика бесконтактной транзакции Apple Pay c привязанной картой VISA. Протокол MasterCard немного отличается, но в целом похож. Из разбора видно, что транзакция защищена криптоподписью, и протокол защищен от replay-атаки.Существует устаревший протокол бесконтактной оплаты в режиме Magnetic Stripe (MSD), который намного хуже защищен от replay-атак, но в данной статье я его разбирать не буду, потому что, насколько мне известно, он почти не поддерживается в СНГ, возможно я ошибаюсь.

Из перехваченных данных можно извлечь номер карты (PAN) и срок действия (expiration date)
Как видно, из перехваченного трафика можно извлечь полный номер карты и expiration date. Хоть CVV в этом дампе и нет, этих данных уже достаточно для оплаты в некоторых интернет-магазинах. В случае с обычной физической пластиковой картой, в перехваченных данных будет содержаться тот же PAN и срок действия, который выбит на самой карте!
Оплата в интернете без CVV (CNP, MO/TO)
В дампе выше указан не только полный номер моей карты, но также и expiration date. Этих данных вполне достаточно, чтобы платить в некоторых магазинах в интернете. Что ж, попробуем это сделать.

Форма добавления карты в Amazon не требует CVV
Будь это номер физической карты, деньги действительно можно было бы украсть, но данные токена Apple Pay можно использовать ТОЛЬКО для операций Client Present (CP), когда карта подписывает транзакцию криптографический подписью. Эти данные нельзя использовать для оплаты в интернете и других операций типа Card not present (CNP), то есть по телефону или имейлу. То-то же!
Всем желающим убедиться в этом, сообщаю, что реквизиты из перехваченного выше дампа Apple Pay на данный момент актуальны и привязаны к действующей карте, на которой есть деньги. На момент написания статьи это 5 тысяч рублей. Предлагаю попробовать их украсть
Почему Apple Pay безопаснее обычной карты

Apple Pay vs обычная бесконтактная карта
- Apple Pay требует авторизацию (отпечаток или пароль) на каждую проведенную транзакцию. Обычная карта не позволяет управлять количеством подписанных транзакций при поднесении к POS-терминалу. В теории, «злой» терминал с модифицированной прошивкой может провести одну транзакцию, а пока клиент держит карту возле считывателя, запросить несколько подписаний, но не проводить их сразу, а провести позже, когда клиент уйдет. С Apple Pay такое невозможно, после проведения транзакции пользователь видит значок успешно выполненной операции и приложение закрывается, новый запрос потребует повторный ввод отпечатка пальца.
- Не позволяет считывать данные до авторизации — когда телефон с Apple Pay попадает в поле действия считывателя (13,56 МГц), пользователю предлагается авторизоваться, и только после успешной авторизации телефон начинает обнаруживаться как бесконтактная карта. До этого момента считыватель не видит ничего. Именно поэтому данные с Apple Pay нельзя считать незаметно из кармана, в отличие от обычной карты.
- Нельзя использовать перехваченные данные для оплаты в интернете — обычная карта может быть использована для операций типа Card not present (CNP), то есть для оплаты в интернете, по телефону и т.д. Данные из виртуальной карты Apple Pay нельзя использовать подобным образом.
- Не раскрывает данные владельца — обычные бесконтактные карты могут передавать имя владельца (Cardholder name) и историю последних покупок. По номеру карты, в некоторых случаях, можно установить ФИО владельца. С Apple Pay ничего подобного сделать нельзя.
Вывод
Бесконтактные платежные системы достаточно надежно защищены. Несмотря на теоретическую возможность мошенничества, на практике она оказывается нерентабельна и крайне тяжело осуществима. Нет никакой причины бояться бесконтактных карт или пытаться сломать антенну в карте.
При прочих равных, Apple Pay будет безопаснее обычной пластиковой карты. Для большей безопасности можно заблокировать CNP-операции (оплата в интернете) по основной бесконтактной карте, и завести вторую карту только для оплаты в интернете.