Телефон вместо пропуска: NFC, Wallet и ограничения iOS/Android

Смартфон можно использовать вместо отдельной карты. Доступ к нему защищён кодом и биометрией, а платёжный токен потерянного устройства можно отозвать удалённо. Но телефон нельзя считать обычной NFC-картой с одним неизменным UID.

Для систем доступа важно разделять три разных механизма:

UID NFC-интерфейса телефона — технический адрес для установления связи. Он не является надёжным пропуском и может меняться при каждом касании.
Номер платёжного токена из Apple Pay или Google Pay — заменитель номера банковской карты, привязанный к кошельку и устройству. Именно его можно использовать как идентификатор в ODNFC.
Специальный пропуск в Wallet — отдельный продукт, который должен быть выпущен организацией и поддержан совместимым протоколом считывателя. Обычный билет или карточка, добавленные в Wallet, не становятся NFC-пропуском автоматически.

Почему нельзя использовать UID телефона

При активации NFC-устройство сначала сообщает считывателю UID. У пластиковой MIFARE-карты он обычно постоянный, поэтому простые СКУД часто используют UID как номер пропуска.

У смартфона это работает иначе. Android прямо определяет, что устройство в режиме HCE следует считать имеющим случайный UID: при новом касании считыватель может получить другое значение. iOS также не даёт обычному приложению произвольно превратить iPhone в MIFARE-карту с выбранным постоянным UID.

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

Утверждение «у телефона каждый раз новый UID» относится прежде всего к эмуляции карты и платёжным приложениям. Это не значит, что любое NFC-действие телефона передаёт только случайное число: после установления связи приложения могут обмениваться собственными данными по протоколу более высокого уровня.

На Android можно разработать HCE-приложение, которое после выбора своей платёжной или служебной программы отдаёт стабильный идентификатор. Но это уже собственный протокол между приложением и считывателем, а не чтение UID. На iPhone доступ к защищённой эмуляции пропусков требует участия в программах Apple, специальных прав приложения и совместимой инфраструктуры.

Рабочий вариант: платёжная карта в Apple Wallet или Google Wallet

Один из вариантов без отдельного мобильного приложения — использовать поддерживаемую банковскую карту, добавленную в официальный кошелёк:

на iPhone — платёжную карту в Apple Wallet, которая работает через Apple Pay;
на Android — платёжную карту в Google Wallet, которая работает через Google Pay.

При добавлении карты кошелёк создаёт для устройства платёжный токен. Apple называет его Device Account Number, Google — device token, DPAN или virtual account number. Это номер того же формата, что и номер карты, но он отличается от номера на пластике и обычно уникален для конкретного кошелька и устройства.

ODNFC устанавливает с телефоном EMV-совместимый обмен и получает номер, предъявленный платёжным приложением. Система доступа связывает этот номер с пользователем точно так же, как другой идентификатор:

Администратор включает режим регистрации пропуска.
Пользователь выбирает нужную карту в Wallet, подтверждает её предъявление и подносит телефон к считывателю.
ODNFC получает номер платёжного токена.
Система сохраняет связь «этот токен — этот пользователь».
При следующем касании полученный номер сравнивается с базой и используется только для решения, разрешать ли доступ.

Доступность Apple Pay и Google Pay зависит от страны, банка, платёжной системы, модели телефона и настроек безопасности. Наличие приложения Wallet само по себе не означает, что конкретную карту можно предъявлять по NFC.

Почему это не платёж и считыватель не может «прочитать деньги»

В сценарии пропуска используется только номер карты или платёжного токена как идентификатор. ODNFC не является банковским POS-терминалом:

не задаёт сумму покупки;
не запрашивает списание или блокировку средств;
не подключён к банку-эквайеру и платёжной сети для авторизации операции;
не получает PIN или CVC;
не узнаёт баланс счёта и не получает доступ к деньгам;
не читает историю операций из банковского приложения.

Деньги не лежат в доступной NFC-памяти телефона или карты. Остаток хранится в банковской системе, а платёж требует отдельного протокола, проверки криптограммы и авторизации. Само чтение номера не создаёт финансовую операцию.

Некоторые открытые служебные поля EMV-карты могут быть доступны при обычном чтении, но для пропуска они не нужны. В базе следует хранить только необходимый идентификатор, не выводить полный номер в журналы и по возможности сравнивать его через HMAC с секретным ключом, а не через обычный хеш.

Платёжный токен остаётся платёжным реквизитом даже без попытки списать деньги. До внедрения согласуйте правила его обработки и хранения с банком, платёжной системой и требованиями к защите данных. Храните только минимально необходимое, предпочтительно в псевдонимизированном виде.

Насколько постоянен номер из Wallet

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

Одна физическая карта на iPhone, Apple Watch и Android-телефоне обычно получит разные токены. Каждое устройство регистрируют как отдельный пропуск.
После удаления и повторного добавления карты, смены телефона, сброса устройства или перевыпуска токена номер может измениться.
Если в кошельке несколько карт, считывателю будет предъявлена выбранная или назначенная по умолчанию карта.
Кошелёк может потребовать разблокировку, Face ID, Touch ID или другое подтверждение. Это зависит от платформы и настроек пользователя.
Банк или платёжная система могут изменить поведение после обновления.

