Хакер получил доступ к NFC в iPhone |

Jailbreak developer hacks nfc on iphone 6s to talk to nfc devices

Благодарности

, который замотивировал меня на написание статьи и помогал по ходу её подготовки к публикации.

Саше Прыймак, который под моим руководством выполнил описанное в статье исследование.

Также большое спасибо за участие и поддержку:Кате Туркиной, Антону Давыдову, Лёше Ершову, Даше Алексеенко.

Джейлбрейк для ios 11 не понадобится – apple открыла доступ к nfc

Дополнительные задачи

1. Получение UID чипа
   Это сделать можно, очень простым способом.
   При старте сессии NFC модуль ищет чипы, AID’ы апплетов которых прописаны в info.plist, и складывает их в массив.
   После этого любой из них можно оттуда достать, и если его тип NFCISO7816Tag, то у него есть поле identifier, в котором и находится UID чипа.

   /**
     * @discussion The hardware UID of the tag.
   */
   var identifier: Data { get }

2. Получение ATR чипа
   А вот ATR, похоже, Core NFC получать не умеет, потому что во фреймворке для этого нет отдельных инструментов, а с помощью APDU-командATR получить нельзя.

Обходные пути

Первое, что приходит в голову — а можно ли добавить в info.plist не AID платежного апплета, а AID Card Manager’а (Card Manager — это группа сервисов внутри операционной системы чипа, управляющих картой, которые отвечают за администрирование и безопасность), чтобы потом вручную послать ему команду SELECT с AID нужного апплета?

Здесь мы споткнулись о первый подводный камень — Core NFC не позволяет отправлять команду SELECT, содержащую AID, который не прописан в info.plist.

Хорошо, добавили A0000000041010, но и тут неудача — Core NFC не позволяет отправлять команду SELECT, содержащую платежный AID, вне зависимости от того, есть он в info.plist или нет.

Разберемся, как именно работает ограничение по идентификаторам.

В info.plist мы указали следующие AID’ы:

1. A000000001510000	- GlobalPlatform Card Manager AID
2. 325041592E5359532E444446303101 - Proximity Payment System Environment (PPSE)
3. A0000000041010	- Mastercard Credit/Debit (Global)
4. A00000000401	- Mastercard PayPass
5. A00000000410101213	- Mastercard Credit
6. A00000000410101215	- Mastercard Credit
7. A00000000410101214	- Придуманный платежный AID
8. A00000000410101216	- Придуманный платежный AID
9. A0000000041010121F	- Придуманный платежный AID
10. A0000000041010BB5445535401 - Придуманный платежный Long AID
11. A0000000041010BB5445535405 - Придуманный платежный Long AID
12. A000000004101FBB5445535401 - Придуманный не платежный AID
13. A000000004101F1213	- Придуманный не платежный AID
14. A00000000F1010	- Придуманный не платежный AID
15. A0000000040F - Придуманный не платежный AID

Мы установили 14 платежных апплетов с разными AID (пп. 2-11 — платежные AID-ы), и попробовали отправить Card Manager команды SELECT с каждым из этих AID.

Ответили номера 12-15.  

Получается, что ограничение накладывается именно на некий префикс AID, наличие которого и определяет, платежный это идентификатор или нет.

Жаль, но этот способ отпадает.

Второй способ персонализации, предусмотренный GlobalPlatform, это команда INSTALL [for personalization].

Она отправляется в Card Manager и содержит AID апплета, который нужно персонализировать.

После этого можно отправлять команды STORE DATA в Card Manager, а он будет пересылать их в целевое приложение.

Но есть одно ограничение. Для того, чтобы апплет поддерживал такой способ персонализации, он должен реализовывать интерфейс org.globalplatform.Application.

Card Manager, на команду INSTALL [for personalization] с Mastercard Credit/Debit (Global) AID, который был присвоен апплету M/Chip Advance от NXP, отвечал ошибкой «6985» (Conditions of use not satisfied),

а значит надо проверить, реализует ли он интерфейс Application.

Для этого мы написали простое приложение-пустышку, реализующее этот интерфейс. Как и ожидалось, на INSTALL [for personalization] оно ответило «9000».

Но когда Application был убран из интерфейсов, реализуемых приложением, оно стало отвечать на эту команду «6985», как и в случае с апплетом M/Chip Advance.

