Xamarin.Forms — простой пример Host-based Card Emulation / Хабр

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

EMV — это международный стандарт для банковских карт с чипом. В разработке этого стандарта принимали участия

uropay

asterCard

ISA, отсюда и название. Попробуем разобраться, как же все таки карта общается с POS-терминалом по бесконтактному интерфейсу.

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

Бесконтактная EMV карта на физическом уровне работает почти так же, как и RFID метка. Если базисно то, чип попадает в электромагнитное поле, а в замкнутом проводящем контуре (в нашем случае это будет антенна, расположенная по периметру), помещенном в переменное магнитное поле, образуется переменный электрический ток.

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

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

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

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

Также еще напомню немного терминологии, для тех, кто не знаком.

POS-терминал (Point of Sale) — устройство продавца, которое считывает карту и инициирует платеж. Далее будем называть это устройство просто терминалом. Банк эмитент — это банк, который выпустил вашу карту.Банк эквайер — банк, который выдает продавцам POS-терминалы и обрабатывает платежи с них.

Платежная система — центральное звено между банком эквайером и банком эмитентом, через нее проходят абсолютно все платежи, и она знает какой банк какому сколько должен перевести денег. Платежных систем в мире не мало, кроме всем известных Visa и MasterCard есть ещё и American Express, China UnionPay и российская платежная система МИР.

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

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

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

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

Что бы в этом разобраться терминал посылает команду SELECT. Например, AID карты Visa Classic будет выглядеть следующим образом: A0000000031010. Если в ответ придет несколько таких кодов и терминал умеет работать с несколькими приложениями, то терминал выведет на экран список и предложит выбрать нужное нам приложение. Если терминал не поддерживает ни один из кодов приложений, то операция будет отклонена терминалом.

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

На этом этапе EMV-транзакция может быть отменена по инициативе самой карты, если данный тип операции запрещен в данной стране мира эмитентом. Далее карта передает терминалу набор специально структурированной информации, содержащей описание функциональности карты и приложения.

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

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

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

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

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

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

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

Эти методы также построены на основе PKI. SDA это просто подписанные данные на приватном ключе банка эмитента, DDA — терминал посылает какое-то случайное число и карточка должна подписать его, используя свой приватный ключ, а терминал проверит эту подпись используя полученный ранее сертификат карты, таким образом терминал удостовериться в том, что карточка и правда обладает приватным ключом — следовательно является подлинной. CDA это просто комбинация обоих способов.

Обработка ограничений. Здесь терминал проверяет полученные ранее данные с карты на условие пригодности для данной операции. Например, проверяет срок начала/окончания действия приложения Application Expiration Date (Tag ‘5F24’) и Application Effective Date (Tag ‘5F25’).

Также производится проверка версии приложения. Результаты операций, проводимых на данном этапе, также записываются в отчет TVR (Terminal verification results). По результатам этого этапа транзакция не может быть отменена, даже в случае, если, например, срок действия приложения истек.

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

Список поддерживаемых методов верификации:

Вот

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

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

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

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

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

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

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

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

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

Делаем rfid-эмулятор

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

, фотографии мои.

Вот такой миниатюрный таракан, вполне может эмулировать метку

Сайт проекта . Код очень интересен, можно сказать гениален и лаконичен (используется ассемблер). Остановимся на нём подробно. Его мы и разберём. Ознакомиться с кодом можно вот тут.

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

Катушка индуктивности около 1 мкГн и микроконтроллер ATtiny85

Вот это дамы и господа и есть настоящее Хакерство, когда уровень понимания особенностей работы оборудования позволяет создавать технические решения, выходящие за рамки, обозначенные производителем! И это работает, проверено лично. Вот истинное значение слова «хакер», это не про взлом и воровство.

Забегая вперёд скажу, что данной катушки для нормальной работы недостаточно, и всё же пришлось cделать нормальную антенну, повесить конденсаторы по питанию, резонансный конденсатор. Но вот для демонстрации принципов работы вполне подойдёт.Как же это работает:

Катушка фактически питает микроконтроллер AVR через контакты ввода/вывода. Каждый такой контроллер имеет диоды на портах ввода/вывода, которые предотвращает повышение напряжения на этом выводе выше напряжения питания микросхемы или опускание уровня сигнала ниже уровня земли. Они используются также для предотвращения статического пробоя, который приводит к выходу из строя микросхемы. При поднесении катушки к считывателю, в ней наводится ЭДС равная нескольким вольтам. Когда напряжение на катушке превышает напряжение питания контроллера, то часть этой энергии через эти ограничивающие диоды передаются к шине питания микросхемы. В результате получается, что микроконтроллер получает питание. А верх и низ синусоидальной волны усекается, и сигнал становится более похож на прямоугольный меандр.
Фильтрация питания с использованием ёмкости кристалла AVR. Обычно, когда ставят микросхему, то ставят конденсаторы по питанию, для фильтрации помех (обычно 0,1 мкФ керамику и электролит параллельно). В данном решении фильтрация осуществляется только внутренней ёмкостью шин питания в кремниевом кристалле микроконтроллера AVR. Она небольшая, но даже её достаточно для стабильного питания и работы, при питании от импульсов с частотой 125кГц!
Работа осуществляется при очень низком напряжении. Микроконтроллер ATtiny85 предназначен для работы при напряжении всего 2,5 В. Существует версия с расширенным диапазоном напряжений до 1,8 В. При этих напряжениях обычные тактовые генераторы AVR не работают, но этого можно избежать применив следующий хак…
Катушка индуктивности применяется не только для питания микросхемы, но ещё и для тактирования микроконтроллера! Выше мы говорили, что получаем прямоугольную волну, которая остаётся после того как ограничивающие диоды забрали немного энергии. Эта форма волны является входом Clock нашего микроконтроллера! И весь код работает на частоте 125 кГц, синхронно с несущей частотой считывателя RFID. Это гениально, ребята!
Прошивка? На таких низких скоростях микропрограммное обеспечение микросхемы больше похоже на последовательность операций ввода-вывода, выполняемых синхронно с каждым тактовым циклом несущей. Но остается много лишних циклов. В протоколе EM4102 вы потенциально можете выполнить некоторую полезную работу с 32 тактовыми циклами между каждым битом. Однако с протоколом HID вам необходимо выводить фронт FSK каждые 4 тактовых цикла. В результате прошивка на RFID-метке крайне тупая. «Исходный код» на самом деле представляет собой просто набор причудливых макросов ассемблера, которые преобразуют код метки RFID в длинную последовательность инструкций ввода-вывода.

Прежде чем мы пойдём разбирать код данного эмулятора давайте сделаем ему нормальную антенну. Мои эксперименты с текущей схемотехникой выявили крайнюю нестабильность её работы. Она работает только совсем рядом со считывателем и то не всегда. Поэтому сначала я припаял конденсатор 0,1 мкФ на ножки питания контроллера, а потом решил сделать настоящий большой колебательный контур, как в настоящей метке.

Первая модификация — конденсатор 0,1 мкФ по питанию

Клонируем карту mastercard в режиме magstripe

Перейдем непосредственно к принципу клонирования. Данный метод атаки на бесконтактные карты был опубликован двумя исследователями

из Австрийского университета. В его основе лежит общий принцип, который называется

Skimming

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

(MasterCard PayPass M/Chip)MagStripe (MasterCard PayPass MagStripe)

режим.

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

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

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

Карта поддерживает специальную команду COMPUTE CRYPTOGRAPHIC CHECKSUM, аргументом которой являются данные, определенные в объекте Unpredictable Number Data Object (UDOL).

В результате карта с помощью алгоритма 3DES и секретного ключа вычисляет динамическую величину CVC3 (Card Verification Code).

В качестве аргумента функции 3DES используется конкатенация данных UDOL и счетчика транзакции (Application Transaction Counter,ATC).

Таким образом, значение величины CVC3 всегда зависит от объектов UN и ATC.

Другими словами, эта команда нужна, чтобы карта сгенерировала некую “подпись” для того, чтобы эмитент мог верифицировать карту. Однако, в этой подписи отсутствует подпись самой транзакции. В подписи содержатся значения ATC — 2 байта, CVC3 (Track1)

— 2 байта, CVC3 (Track2) — 2 байта, которые генерируются картой на основе секретного ключа, который также знает банк-эмитент и счетчика транзакций (ATC). При этом также для генерации подписи POS-терминал сообщает карте UN (Unpredictable Number)

