Addressing NFC Mobile Relay Attacks: NFC User Key Confirmation Protocols | Request PDF

Iso/iec 14443 – бесконтактные карты

Стандарт включает четыре раздела:

• ISO/IEC 14443-1:2008 – физические характеристики. Этот раздел стандарта ISO/IEC 14443 определяет размер и физические характеристики карты. В нем также перечислены некоторые экстремальные условия окружающей среды, которые карта должна выдерживать без прерывающих использование карты дефектов. Эти тесты предназначены для выполнения на уровне карты и зависят от конструкции карты и конструкции антенны. Большинство требований не может быть напрямую переведено на уровень ИС или кристалла.
• ISO/IEC 14443-2: 2020 – радиочастотная мощность и баланс сигнала. Этот раздел определяет РЧ-мощность и сигнальный интерфейс для двух схем передачи сигналов: типа A и типа B. Обе схемы являются полудуплексными со скоростью передачи данных 106 кбит/с в каждом направлении. Данные с карты передаются посредством модулированной нагрузки с поднесущей 848 кГц. Электропитание карты происходит от РЧ-поля. Батарея не требуется.
• ISO/IEC 14443-3: 2020 – инициализация и механизм предотвращения конфликтов. В этом разделе описаны протоколы инициализации и предотвращения конфликтов для PICC типов A и B. Определены команды предотвращения конфликтов, отклики, пакеты данных и синхронизация. Схема инициализации и предотвращения конфликтов разработана таким образом, что позволяет создавать мультипротокольные считыватели, способные связываться с картами типов A и B. Находясь в РЧ-поле, карты обоих типов пассивно ожидают команды опроса (Polling). Мультипротокольный считыватель опрашивает один тип карт, завершает все транзакции с ответившими картами, а затем проводит опрос для другого типа карт.
• ISO/IEC 14443-4:2020 – протокол передачи. Этот раздел определяет высокоуровневые протоколы передачи данных для PICC Типов A и B. Эти протоколы являются опциональными, поэтому PICC могут быть спроектированы как с их поддержкой, так и без нее. PICC сообщает PCD о возможности ответа на команду опроса, как определено в разделе 3 стандарта. Таким образом, PCD знает, поддерживает ли PICC протоколы высокого уровня, определенные в этом разделе стандарта ISO/IEC 14443.

Протоколы, определенные в разделе 4, также позволяют передавать блоки данных приложений, как определено в ISO/IEC 7816-4, и выбор приложения, как определено в ISO/IEC 7816-5. ISO/IEC 7816 является стандартом контактной смарт-карты на основе интегральной схемы.

Rf430f59xx

Микросборка RF430F5978 (система в корпусе) (рисунок 7) [9] объединяет в себе низкочастотный радиоинтерфейс, NFC-интерфейс 134 кГц, радиочастотный приемопередатчик субгигагерцевого диапазона и микроконтроллерное ядро MSP430. Подобная архитектура позволяет активировать устройство в пределах определенной области и может способствовать сокращению общего энергопотребления устройства.

Встроенный низкочастотный транспондер продолжает функционировать даже в отсутствии основного питания. Обмен данными по RFID-каналу может быть защищен шифрованием (AES128), при этом для операций чтения/записи доступно 2 кбайта EEPROM. Блок транспондера имеет выводы для подключения трех внешних антенн.

В RF430F5978 обеспечена тесная интеграция между ядром микроконтроллера, его периферийными устройствами, встроенным субгигагерцевым трансивером и низкочастотным трансивером RFID.

Система на кристалле CC430 объединяет в себе трансивер CC1101 и микроконтроллер MSP430 с 32 кбайт FLASH-памяти, 4 кбайт ОЗУ, два 16-битных таймера, высокопроизводительный 12-разрядный АЦП, датчики температуры и уровня питающего напряжения, аналоговый компаратор, универсальный последовательный интерфейс, блок AES-шифрования, часы реального времени.

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

Tnf_well_known с rtd_text (mime-тип с записью простого текста)

Создать NDEF-запись TNF_WELL_KNOWN можно следующим образом:

Kotlin