Следовательно, проблема именно в том, что приложение NXP не реализует необходимый для такого способа персонализации интерфейс. Этот способ тоже отпадает.

Персонализация апплетов

На самом деле, персонализация апплета — очень простая штука; всё, что требуется, это загрузить в него необходимые платежные данные. Для этого нужно выбрать апплет командой SELECT по его AID, установить защищенное соединение и отправить выбранному апплету команды STORE DATA с данными внутри.

Теперь вернемся к списку AID’ов в файле info.plist — зачем он нужен, и как конкретно Core NFC выбирает, с каким апплетом взаимодействовать?

Выглядит это примерно так:

1. Программа идет по списку сверху вниз;
2. Для каждого AID она формирует и отправляет команду SELECT;
3. AID первого апплета, ответившего «9000» (статус успешного ответа, здесь список всех возможных ответов) записывается в поле initialSelectedAID объекта типа NFCISO7816Tag, который кладется в массив обнаруженных чипов

@available(iOS 13.0, *)
public protocol NFCISO7816Tag : NFCNDEFTag, __NFCTag {
   /**
    * @property initialSelectedAID The Hex string of the application identifier (DF name) selected by the reader when the tag is discovered.
    *                              This will match one of the entries in the «com.apple.developer.nfc.readersession.iso7816.select-identifiers»
    *                              in the Info.plist.
    */
   @available(iOS 13.0, *)
   var initialSelectedAID: String { get }

Дальше из массива можно выбрать любой такой объект, и с помощью метода

отправлять

выбранному апплету.

А теперь поговорим об этом ограничении:

Core NFC doesn't support payment-related Application IDs.

То есть

не поддерживает платежные AID’ы, а именно боевые, с которыми работают платежные терминалы.

Конечно, платежный AID в список info.plist добавить можно, вот только Core NFC его проигнорирует и не будет отправлять для него SELECT (кстати, здесь список всех использующихся AID’ов). Apple таким образом защищают свою технологию Apple Pay, закрывая сторонним разработчикам доступ к любым платежным функциям iPhone (и всему, что с этим связано).

Платформа iot

На данный момент мы с командой работаем над запуском платформы интернета вещей, которая сможет дополнить и расширить существующий опыт использования сервиса Pay и внедрить оплату (и другие сервисы идентификации) в те вещи, которые мы обычно носим с собой — так называемые носимые устройства.

Интернет вещей — это концепция привычных физических предметов, оснащенных технологиями для взаимодействия с внешней средой или друг с другом. 

В этой концепции привычные сценарии использования вещей перестраиваются благодаря автоматизации.

Пример носимых устройств — умные часы, фитнес-браслеты, кольца, брелоки.

Если раньше человек носил кольцо из-за красоты или символизма, то теперь, в концепции интернета вещей, кольцо выполняет функцию платежного инструмента, пропуска СКУД, пульта управления другими умными устройствами и т.д. Таким образом, для привычной вещи появляются новые удобные сценарии использования.

Умные вещи сейчас — мировой тренд. Об этом свидетельствуют собранные различными мировыми агентствами статистические данные (см. ссылки в конце статьи). 

В этой статье я хочу на примере проведенного нами исследования в рамках разработки IoT-платформы рассказать, с какими задачами работает финтех-направление приложения «Кошелёк», с какими проблемами мы сталкиваемся и как используем проверенные технологии карточной индустрии для создания новых продуктов.

Для начала я кратко и простыми словами опишу технологии, на которых базируется наша платформа. Если интересно почитать про эти технологии подробнее — в конце статьи будут ссылки. 

1. Элемент безопасности, или Secure Element — это полноценный компьютер, выполненный в цельном кристалле кремния размером около 5-20 квадратных миллиметров. Он имеет свою операционную систему, систему ввода-вывода, центральный процессор, несколько крипто-процессоров для реализации криптографических операций, оперативную и постоянную память. Элементы безопасности используют при производстве банковских карт, SIM-карт, а также встраивают в смартфоны и другие устройства. Элемент безопасности практически невозможно взломать и получить оттуда данные (отсюда и название).