— 4 байта, который также используется в генерации подписи. Unpredictable Number препятствует формированию кодов аутентификации на реальной карте для последующего использования в мошеннических транзакциях. Для атаки нам сильно мешает UN, поскольку 4 байта не представляется возможным перебрать, не выйдя за пределы счетчика транзакций. Однако, в спецификации этого есть некоторые слабости.

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

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

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

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

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

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

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

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

Теперь давайте попробуем все это преобразовать в код. Приложение будем писать на языке 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 split(): ByteArray {
    	return getHexString().hexToByteArray()
	}
 
	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(»d”, i)}”.replace(“..(?!$)”.toRegex(), “$0 “). И не забываем выполнять GET_PROCESSING_OPTIONS каждый раз перед COMPUTE_CRYPTOGRAPHIC_CHECKSUM иначе чек сумма подсчитываться не будет.

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

Пробежимся по коду

Давайте кратенько пробежимся по коду, который можно посмотреть

. Там пример эмуляции двух типов карт, я разберу только EM4102.

Перво-наперво, как гласит код, нам при прошивке микроконтроллера надо прошить fuse-биты в значение lfuse to 0xC0: таким образом, чтобы контроллер тактировался от внешнего генератора. Обращаю внимание, что любая перепрошивка контроллера будет сопряжена с тем, что его надо будет тактировать от внешнего источника, так как мы устанавливаем fuse биты с генерацией от внешнего генератора!

Весь код основан на макросах. Напомню, что такое макросы — это программа, которая подготавливает код к компиляции. Наша программа состоит всего из нескольких ассемблеровских инструкций: rjmp, call (2 такта), nop, ldi, out и ret (все по 1 такту)! Всё, весь остальной код формируется макросами в зависимости от макроса серийного номера (дефайна).

Особенность работы в том, что у нас достаточно мало тактов для нормальной работы. Попробуй успей за 32 такта сделать что-то, учитывая что инструкции перехода в контроллере AVR занимают 2 такта. Поэтому весь код генерируют макросы в зависимости от ID-карты.

#define FORMAT_IS_EM4102
#define EM4102_MFR_ID		0x12
#define EM4102_UNIQUE_ID	0x3456789A

Дефайнами задаём какой тип карты мы эмулируем и задаём ID-карты. Это главный макрос, на основании которого и формируется остальной код. И, тадам, его величество макросы.

    .macro	delay cycles
    .if cycles > 1
    rjmp	. 0
    delay	(cycles - 2)
    .elseif cycles > 0
    nop
    delay	(cycles - 1)
    .endif
    .endm

Макрос задержки, принимает на вход количество тактов задержки. Достаточно очевидный рекурсивный макрос, осуществляет задержку с помощью команды nop (нет операции, 1 такт) и команды rjmp . 0 (перейти на следующую строку, 2 такта). Комбинируя эти команды между собой, можно сделать задержку нужной длинны в тактах. По сути код ничего не делает, только тратит машинное время.

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

Рекурсивный макрос кодирования манчестер-кодом.

    .macro	manchester bit, count=1
    .if		count
    manchester (bit >> 1), (count - 1)
    .if		bit & 1
    baseband_1
    baseband_0
    .else
    baseband_0
    baseband_1
    .endif
    .endif
    .endm

    .macro	stop_bit
    baseband_0
    baseband_1_last
    .endm

Собственно тут и осуществляется вся логика. Принимает на вход битовую маску и счётчик битов. Если счётчик не нуль, то вызываем ещё раз сами себя, декрементируя счётчик (рекурсивный макрос, ага). Далее в самом теле идут вызовы макросов baseband_0, baseband_1 и baseband_1_last.

Помните выше я приводил таблицу в статье, как идёт кодирование содержимого карты, где идут биты чётности, и стоп биты в конце. Так вот, наша задача теперь ID-метки закодировать этим методом, для этого у нас существуют два макроса.

#define ROW_PARITY(n)  ( (((n) & 0xF) << 1) | 
                         (((n) ^ ((n) >> 1) ^ ((n) >> 2) ^ ((n) >> 3)) & 1) )