fun createTextRecord(payload: String, locale: Locale, encodeInUtf8: Boolean): NdefRecord {
    val langBytes = locale.language.toByteArray(Charset.forName("US-ASCII"))
    val utfEncoding = if (encodeInUtf8) Charset.forName("UTF-8") else Charset.forName("UTF-16")
    val textBytes = payload.toByteArray(utfEncoding)
    val utfBit: Int = if (encodeInUtf8) 0 else 1 shl 7
    val status = (utfBit   langBytes.size).toChar()
    val data = ByteArray(1   langBytes.size   textBytes.size)
    data[0] = status.toByte()
    System.arraycopy(langBytes, 0, data, 1, langBytes.size)
    System.arraycopy(textBytes, 0, data, 1   langBytes.size, textBytes.size)
    return NdefRecord(NdefRecord.TNF_WELL_KNOWN, NdefRecord.RTD_TEXT, ByteArray(0), data)
}

Java

public NdefRecord createTextRecord(String payload, Locale locale, boolean encodeInUtf8) {
    byte[] langBytes = locale.getLanguage().getBytes(Charset.forName("US-ASCII"));
    Charset utfEncoding = encodeInUtf8 ? Charset.forName("UTF-8") : Charset.forName("UTF-16");
    byte[] textBytes = payload.getBytes(utfEncoding);
    int utfBit = encodeInUtf8 ? 0 : (1 << 7);
    char status = (char) (utfBit   langBytes.length);
    byte[] data = new byte[1   langBytes.length   textBytes.length];
    data[0] = (byte) status;
    System.arraycopy(langBytes, 0, data, 1, langBytes.length);
    System.arraycopy(textBytes, 0, data, 1   langBytes.length, textBytes.length);
    NdefRecord record = new NdefRecord(NdefRecord.TNF_WELL_KNOWN,
    NdefRecord.RTD_TEXT, new byte[0], data);
    return record;
}

Intent-фильтр для такой NDEF-записи будет таким:

Антенна

ISO/IEC 14443 определяет 6 классов антенн (показанных на рисунке 6), также упоминаемых в ISO/IEC 15693. Для каждого устройства NFC необходимо выбрать подходящую антенную конструкцию, чтобы обеспечить оптимальные параметры в заданной среде.

Большие антенны Класса 1 имеют форму и размеры смарт-карты. Они обеспечивают наилучшие показатели в отношении электромагнитного РЧ-поля. На другом конце стандартизованного ряда антенн находится Класс 6. Такая антенна является самой маленькой и обладает наилучшими возможностями для встраивания, с учетом потерь в качественных характеристиках.

«Форум NFC» предоставляет свои собственные конструкции PCD – Proximity coupling device (передатчики, называемые «опрашивателями» – poller) и PICC – Proximity coupling device  (называемые «слушателями» – listener), описанные в NFC Forum-TS-Analog-1.0 (папка 2.2.1, таблица 16).

При подключении к соответствующему генератору и усилителю мощности эталонного PCD от «Форума NFC» он позволяет посылать команды к PICC. Реакция PICC затем может быть зафиксирована и проанализирована посредством связанного измерительного оборудования.

Эталонный PCD от «Форума NFC» с тремя различными конструкциями антенных катушек основан на стандартном PCD класса 0 и двух компенсированных версиях антенных катушек PICC-3 и PICC-6, стандартизированных ISO/IEC. Эти катушки, называемые Poller-0, Poller-3 и Poller-6, представлены в соответствующем порядке слева-направо на рисунке 7.

Образцы конструкций PICC от «Форума NFC» определены с тремя проектными геометрическими формами антенной катушки. Геометрия катушек Listener-1, Listener-3 и Listener-6, как показано на рисунке 8 в порядке слева направо, основана на размерах внешней оболочки PICC-1, PICC-3 и PICC-6, утвержденных ISO/IEC.

Конструкции катушек на печатной плате не обязательно должны быть идентичными. Эталонный PICC «Форума NFC» позволяет анализировать сигнал, отправленный PCD. Для анализа частоты и формы этих сигналов эталонный PICC «Форума NFC» оснащен встроенной измерительной катушкой.

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