   Как и на любой компьютер, в элемент безопасности можно установить приложения — так называемые апплеты. Мы в нашей статье будем работать с платежным апплетом, благодаря установке и персонализации которого носимое устройство с элементом безопасности и имеет сервис бесконтактной оплаты.

2. Стандарт GlobalPlatform Card Specification — он описывает работу операционной системы элемента безопасности в целом, а также сценарии и протоколы безопасного управления содержимым элемента безопасности.
3. TSM  (Trusted Service Manager) — сервис для управления содержимым в элементе безопасности. Он управляет жизненным циклом апплетов и их персонализацией под конкретного пользователя на конкретном элементе безопасности.
4. Для превращения носимого устройства в платежный инструмент платежными системами применяется технология токенизации по стандарту EMV — это процесс получения от платежной системы токена (суррогатного номера), связанного с номером реальной банковской карты. Для каждой банковской карты, в связке с форм-фактором устройства оплаты, токен всегда уникален, что обеспечивает дополнительную безопасность при оплате токеном.

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

Первый сценарий — это взаимодействие с активными носимыми устройствами. Активными называют носимые устройства, в которых есть свой элемент питания (например, аккумулятор). Как правило, внутри вещи работает своя операционная система и имеется модуль BLE для связи со смартфоном. Производитель устройства предоставляет SDK и ключи доступа для взаимодействия с элементом безопасности.

Именно так работают все умные часы и фитнес-браслеты с функцией бесконтактной оплаты.Тут всё просто и понятно — берем и делаем. 

Второй сценарий интереснее — это взаимодействие с пассивными носимыми устройствами. Пассивными называют носимые устройства, в которых нет своего элемента питания. Эти устройства питаются от внешнего магнитного поля, в которое их необходимо поместить.

Проблема заключается в том, что нужно загрузить в пассивное носимое устройство свою банковскую карту из приложения на смартфоне.

Этот сценарий мы (условно) разбиваем уже по типу смартфонов:

1. Любые смартфоны без NFC
2. Смартфон Android c NFC
3. iPhone c NFC

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

Реализация терминала персонализации может быть разной: может быть тот же смартфон пользователя, подключенный к внешнему считывателю смарт-карт по BLE или USB, а может быть и автономное внешнее устройство (полноценный компьютер с подключенным к нему считывателем, выходом в интернет и управляющим программным обеспечением).

Для второго типа (Android c NFC) реализация понятна. Смартфон в этом случае можно использовать в качестве терминала, запитать пассивное устройство от NFC-антенны и загрузить в него токен банковской карты.

В нашем исследовании я подробно распишу, как мы прорабатывали третий тип смартфонов (iPhone с NFC). В качестве носимых устройств мы использовали брелки от компании ISBC — партнера, с которым мы запускаем пилот.

Побочный результат исследования

В ходе проведения работ родилась схема потенциального мошенничества, которую нельзя воспроизвести посредством смартфонов Apple, но вполне можно реализовать через Android-смартфон с поддержкой NFC и технологией Host Card Emulation.

Суть вкратце: 

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

1. Первый смартфон прикладывается к любой банковской карте;
2. Второй — прикладывается к платежному терминалу;
3. Второй смартфон эмулирует банковскую карту, пересылая APDU-команды, посылаемые терминалом, первому смартфону;
4. Первый смартфон транслирует эти команды приложенной банковской карте, передавая ее ответы второму смартфону;
5. Второй смартфон передает полученные ответы терминалу;
6. Платеж произведен.

То есть потенциально мошенник может приложить смартфон к вашему карману и оплатить покупку.

Будьте осторожны!

Чтобы не стать жертвой подобной схемы мошенничества, вы можете, например, перенести банковские карты в смартфон и не носить с собой пластик.

Полезные ссылки

Если вас заинтересовала тема, описанная в статье, то ниже — несколько ссылок для более подробного изучения:

1. Книга И. М. Голдовского «Банковские Микропроцессорные Карты»
2. Концепция EMV Payment Tokenisation
3. Статьи с анализом рынка IoT: 

Привет, хабр!

Меня зовут Максим. Промышленной разработкой я занимаюсь с 2005 года. В Кошельке работаю с 2021 года, а с 2021 года помогаю бизнесу компании развивать новые финтех-сервисы в качестве руководителя подразделения.

В Кошельке наша команда запустила немало инновационных продуктов. Это и одна из первых в мире полностью виртуальная банковская карта в смартфоне с возможностью бесконтактной оплаты (за год до запуска Apple Pay в России и задолго до запуска Apple Card), и первая транспортная карта, и первая карта болельщика, и первая кампусная карта в смартфоне.

В прошлом году мы совместно с Mastercard запустили сервис Кошелёк Pay — единственный в мире сервис, который, в отличие от аналогов, работает независимо от производителя смартфона или операционной системы. Например, Кошелёк Pay работает на смартфонах Huawei, на которых отсутствуют сервисы Google.

Решение

В начале декомпозируем основную задачу, а именно определим шаги, необходимые для превращения совершенно обыкновенного брелка (ну, почти) в полноценное платежное средство:

1. Установление соединения чипа с NFC модулем iPhone
2. Установка на чип апплетов Mastercard M/Chip Advance и PPSE
3. Персонализация апплетов 

Установка апплетов

Для установки апплетов на чип необходимо защищенное соединение (Secure Channel Protocol или SCP); мы сделали это за кадром с помощью обычного

считывателя и платформы

TSM.

Однако, даже если у вас ничего из этого нет, вы все равно можете попробовать установить свой собственный апплет на чип — только на виртуальный.

Понадобится любая IDE с поддержкой JCOP Shell и эмулятором JavaCard, например, вот эта.

Создаем пустой проект, указываем желаемый AID (например 0000000000) и запускаем.

Дальше разбираемся по шагам:

1. /card
   Получаем ATR, отправляем SELECT без идентификатора, чтобы был выбран Card Manager;
2. auth
   Создаем защищенное соединение с эмулятором, иначе ничего установить не получится;
3. ls (опционально)
   С помощью этой команды можно увидеть, какие приложения установлены на вашем девайсе/эмуляторе;
4. install [packageAID] [appletAID] [instanceAID]
   Устанавливаем апплет:

   packageAID — идентификатор пакета (Module), например, «0000000000»
   appletAID — идентификатор апплета (Load File), например, «000000000000»
   instanceAID — идентификатор, который будет присвоен вашему апплету после установки, например, «A0000000041010»;

5. ls
   Проверяем, появился ли ваш апплет в списке установленных приложений:

Цель исследования

Можем ли мы дать возможность пользователю

на платформе iOS загрузить свою банковскую карту в носимое устройство, приложив его к iPhone?

То есть:

1. Пользователь в приложении приложении «Кошелёк» вводит данные своей банковской карты
2. Пользователь прислоняет к задней стенке iPhone носимое устройство
3. Банковская карта загружается в носимое устройство

Соответственно, техническая задача — определить, можно ли во внешний элемент безопасности (Secure Element) загрузить банковскую карту, используя обычный iPhone и его

антенну, через протокол

(T=CL). 

Дополнительные задачи:

1. Получить ATR (Answer To Reset) чипа, не убирая его от считывателя
2. Получить UID (Unique Identifier) чипа

Эти данные могут быть полезны, так как они часто используются для идентификации чипа в системах поставщиков сервисов и диверсификации ключей от чувствительных данных приложений чипа.

Что имеем:

Выводы

Что же в сухом остатке?

1. Мы научились работать с чипами стандарта ISO/IEC 7816 (в том числе и получать их UID), используя новые возможности фреймворка Core NFC;
2. Разобрались с ограничениями, наложенными Apple на свою технологию;
3. Выяснили, что на данный момент, используя iPhone, персонализировать апплеты с платежными идентификаторами, при этом не реализующие интерфейс Application — невозможно;
4. Взяли на заметку, что с любыми другими AID все работает на ура — эти знания пригодятся нам в будущем при работе с нефинансовыми сервисами.

Отвечая на вопрос, поставленный в начале, можем ли мы дать пользователю Кошелька возможность загрузить свою банковскую карту в брелок, приложив его к iPhone — нет, пока что это невозможно.

В рамках поставленной задачи мы остановились на использовании внешнего BLE считывателя для загрузки токена банковской карты из iPhone в пассивное носимое устройство.

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

Вместо заключения

Статью я старался писать простым языком, не сильно углубляясь в терминологию предметной области. В ней я описал один из инновационных проектов, над которым мы работаем, предметную область и небольшое исследование новых возможностей iOS фреймворка  Core NFC.