#define COLUMN_PARITY  ( (EM4102_MFR_ID >> 4) ^        
                         (EM4102_MFR_ID) ^             
                         (EM4102_UNIQUE_ID >> 28) ^    
                         (EM4102_UNIQUE_ID >> 24) ^    
                         (EM4102_UNIQUE_ID >> 20) ^    
                         (EM4102_UNIQUE_ID >> 16) ^    
                         (EM4102_UNIQUE_ID >> 12) ^    
                         (EM4102_UNIQUE_ID >> 8) ^     
                         (EM4102_UNIQUE_ID >> 4) ^     
                         (EM4102_UNIQUE_ID) )

ROW_PARITY — расчёт бита чётности в строке из четырёх бит, COLUMN_PARITY — расчёт контрольной суммы всей посылки.

Вся логика работы у нас описывается в макросе в .main

        header
        manchester	ROW_PARITY(EM4102_MFR_ID >> 4), 5
        manchester	ROW_PARITY(EM4102_MFR_ID >> 0), 5
        manchester	ROW_PARITY(EM4102_UNIQUE_ID >> 28), 5
        manchester	ROW_PARITY(EM4102_UNIQUE_ID >> 24), 5
        manchester	ROW_PARITY(EM4102_UNIQUE_ID >> 20), 5
        manchester	ROW_PARITY(EM4102_UNIQUE_ID >> 16), 5
        manchester	ROW_PARITY(EM4102_UNIQUE_ID >> 12), 5
        manchester	ROW_PARITY(EM4102_UNIQUE_ID >> 8), 5
        manchester	ROW_PARITY(EM4102_UNIQUE_ID >> 4), 5
        manchester	ROW_PARITY(EM4102_UNIQUE_ID >> 0), 5
        manchester	COLUMN_PARITY, 4
        stop_bit

Ну то есть, так же точно передаём заголовочные 9 бит, потом манчестер кодинг, высчитывая бит чётности для каждых 4-х бит, в конце контрольная сумма и стоп бит.

Осталось разобраться, что же такое baseband. Для этого у нас служат ещё одни макросы обёртки (да сколько можно-то, а?).

        .macro baseband_0
        rcall	baseband30_0
        rjmp	. 0
        .endm

        .macro baseband_1
        rcall	baseband30_1
        rjmp	. 0
        .endm
        
        .macro baseband_1_last
        rcall	baseband30_1
        rjmp	main
        .endm

        .macro header
        manchester 0x1FF, 9
        .endm

Макросы baseband* — выполняют ассемблеровский код: вызывают соответствующие функции, и потом делают переход на другую команду. Макрос baseband_1_last — аналогична макросу baseband_1, кроме того что делает безусловный переход не на команду ниже, а в начало функции main.

Последнее, что осталось разобрать — это функции baseband30_0 и baseband30_1. Они описываются следующим кодом.

baseband30_0:
        ldi	r16, OUT_PINS		// 1
        rjmp	baseband30		// 2

        /*
         * Emit a 1 at the baseband layer.
         * Takes a total of 30 clock cycles, including call overhead.
         */
baseband30_1:
        ldi	r16, 0			// 1
        rjmp	baseband30		// 2
        
        /*
         * Internal routine for baseband32_0 and _1. Must use
         * a total of 24 clock cycles. (32 - 1 ldi - 2 rjmp - 3 rcall)
         */ 
baseband30:
        out	_SFR_IO_ADDR(DDRB), r16		// 1
        delay	19				// 19
        ret					// 4

В зависимости от того, какая функция вызывается baseband30_0 или baseband30_1 в регистр r16 записывается значение того что должно быть на пине ввода/вывода: 1 или 0. После этого идёт безусловный переход на baseband30 осуществляется вывод и задержка на 19 тактов, после чего идёт возврат.

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

Давайте его скорее скомпилируем и посмотрим как он выглядит, как развернутся все эти макросы. Компилируем командой make (предварительно установив avr-gcc) и дизассемблируем получившийся elf-файл

00000000 __vectors:
   0:	0e c0       	rjmp	. 28     	; 0x1e __ctors_end
   2:	15 c0       	rjmp	. 42     	; 0x2e __bad_interrupt
...

Вначале у нас вектора прерываний, но нас интересует только первый jump. Так как остальные вектора никуда не ведут.