Поэтому у администратора должен быть простой способ повторно зарегистрировать телефон и отозвать старый идентификатор. Перед внедрением нужно проверить конкретные модели смартфонов, версии ОС, банк и карту, которые будут использоваться на объекте.

Обычный пропуск в Wallet и банковская карта — не одно и то же

В Apple Wallet и Google Wallet можно хранить билеты, карты лояльности, посадочные талоны и пропуска. Но наличие красивой карточки в приложении ещё не означает, что она передаёт данные через NFC.

Для бесконтактных пропусков Apple использует протокол Apple Pay VAS, NFC-сертификаты и сертифицированные терминалы. Google применяет Smart Tap: пропуск должен быть настроен издателем, а терминал — поддерживать этот протокол и идентификатор издателя. Корпоративные бейджи и ключи Apple Wallet тоже выпускаются только участвующей организацией и работают с совместимой системой доступа.

ODNFC и ODRFID не следует считать терминалами Apple VAS или Google Smart Tap только потому, что в них есть NFC. Описанный в этой статье вариант для ODNFC — это чтение номера платёжного токена, а не произвольного билета или пропуска, сохранённого в Wallet.

Почему SberPay и «Вжух» не являются готовыми пропусками

SberPay — отдельная платёжная система, а не вариант Apple Wallet или Google Wallet с тем же способом выдачи идентификатора.

На Android бесконтактный SberPay работает как платёжное приложение для поддерживаемых карт и ожидает обмен с совместимым платёжным терминалом. Он не обязан отдавать стороннему NFC-считывателю постоянный открытый номер, пригодный для СКУД. То, что ODNFC умеет прочитать номер физической карты «Мир», не означает автоматическую поддержку токена этой карты в SberPay.

Токенизированное приложение «Мир» может использовать другой набор команд, параметров и форматов ответа, чем те, которых достаточно для чтения номера обычной карты. Поэтому поддержку SberPay нужно реализовывать и проверять отдельно.

«Вжух» работает на iOS и Android через Bluetooth Low Energy и совместимый платёжный терминал Сбера, а не как NFC-карта. Наличие BLE в ODNFC само по себе не означает поддержку этого платёжного протокола. В других сценариях SberPay платёж запускается через QR-код, платёжную ссылку, кнопку или переход в приложение банка — это тоже не предъявление NFC-пропуска.

Поэтому SberPay нельзя закладывать в проект как поддерживаемый источник стабильного номера для ODNFC или ODRFID. Если это обязательное требование, нужна отдельная интеграция и проверка конкретной версии сервиса, а не только проверка наличия NFC в телефоне.

Совместимость с ODNFC и ODRFID

Устройство	Что происходит со смартфоном
ODNFC-LAN, Lua и MicroPython	Может использовать номер совместимого платёжного токена после проверки телефона и Wallet
ODNFC-LAN-C, Lua	Тот же сценарий через платёжный токен
ODNFC-RS485, Lua и MicroPython	Тот же идентификатор можно передать в СКУД или ПЛК по выбранному протоколу RS485; конкретную программу и сценарий нужно проверить
ODNFC-LAN-UHF	Не подходит: UHF 860–960 МГц — другой радиодиапазон, смартфон с NFC его не эмулирует
ODRFID-N и 13,56-МГц часть ODRFID-M	Читают UID NFC-объекта, но UID телефона может меняться; платёжный токен как ODNFC не извлекают
ODRFID-RS485	Работает с картами 13,56 МГц, но UID телефона может меняться; используйте физический пропуск или ODNFC
ODRFID-E и 125-кГц часть ODRFID-M	Не подходят: телефон не эмулирует EM-Marine/HID Prox 125 кГц

Для проекта «телефон вместо пропуска» выбирайте ODNFC-LAN, ODNFC-LAN-C или ODNFC-RS485 с радиоинтерфейсом 13,56 МГц. ODRFID-N и ODRFID-RS485 подходят для физических MIFARE/NTAG, а настольные ODRFID-E и ODRFID-M — для пропусков 125 кГц. Случайный UID смартфона нельзя использовать как постоянный номер пользователя.

Проверка перед внедрением

Убедитесь, что выбранная карта действительно работает в Apple Pay или Google Pay на целевом телефоне и в вашей стране.
Зарегистрируйте телефон и поднесите его несколько раз после блокировки, разблокировки и перезапуска. Система должна получать один и тот же платёжный токен, а не UID сеанса.
Проверьте выбор карты, если в Wallet их несколько.
Повторите тест на всех поддерживаемых моделях телефонов и версиях ОС.
Проверьте, как будет отозван старый токен при потере телефона и как пользователь зарегистрирует новый.
Оставьте резервный способ входа: физическую карту, временный код или помощь администратора.
Для объекта с высокими требованиями к безопасности используйте криптографически защищённый пропуск и контролируемый протокол СКУД. Сравнение только статического номера не подтверждает подлинность носителя так же строго, как полноценная криптографическая аутентификация.