Эталонные конструкции «Форума NFC» следует использовать при тестировании и проверке устройства NFC в качестве эталона или ориентира, таким образом помогая разработчикам оптимизировать конструкции антенн.

Архитектура nfc

В архитектуре NFC есть несколько уровней. Самый низкий из них — физический, который реализован ЦПУ и другим аппаратным комплексом, через который происходит взаимодействие. В середине находятся данные о пакетах и транспортный уровень, затем формат данных уровней, и в конце программное обеспечение.

На физическом уровне NFC работает по алгоритму, описанному в ГОСТ для RFID (ГОСТ Р ИСО/МЭК 14443-2-2020), где говорится о маломощных радиосигналах частотой 13,56 МГц. Затем идёт уровень, который описывает разбивку потока данных на фреймы (ГОСТ Р ИСО/МЭК 14443-3-2020).

Любые радиоконтроллеры, которые используются в телефоне, планшете или подсоединяются к компьютеру или микроконтроллеру, являются отдельными аппаратными компонентами. Они взаимодействуют с главным процессором посредством одного или нескольких стандартных последовательных протоколов между устройствами: универсальный асинхронный приёмопередатчик (UART), последовательный периферийный интерфейс (SPI), последовательная шина данных для связи интегральных схем (I2C) или универсальная последовательная шина (USB).

Над этим находится несколько протоколов команд RFID, базирующихся на двух спецификациях. NFC чтение и запись меток базируется на оригинальном RFID ГОСТ Р ИСО/МЭК 14443A. Протоколы Philips/NXP Semiconductors Mifare Classic и Mifare Ultralight и NXP DESFire совместимы с ГОСТ Р ИСО/МЭК 14443A.

Обмен данными P2P NFC базируется на ГОСТ Р ИСО/МЭК 18092. Также на этом же стандарте базируются RFID-карты и метки Sony FeliCa, которые доступны в основном в Японии. Можно читать и записывать метки, основанные на этих стандартах, и не использовать NFC.

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

Атака nfcdrip использует nfc для передачи данных на сравнительно дальние дистанции

Глоссарий

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

Таблица 1. Терминология для технологии NFC

Извлекаем данные с карты

На Хабре уже есть статьи, подробно описывающие процесс взаимодействия карты и терминала (

), поэтому постараюсь не повторяться и сосредоточиться на практической части.

Для общения с картой будем использовать ридер PN532 из-за приятной цены и библиотеку libnfc. Плавно переходим к делу. Данные на карте организованы следующим образом: Окружения -> Приложения -> Файлы -> Записи.

Цель считывания – получить данные всех записей, для этого нужно пройти полную цепочку, причём выбор окружения и приложения происходит только один раз в начале общения. Тот же процесс в терминах EMV-команд:

• SELECT PPSE // Выбираем бесконтактное окружение
• SELECT APPLICATION // Выбираем приложение по AID
• READ RECORD // Указываем номер файла и записи

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

    byte_t const command[] = {
        0x40, 0x01, // Pn532 InDataExchange
        0x00, 0xA4, // SELECT ppse
        0x04, 0x00, // P1:By name, P2:_

        0x0e, // Lc: Data length
        0x32, 0x50, 0x41, 0x59, 0x2e, 0x53, 0x59, // Data string:
        0x53, 0x2e, 0x44, 0x44, 0x46, 0x30, 0x31, // 2PAY.SYS.DDF01 (PPSE)
        0x00 // Le
    };

Пример ответа:

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

Для вызова следующей команды нам потребуется разобрать ответ предыдущей команды.

Нас интересует идентификатор приложения AID. Запоминаем его и формируем новый SELECT запрос, но на этот раз передаём команде SELECT полученный AID, а не PPSE, как в первой команде.

Пример: 00 A4 04 00 07 A0 00 00 00 03 10 10 00

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

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

Пример формирования команды: (подробнее об этом можно почитать в стандарте. EMV Book1. 11.2 READ RECORD)

    byte_t const sfi_param = (sfi << 3) | (1 << 2);

    byte_t const command[] = {
        0x40, 0x01, // Pn532 InDataExchange
        0x00, 0xB2, // READ RECORD
        record_number, sfi_param, // P1:record_number and P2:SFI
        0x00 // Le
    };