0000001e __ctors_end:
  1e:	11 24       	eor	r1, r1
  20:	1f be       	out	0x3f, r1	; 63
  22:	cf e5       	ldi	r28, 0x5F	; 95
  24:	d2 e0       	ldi	r29, 0x02	; 2
  26:	de bf       	out	0x3e, r29	; 62
  28:	cd bf       	out	0x3d, r28	; 61
  2a:	02 d0       	rcall	. 4      	; 0x30 main
  2c:	11 c1       	rjmp	. 546    	; 0x250 _exit

Здесь мы настраиваем порты ввода/вывода, и вызываем функцию main. A main состоит из безумного количества вызовов функций baseband30* и jump (так развернулся наша адский цирк макросов).

00000030 main:
  30:	01 d1       	rcall	. 514    	; 0x234 baseband30_1
  32:	00 c0       	rjmp	. 0      	; 0x34 main 0x4
  34:	fd d0       	rcall	. 506    	; 0x230 baseband30_0
  36:	00 c0       	rjmp	. 0      	; 0x38 main 0x8
  38:	fd d0       	rcall	. 506    	; 0x234 baseband30_1
  3a:	00 c0       	rjmp	. 0      	; 0x3c main 0xc
  3c:	f9 d0       	rcall	. 498    	; 0x230 baseband30_0
  3e:	00 c0       	rjmp	. 0      	; 0x40 main 0x10
  40:	f9 d0       	rcall	. 498    	; 0x234 baseband30_1
  42:	00 c0       	rjmp	. 0      	; 0x44 main 0x14
  44:	f5 d0       	rcall	. 490    	; 0x230 baseband30_0
  46:	00 c0       	rjmp	. 0      	; 0x48 main 0x18
  48:	f5 d0       	rcall	. 490    	; 0x234 baseband30_1
  4a:	00 c0       	rjmp	. 0      	; 0x4c main 0x1c
  4c:	f1 d0       	rcall	. 482    	; 0x230 baseband30_0
...
 22e:	00 cf       	rjmp	.-512    	; 0x30 main

И так далее… пока не джампнемся снова на main

Ну и глянем как же выглядит наш baseband модуль.

00000230 baseband30_0:
 230:	08 e1       	ldi	r16, 0x18	; 24
 232:	02 c0       	rjmp	. 4      	; 0x238 baseband30

00000234 baseband30_1:
 234:	00 e0       	ldi	r16, 0x00	; 0
 236:	00 c0       	rjmp	. 0      	; 0x238 baseband30

00000238 baseband30:
 238:	07 bb       	out	0x17, r16	; 23
 23a:	00 c0       	rjmp	. 0      	; 0x23c baseband30 0x4
 23c:	00 c0       	rjmp	. 0      	; 0x23e baseband30 0x6
 23e:	00 c0       	rjmp	. 0      	; 0x240 baseband30 0x8
 240:	00 c0       	rjmp	. 0      	; 0x242 baseband30 0xa
 242:	00 c0       	rjmp	. 0      	; 0x244 baseband30 0xc
 244:	00 c0       	rjmp	. 0      	; 0x246 baseband30 0xe
 246:	00 c0       	rjmp	. 0      	; 0x248 baseband30 0x10
 248:	00 c0       	rjmp	. 0      	; 0x24a baseband30 0x12
 24a:	00 c0       	rjmp	. 0      	; 0x24c baseband30 0x14
 24c:	00 00       	nop
 24e:	08 95       	ret

В конце видно как delay развернулся в список jump и nop для задержки. Вот такая красивая магия.

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

Создание антенны

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

Собрать и настроить антенну очень просто, прямо как в картинке из [1].

Для расчёта антенны надо вспомнить немного теории. Нам необходимо сделать колебательный контур, который будет настроен на частоту 125 кГц. Откроем курс Теоретических Основ Электротехники и прочитаем, что же такое колебательный контур:

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

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

Где

— частота колебаний,

— индуктивность катушки,

— ёмкость конденсатора.

В данном случае у нас есть фиксированный параметр — частота, а с ёмкостью и индуктивностью мы можем играться. Для того чтобы рассчитать катушку, воспользуемся документом [2]. Все кто хоть как-то собираются делать антенны для RFID меток (любых частот), обязаны с ним ознакомиться!

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