Пример вызова:

00 B2 02 14 00

Заметим, что под номер файла отводится не полный байт, соответственно, всего файлов может быть 31 (2^5 — 1), а записей 255. Файлы с 1-го по 10-й отводятся для хранения внутренних данных, а оставшиеся отводятся под хранение лога транзакций, если карта поддерживает логирование.

Теперь используя два вложенных цикла, мы можем получить данные всех записей карты, вызывая для каждой пары команду READ RECORD. Процесс перебора можно существенно ускорить, если обращать внимание на возвращаемый картой status word (последние два байта ответа).

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

Фрагмент данных, извлечённых из записей карты:

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

Медленный способ

Для реализации медленного способа (атака потребует около 4 минут) необходимо переполнить внутренний счётчик транзакций карты (ATC). Для этого требуется вызвать:

• SELECT PPSE // Выбираем бесконтактное окружение
• SELECT APPLICATION // Выбираем приложение
• GET DATA // Узнаём, сколько осталось до переполнения ATC (Опционально)
• GET PROCESSING OPTIONS // Начинаем проводить транзакции
• …
• GET PROCESSING OPTIONS // Повторяем транзакции до переполнения

Рассмотрим шаги подробнее. Выбор бесконтактного окружения и приложения аналогичен пункту с извлечением данных, единственным отличием является то, что на этот раз нам потребуется обработать ответ команды SELECT APPLICATION.

Нас интересует поле PDOL, так как оно понадобится для последующего вызова команды GET PROCESSING OPTIONS, которая и будет увеличивать счётчик транзакций при каждом вызове.В PDOL-е карта просит от нас информацию о терминале и платеже.

В примере выше карта просит у нас:

• 9F66 04 // Terminal transaction qualifier (4 bytes)
• 9F02 06 // Amount (6 bytes)
• 9F37 04 // Unpredictable number (4 bytes)
• 5F2A 02 // Transaction Currency code (2 bytes)

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

(EMV Book 3. Annex A Data Elements Dictionary).

Для удобства практического использования привожу таблицу:

Сформировав данные, запрашиваемые картой, мы готовы к вызову GPO.

Пример: 80 A8 00 00 12 83 10 79 00 40 80 00 00 00 10 00 00 82 3D DE 7A 01 24 00

Ответ: 77 4F 82 02 20 00 94 0C 10 02 03 00 18 01 01 00 10 04 04 00 57 13 42 76 55 00 66 83 25 13 D2 00 52 01 14 89 36 20 00 00 1F 5F 20 02 20 2F 9F 10 07 06 01 11 03 80 20 00 9F 6C 02 30 00 9F 26 08 33 33 89 D5 70 A3 DF 37 9F 27 01 00 9F 36 02 02 48 90 00

Повторяем вызов GPO 65 536 раз, и карта блокируется. Можно уменьшить количество требуемых вызовов, если предварительно считать текущее значение ATC с помощью GET DATA.

Обновление по контроллера по nfc-каналу

Начальный загрузчик (bootstrap loader – BSL) позволяет осуществлять доступ к памяти MSP430 во время прототипирования, для обновления прошивки контроллера в готовом изделии и для сервисного обслуживания устройства. В то время как в младших сериях контроллеров семейства MSP430 BSL (рисунок 4) загрузчик располагается в ROM-памяти и доступен только для чтения, в сериях MSP430F5xx и MSP430F6xx загрузчик располагается в защищенной области FLASH-памяти [6]. Это не только обеспечивает ему защиту при стирании памяти, но и позволяет выполнять следующие задачи:

• использовать различные протоколы и интерфейсы, такие как UART, USB, SPI, I2C, NFC, и sub-1GHz;
• назначать различные события для запуска BSL, вплоть до нажатия кнопки;
• добавлять проверку целостности загружаемых или загруженных данных и кода, например, путем вычисления контрольной суммы (CRC);
• изменять скорость передачи данных.

Сам загрузчик состоит из трех основных частей:

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

Целевое устройство изначально находится в режиме пассивного ожидания, предусмотренного в TRF7970A при активировании режима Single Device Detection (SDD), что позволяет снизить требования к объему занимаемой памяти. Скорость данных при установлении соединения – 106 кбит/с.

Пакет запроса атрибутов и ответ на него (Attribute Request – ATR_REQ и Attribute Response – ATR_RES соответственно) завершают процесс установления соединения. Передача пакетов данных идет посредством посылаемых инициатором обмена запросов протокола Data Exchange Protocol (Data Exchange Protocol Requests – DEP_REQ), на которые целевое устройство отвечает подтверждениями (Data Exchange Protocol Responses – DEP_RES).

Скорость прошивки вполне сопоставима со скоростями работы через COM-порт (рисунок 5). (В примере задействованы отладочные платы MSP-EXP430F5529 и MSP-EXP430F5438 с подключенными к ним NFC-платами TRF7970ATB).

Передача данных nfc-v

Передача данных от VCD к VICC в режиме NFC-V. Передача сигналов данных от VCD к VICC в режиме NFC-V основана на 10%- или 100%-модуляции методом амплитудной манипуляции (ASK). Двоичное кодирование использует метод импульсно-позиционной модуляции (Pulse Position Modulation, PPM) «один-из-четырех» или «один-из-256».

На рисунке 14 показана передача данных от VCD к VICC с использованием кодирования методом PPM «один-из-четырех». Сигнал, в сущности, является интервалом, занимающим одну восьмую символьного периода. Один символ кодирует битовую пару. Импульс каждого из четырех значений битовой пары занимает временной интервал, зарезервированный для него в символьном периоде. Символы «Начало кадра» (SOF) и «Конец кадра» (EOF) располагаются в неиспользованных битовыми парами временных слотах.

Использование PPM для кодирования данных обеспечивает высокий коэффициент заполнения РЧ-поля, в особенности в случае системы «один-из-256». Это позволяет использовать высокий индекс модуляции, обеспечивая устойчивые сигналы передачи данных как в NFC-A, сохраняя при этом низкий уровень РЧ-энергии, как в режиме NFC-B.

Передача данных от VICC к VCD в режиме NFC-V. Передача сигналов данных от VICC к VCD в режиме NFC-V выполняется с 10%-модуляцией ASK, создавая поднесущую 424 кГц и амплитудную манипуляцию (OOK) на поднесущей. Для кодирования битового потока данных используется манчестерский код. Другой вариант технологии NFC-V основан на добавлении частотной манипуляции (FSK), чередуя две поднесущие – 424 и 484 кГц.

Для кодирования двоичного потока данных используется манчестерский код. В этом режиме скорость передачи данных немного изменяется. На рисунке 15 показано, как VICC передает данные к CD с использованием OOK. В случае использования FSK вместо OOK состояние выключенного периода поднесущей заменяется поднесущей на частоте 484 кГц.

Этот стандарт позволяет VCD и VICC выбирать наилучшие условия для коммуникации в соответствии с различными эксплуатационными требованиями, начиная от использования на ближнем расстоянии при высоком уровне РЧ-шума и заканчивая удаленным расстоянием при пониженном уровне РЧ-шума.

Типы меток

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

В таблице 3 представлен обзор типов NFC-меток. Скорость передачи данных выше 100 кбит/с, отображаемая в таблице 2, а также используемая в этом документе, округляется до ближайшего целого числа кбит/с.

Таблица 3. Типы NFC-меток

Метки типа 1 соответствуют требованиям ISO/IEC 14443A. Они способны работать в режиме чтения/записи и могут настраиваться пользователем для режима «только чтение». Размер памяти варьируется от 93 байт до 2 кбайт, а скорость коммуникации или передачи данных составляет 106 кбит/с. Метки типа 1 не поддерживают механизм предотвращения конфликтов.

Метки типа 2 соответствуют требованиям ISO/IEC 14443A. Они способны работать в режиме чтения/записи и могут настраиваться пользователем для режима «только чтение». Размер памяти варьируется от 48 байт до 2 кбайт, а скорость коммуникации или передачи данных составляет 106 кбит/с. Метки типа 2 поддерживают механизм предотвращения конфликтов.