В результате выбираю размер будущей катушки индуктивности практически такой же, как стоит в настоящей метке, то есть примерно 70х40 мм. Если конденсатор выбрать 10 нФ, то индуктивность катушки (из формулы выше), должна составлять у нас 162 мкГн.

Как видим параметры толщины и ширины катушки у нас неизвестные и изменяемые (упираются в толщину провода 0,2 мм), но общие прикидки мне дали цифру в 42 витка. Можно было бы сделать несколько итераций, и сделать прям точный-точный расчёт, но в нашем штучном случае, и так сойдёт.

После чего, необходимо изготовить каркас 70х40 мм для намотки катушки. Его я изготовил из текстолита и на него намотал катушку.

Каркас из текстолитаНамотка и готовая катушка

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

Начнём подбор резонансного конденсатора

Сначала я проверил конденсатор емкостью 10 нФ, который должен быть резонансным. Но амплитуда сигнала сразу просела, по сравнению с пустой катушкой. Тогда я взял конденсатор меньшего номинала. И так перебирал конденсаторы, пока не поймал резонанс. Таким образом резонансная ёмкость конденсатора составила 3,2 нФ.

Сигнал без конденсатора, пустая катушкаСигнал 10 нФ1 нФ, 2 нФ3 нФ, 4 нФ, 2,2 нФ3,2 нФ

Видно, что пробовал разные варианты, и было ясно что максимум лежит где-то между 3 и 4 нФ и результатом стал конденсатор 3,2 нФ (состоящий из двух конденсаторов в параллели). Всё, наша катушка готова к дальнейшим опытам.

Вообще, хочу заметить, что катушку можно сделать вообще в виде дорожек на печатной плате, и при небольшой серии изделий так и стоит делать. Вот, пример такой платы, именно на 125 кГц от Alexander Guthmann. К сожалению, сайт практически умер, а автор давно не выходит на связь, так что довольствуемся только моими фото. Если кто поможет его найти, буду признателен! Не знаю что с ним случилось.

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

, сможете рассчитать такое самостоятельно, раз это смог сделать четырнадцатилетний немецкий школьник.

Физический контроль доступа

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

В течение последних нескольких лет индустрией были предприняты серьезные усилия по обновлению этой инфраструктуры и переходу от поддержки только RFID оборудования низкочастотного диапазона к более функциональным высокочастотным устройствам, совместимым с ISO / IEC 14443.

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

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

Современные облачные сервисы позволяют поставщикам продуктов и услуг доступа просто и безопасно портировать свои приложения для смарт-карт на смартфоны. Все права и функции, связанные с бесконтактной картой контроля доступа, могут обрабатываться смартфоном.Смартфоны, поддерживающие NFC, могут хранить и предоставлять учетные данные доступа считывателям, которые поддерживают карты бесконтактного доступа, соответствующие ISO / IEC 14443. Учетные данные могут быть сгенерированы в режиме реального времени и храниться в SE или в приложении с поддержкой HCE.Смартфон, среди прочих функций, становится устройством открывания дверей, электронным билетом или системой отслеживания пользователей и посещаемости.Контроль доступа на основе NFC катастрофически удобен для управления физическим доступом для большого количества территориально распределенных объектов.

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

В том числе огромным преимуществом использования смартфона с NFC в качестве ключа, является возможность использования замков, для которых источником питания будет выступать смартфон в момент идентификаций передающий на замок достаточно питания для его разблокировки.РеализацияЧастично реализация физического контроля доступа описана в пункте «Гостиничный бизнес».

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

ПроблемыКроме проблем, описанных в разделе «Гостиничный бизнес», есть еще несколько.Поддержка NFC производителями смартфонов до сих пор относится к аппаратам премиум-сегмента. Кроме того, некоторые телефоны имеют неоптимальное расположение и дизайн антенны, что дает в результате низкое качество считывания.

Поэтому технология NFC используется в связке с Bluetooth в качестве бесконтактного протокола. Bluetooth доступен практически на всех смартфонах, у этого протокола больший радиус действия. И производители оборудования систем контроля доступа включают поддержку Bluetooth в дополнение к стандарту ISO / IEC 14443 и NFC.