Метки типа 3 соответствуют стандартам ISO/IEC 18092 и JIS X 6319-4 за исключением поддержки шифрования и аутентификации. Даже если имеется возможность чтения/записи, метка типа 3 может быть настроена на режим «только чтение». В процессе эксплуатации метки типа 3 может использоваться специальное сервисное оборудование для повторной записи данных.

Метки типа 4 соответствуют стандарту ISO/IEC 14443 версий A/B. Режим работы метки типа 4 «только для чтения» устанавливается на заводе-изготовителе, и для обновления данных метки требуется специальное сервисное оборудование. Размер памяти метки типа 4 — до 32 кбайт, а скорость передачи данных составляет 106 кбит/с, 212 кбит/с и 424 кбит/с. Метки типа 4 поддерживают механизм предотвращения конфликтов.

Метки типа 5 (NFC-V) недавно были добавлены в спецификацию «Форума NFC». Такая метка основана на стандарте ISO/IEC 15693, содержит более 64 кбайт памяти, поддерживает скорость передачи данных 26,48 кбит/с и механизм предотвращения конфликтов.

Транспондеры серии rf430frl15xh

RF430FRL15xH [7, 8] является транспондером диапазона 13,56 МГц со встроенным 16-битным малопотребляющим контроллером MSP430 (рисунок 6). Для хранения программы и данных используется энергонезависимая оперативная память технологии FRAM.

FRAM эффективна в NFC-приложениях благодаря высокой скорости работы и низкому энергопотреблению в сочетании с сохранением данных при выключении питания. Энергонезависимость встроенной FRAM-памяти RF430FRL15xH позволяет свободно применять данный транспондер и в приложениях с автономным питанием, и в приложениях с питанием за счет внешнего электромагнитного поля считывателя.

RF430FRL15xH поддерживает обмен данными, установку параметров и конфигурирование посредством беспроводного интерфейса (стандарты ISO/IEC 15693, ISO18000-3), а также при помощи SPI- или I2C-интерфейса.

Встроенный датчик температуры, малопотребляющий 14-битный АЦП, два конфигурируемых аналоговых усилителя позволяют применять RF430FRL15xH в качестве самостоятельного сенсорного узла, обслуживающего как цифровые, так и аналоговые датчики.

Основные возможности транспондера:

• радиоинтерфейс ISO/IEC 15693, ISO/IEC 18000-3 (Mode 1);
• выбор источника питания: внешний источник питания или электромагнитное поле;
• встроенный датчик температуры, интерфейс к резистивному датчику;
• 16-битный блок вычисления контрольной суммы (CRC);
• микроконтроллерное ядро MSP430 (2 кбайта FRAM, 4 кбайта ОЗУ, 8 кбайт ПЗУ);
• напряжение питания – 1,45…1,65 В (ток потребления 260 мкА/МГц, в режимах экономии энергии – 9…15 мкА);
• несколько источников тактирования (4 МГц, 256 кГц, внешний тактовый сигнал);
• интерфейсный модуль eUSCI, поддерживающий SPI и I2C;
• отладочный интерфейс JTAG.

Транспондеры серии trf796xa

Микросхемы TRF796xA и TRF7970A [5] являются высокопроизводительными приемопередатчиками диапазона 13,56 МГц со встроенными устройствами формирования пакетов с поддержкой стандартов ISO/IEC 15693, ISO/IEC 18000-3, ISO/IEC 14443A и B (рисунок 3).

TRF7970A, как наиболее современный представитель семейства трансиверов TRF79xxA, поддерживает NFC-стандарты NFCIP-1 (ISO/IEC 18092) и NFCIP-2 (ISO/IEC 21481).

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

Широкий диапазон допустимых напряжений питания 2,7…5,5 В допускает применение транспондера в устройствах с различными уровнями напряжений – и в устройствах с логическими уровнями 3 В, и с устройствами 5 В. Также возможна работа транспондера при сильно разряженной батарее питания.

Приемопередатчик TRF79xxA позволяет реализовывать различные протоколы обмена для диапазона 13,56 МГц, включая нестандартные.

Основные возможности:

• поддержка стандартов ISO 14443A, ISO 14443B, ISO 15693, ISO/IEC 18000-3 (Mode 1);
• диапазон напряжений питания 2,7…5,5 В;
• встроенный стабилизатор питания (выходной ток до 20 мА);
• потребление в режиме ожидания – 120 мкА, в режиме сна – менее 1 мкА;
• параллельный или последовательный (SPI) интерфейс с хост-системой;
• встроенные блоки формирования пакетов, проверки контрольной суммы, контроля четности;
• скорость передачи данных – до 848 кбит/с;
• тактовый выход для хост-контроллера;
• программируемый антенный усилитель;
• выходной усилитель с поддержкой OOK- или ASK-модуляции;
• программируемая выходная мощность – 100 или 200 мВт;
• прием и декодирование нескольких поднесущих.

Читаем ndef-сообщение

Когда телефон на Android считывает NFC-метку, он сначала её обрабатывает и распознает, а затем передаёт данные о ней в соответствующее приложение для последующего создания intent. Если с NFC может работать больше одного приложения, то появится меню выбора приложения. Система распознавания определяется тремя intent, которые перечислены в порядке важности от самой высокой до низкой:

1. ACTION_NDEF_DISCOVERED: Этот intent используется для запуска аctivity, если в метке содержится NDEF-сообщение. Он имеет самый высокий приоритет, и система будет запускать его в первую очередь.
2. ACTION_TECH_DISCOVERED: Если никаких activity для intent ACTION_NDEF_DISCOVERED не зарегистрировано, то система распознавания попробует запустить приложение с этим intent. Также этот intent будет сразу запущен, если найденное NDEF-сообщение не подходит под MIME-тип или URI, или метка совсем не содержит сообщения.
3. ACTION_TAG_DISCOVERED: Этот intent будет запущен, если два предыдущих intent не сработали.

В общем случае система распознавания работает, как представлено на рисунке ниже.

Когда это возможно, запускается intent ACTION_NDEF_DISCOVERED, потому что он наиболее специфичный из трёх. Более того, с его помощью можно будет запустить ваше приложение.

Если activity запускается из-за NFC intent, то можно получить информацию с отсканированной NFC-метки из этого intent. Intent может содержать следующие дополнительные поля (зависит от типа отсканированной метки):

• EXTRA_TAG (обязательное): объект Tag, описывающий отсканированную метку.
• EXTRA_NDEF_MESSAGES (опциональное): Массив NDEF-сообщений, просчитанный с метки. Это дополнительное поле присуще только intent ACTION_NDEF_DISCOVERED.
• EXTRA_ID (опциональное): Низкоуровневый идентификатор метки.

Ниже представлен пример, проверяющий intent ACTION_NDEF_DISCOVERED и получающий NDEF-сообщения из дополнительного поля.

Kotlin

override fun onNewIntent(intent: Intent) {
    super.onNewIntent(intent)
    ...
    if (NfcAdapter.ACTION_NDEF_DISCOVERED == intent.action) {
        intent.getParcelableArrayExtra(NfcAdapter.EXTRA_NDEF_MESSAGES)?.also { rawMessages ->
            val messages: List = rawMessages.map { it as NdefMessage }
            // Обработка массива сообщений.
            ...
        }
    }
}

Java

@Override
protected void onNewIntent(Intent intent) {
    super.onNewIntent(intent);
    ...
    if (NfcAdapter.ACTION_NDEF_DISCOVERED.equals(intent.getAction())) {
        Parcelable[] rawMessages =
            intent.getParcelableArrayExtra(NfcAdapter.EXTRA_NDEF_MESSAGES);
        if (rawMessages != null) {
            NdefMessage[] messages = new NdefMessage[rawMessages.length];
            for (int i = 0; i < rawMessages.length; i  ) {
                messages[i] = (NdefMessage) rawMessages[i];
            }
            // Обработка массива сообщений.
            ...
        }
    }
}

Также объект Tag можно получить из intent, который будет содержать полезную информацию и позволит перечислить технологии метки:

Kotlin

val tag: Tag = intent.getParcelableExtra(NfcAdapter.EXTRA_TAG)

Java

Tag tag = intent.getParcelableExtra(NfcAdapter.EXTRA_TAG);