Comments 65
Так всетки, есть шанс появления FlipperPay, или это слишком невозможно реализовать?
Для этого нужен Secure Element, отдельный чип которого в Флиппере нет.
Плюс сертификации EMV и контракты с банками - а это самое сложное.
а хотя бы ради интереса зондировали эту тему?
просто интересно сколько времени денег и нервов надо потратить чтобы сделать свой ProductnamePay
Но для того, чтобы это работало на Флиппере нужно будет затащить целиком все протоколы, в том числе проприетарные расширения VISA, MASTERCARD и т.д. в прошивку Флиппера. Это довольно большая работа, которую непонятно зачем делать, учитывая что воспользоваться такой функцией сможет полтора человека.
Там, насколько я помню, даже есть прямое подключение NFC чипа к симке.
Этот протокол тоже задумывался для платежей с помощью телефона, но не полетел. В итоге сейчас почти не используется. Мобильные операторы Мегафон, Билайн, МТС, выпускают такие сим-карты, они работаю для технологии «мобильный билет», для оплаты в метро прямо со счета мобильного оператора. Но об этой функции почти никто не знает. У МТС были попытки использовать этот протокол для создания виртуальных банковских карт внутри SIM-карты.
Копипаст моего старого комментария:
Эта технология не имеет маркетингового названия. Такие сим-карты есть у операторов Мегафон/МТС/Билайн. В Москве, например, они используются как транспортный проездной для метро и автобусов. Эту технологию уже несколько лет поддерживают смартфоны на Android.
Принцип таков: сим-карта подключается к NFC модулю который выполняет физическую модуляцию радиосигнала, при этом данные передает сама sim-карта.
На физическом уровне это работает через протокол SWP (Single wire protocol), не путать с 1-Wire en.wikipedia.org/wiki/Single_Wire_Protocol
Стандарты SWP открыты:
www.etsi.org/deliver/etsi_ts/102600_102699/102613/11.00.00_60/ts_102613v110000p.pdf
www.etsi.org/deliver/etsi_ts/102600_102699/102622/12.01.00_60/ts_102622v120100p.pdf
На пальцах это работает так — контактная площадка sim-карты (iso7816) имеет 8 контактов. В наших сим-картах обычно используется только 6 контактов (C4 и C8 отсутствуют).
Контакт C6 используется для SWP, при этом он независим от всей остальной логики сим-карты. То есть подав только питание на сим-карту и подключив C6 к радиомодулю поддерживающему SWP, можно пользоваться.
Вот как выглядит принципиальная схема из стандарта
При этом связь дуплексная, то есть по одному контакту данные передаются в обе стороны синхронно.
Здесь упрощенно описано как работает SWP на физическом уровне hilbert-space.de/?p=93
Лучше посмотреть эту ссылку, так будет понятнее.
Дальше я очень слабо разбираюсь, поэтому могу писать глупо.
Как я понимаю, сигнал S1, от NFC модуля к сим-карте (от Master CLF к Slave UICC) модулируется с помощью напряжения, как обычно.
При этом сигнал S2 от сим-карты к радиомодулю модулируется с помощью сопротивления (нагрузки?) которую генерирует сим-карта в момент когда на контакте C6 значение High. Радиомодуль в момент передачи сигнала S1 меряет сопротивление и расчитывает сигнал S2.
Я хочу повторить схему сниффера описанную здесь hilbert-space.de/?p=168
Но я плохо понимаю что именно в ней происходит. В идеале хотелось бы сделать полноценную печатную плату.
В качестве NFC чипа (он же CLF, Master S1) я использую внешнюю NFC антенну. Она устанавливается как прокладка между оригинальной сим-картой и телефоном, заворачивая на себя только SWP. Это позволяет использовать технологию на любых телефонах не поддерживающих SWP и NFC вообще. Внутри антенны есть полноценный NFC чип. Называется она Gemalto N-Flex. К сожалению купить их почти невозможно, но у меня есть пару штук, и если тебе интересно, я могу выслать такую антенну вместе с сим-картой поддерживающей SWP.
Сейчас я подключаю сим-карту напрямую к антенне, и оно работает корректно в такой связке. Но стоит подключить щупы осциллографа, как все ломается. Видимо из-за паразитной емкости. К сожалению я никогда раньше в жизни не сталкивался ни с чем подобным и с осциллографом за всю жизнь работал около получаса.
Вот как выглядит моя конструкция сейчас. Зеленая плата это GPRS модем, но он используется только как сокет для сим-карты. Сам модем не активен. По сути здесь реализована точная копия принципиальной схемы как на картинке выше.
Конечная моя цель, сделать открытую реализацию SWP (конкретно Slave S2) которую можно повторить на микроконтроллере общего назначения. Так как эта технология позволяет эмулировать любые карты почти аппаратно, при этом работает очень хорошо. Я пробовал много разных программных способов эмуляции ISO1443 и все они работали плохо.
Но для начала мне нужна отладочная плата (сниффер) чтобы иметь возможность тестировать как работают реальные устройства. Здесь этот же мужик пишет про свой SWP reader на FPGA hilbert-space.de/?p=140 но схемы не выкладывает, и как я понял это полноценный интерфейс для работы в качестве S1 через компьютер. Мне же достаточно сниффера, который позволит снимать сигнал без его искажения, при том что S1 и S2 у меня заводские.
Кстати, если не ошибаюсь, андроид такое уже давненько поддерживает. Это называется off-host-NFC
Проблема в том, что эту ногу мало кто заводит на SIM-карту, и не понятно как эта функция вообще называется. Айфон так не делает, например вообще.
О, интересно. Насколько я понимаю в рамках андроида off-host означает что данные от NFC чипа будут напрямую прокидываться в UICC, которым, насколько я понимаю, может быть как SIM-карта, так и SecureElement. Но сам я таким не пользовался. Мне кажется, это довольно экзотичный случай.
Ещё, насколько я понимаю, по похожей схеме у NXP работают аппаратные SAM-модули для современных карт mifare. Чип делегирует им передачу данных от карты, а они занимаются расчётом криптографии необходимой для получения криптограмм в challenge-response схеме аутентификации секторов на чтение/запись. Таким образом данные о ключах спасаются от нахождения в памяти хост-системы к которой подключён кард-ридер
А если я не знаю что за стандарт у меня?
Хочу просто прикладывать к флипперу всё подряд и пусть он угадывает. Можно так?
Можно, Флиппер будет определять известные ему протоколы и стандарты. А если протокол неизвестен, Флиппер не отреагирует на карту.
Например, вы можете прочитать карту из меню 125 kHz RFID и она не определится, тогда вы можете зайти в меню NFC (для 13,56 МГц) и прочитать ее.
Мы думали объеденить все протоколы в одно меню RFID, но это также добавляет путаницы, например из-за двухдиапазонных карт, которые одновременно работадют на 125 khz и 13,56 MHz.
Флиппер не может одновременно активировать обе антенны RFID, поэтому нужно будет включать их по очереди. Каждое чтение занимает время и если сперва ждать все протоколы на одном диапазоне, потом на другом, чтение будет занимать несколько секунд, и чтение не будет отзывчивым. Это будет раздражать.
Детектор считывателя
Мы собираемся добавить функцию обнаружения частоты, на которой работает считыватель. Можно будет просто поднести Флиппер к считывателю и он скажет в каком диапазоне работает этот считыватель.
Вопрос может слишком странный, но любопытно
Можно ли сделать взять два флиппера, соединить их по ble или wifi, поднести один к телефону с готовым Apple Pay а второй к терминалу оплаты и сделать такой хитрый проброс оплаты чего либо?
Или же у NFC есть ограничение на время ответа. В этом случае может понадобиться связь побыстрее
В целом, я не вижу никаких ограничений для такого, потому что POS терминалы очень толерантны к задержкам ответа карты, я сам удивился обнаружив, что банковская карта может думать перед ответом ДЕСЯТКИ миллисекунд. Так что вполне возможно, но сами мы делать такую функцию не будем.
Плюсую. Вообще вроде как по идеологии NFC ответ должен быть всегда очень быстрым, но при этом современные реалии существенно скорректировали это, т.к. 13.56МГц картам, в чипе которых например крутятся апплеты, считающие тот же RSA, очевидно необходимо большее время для ответа чем LF-карточке передающей только свой ID. Насколько я понимаю, время таймаутов на получение ответа настраивается на уровне драйверов и в общем PC/SC драйвере на винде например по умолчанию составляет 5 секунд.
Я для интереса эмулировал ISO-7816 NDEF тэг на андроиде через HCE сервис. А HCE сервис в андроиде так устроен что сначала система получает ISO SELECT APDU (00 A4 04 ... ), парсит из него значение AID (идентификатора апплета с которым необходимо начать работу), затем по этому AID система смотрит есть ли среди манифестов приложений объявленые HCE-сервисы которые умеют эмулировать апплет с таким ID и если есть, то стартует этот сервис и передаёт ему управление. Это занимает время, плюс на старте сервиса у меня инициализировалось создание объектов, вычитывание данных из песочницы и т.д. что тоже занимает время, и по факту ответ на первую APDU приходил с ооооочень большой для NFC задержкой (очень много миллисекунд), но ничего - ни один ридер не подавился. Так что не исключено, что и relay-атаки вполне осуществимы
Купленный на али несколько лет назад считыватель mifare раньше мог прочитать хоть какой-то код при прикладывании банковской карточки. Пробовал повторить этот фокус не так давно, ничего не прочиталось. Да, карточки уже новые.
Вопрос: за несколько последних лет что-то поменялось, банки теперь выдают карточки, работающие совсем иначе?
Возможно ваш считыватель настроен на определенный SAK, ATQA и видя данные, не соответствующие по его мнению картам Mifare, он просто не выводит их. Но так сложно гадать, нужно больше информации.
Очень хочется такую же фичу для 2.4 GHZ (2.4G FSK) пультов. Для ИК пультов таких решений навалом, а вот для 2.4 GHZ найти не удалось. Могло бы стать уникальной киллерфичей флиппера, из-за которой я с удовольствием его купил бы! Надеюсь учтёте в будущей версии девайса.
Что-то жутко специализированное, подо что нужно ещё целый железный модуль с антенной. Где это применяется? Нагуглил только пульты для фотиков.
Да нет, 2.4G пульты - очень распространённый вариант. Для радиоуправляемых игрушек, освещения, камер и др. Конкретно FSK я выделил, потому что это моя потребность, ради которой я купил бы флиппер. Но обычно в чипах 2.4G (напр. от тех же TI) помимо FSK поддерживаются и другие принципы передачи, так что при правильном подборе железной части, получится довольно универсально.
Есть специальный мультипротокольный модуль для RC моделей. Там аж три аппаратных модуля. Но, понятное дело, там никаких протоколов камер и освещения там нет. Вообще основная проблема в подобных вещах это не аппаратная возможность, а программная поддержка. Купить модуль на алишке и припаять его к ардуине может практически кто угодно, а вот среверсить протокол и закодить его это уже совсем другой уровень усилий. Даже если протокол тривиальный, все равно далеко не каждый хочет тратить на это жопочасы, а так как протоколов много, то вряд ли стоит ожидать хорошую поддержку как минимум большинства из них.
Вот репа модуля, о которой говорит @Firelander. https://github.com/pascallanger/DIY-Multiprotocol-TX-Module
Моя аппа использует такой модуль и имеет функцию обучения. Прошивка аппы тоже открытая - OpenTX. Думаю можно сделать расширение для флиппера на основе мультимодуля и утащить кусок прошивки OpenTX
Встречался с RFID на 134 kHz (для животных 12мм и 8мм).
Flipper поддерживает 134 kHz?
Насколько я знаю, в хардверной части должно работать. Но для 134 кГц применяются другие протоколы, которые мы пока не поддерживаем, софт под них не написан. То есть из коробки, эти протоколы определяться не будут. Возможно в дальнейшем такие протоколы добавятся в прошивку.
Стандарты требующие 134кгц допускают работу и на 125кгц. Но антенна и весь тракт у нас довольно широкополосные.
Раз тут собрались спецы по RFID, может кто мне обьяснит почему не взлетел учет товаров в магазине с использованием RFID меток ?
Местами он используется, но не в продуктах повседневного спроса (FMCG). Думаю, это связано с экономикой больше. Напечатать штрих-код дешевле, чем вести учет меток. Обычно магазины больше теряют на списании товара из-за срока годности или повреждениях в транспортировке, чем на воровстве. Но если говорить об одежде, или книгах, RFID достаточно распространен.
Там все товары снабжены тегами, UHF RFID если не ошибаюсь. Работает чуть ли не в полуметре от рамки даже.
Я занимался проектами и поддержкой оборудования для печати и немного сканирования ШК/считывания RFID... Т.е. я не эксперт, но сталкивался. Важно сразу разделить отрасли - безопасность, платежи и торговлю (ритейл). Я могу немного сказать за торговлю (в частности, магазины, авиа/кинотеатровые билеты и их аналоги)...
Вопрос чисто экономический - еще в 2009 году делали перед началом проекта по пакетному сканирования приходящих грузов оценивали экономику штрих-кодов (ШК) и RFID - выбор тогда очевидно был в пользу ШК - дешевле в разы, если не на порядки. Позже, в ~2014 опять рассматривали варианты использования RFID для торговли - все равно дорого и ненадежно. Суть проблемы в том, что метки стоят денег (сейчас, конечно дешевле) и оборудование стоит денег. Причем бизнес уже оснащен всем необходимым для работы с ШК - принтерами, сканерами, расходкой - это уже стало массовым, есть наработки по железу, софту и типовым кейсам и, соответственно, ценник низкий ввиду массовости. С RFID все сильно хуже - железо редкое, софтовых решений мало, почти нигде не внедрялось. Ценник выше из-за немассовости и риски выше.
Опять-таки у ШК есть 2 сильно отличающихся по возможностям варианта:
1) линейные штрих-коды (UPC,EAN, ...) - слабая помехозащита, малая емкость, копеечное оборудование для печати и сканирования (принтер за несколько сотен долларов и сканер за десятки долларов).
2) 2D QR-коды (Aztec, QR, ...) - хорошая помехозащита, емкость сильно выше, копеечное оборудование для печати и чуть более дорогое сканирования (скажем, сканер раза в 2 дороже а принтеры, в основном, пригодны любые).
У RFID их 3:
1) 125 Khz (EM Marine, ...) - малая емкость (только UID), нет шифрования, небольшая дистанция считывания (несколько см.), копеечное оборудование для сканирования (несколько тыс. руб.).
2) 13.56Mhz HF RFID (Mifare, NDEF) - большая емкость, но малая дистанция считывания (несколько см.), умеренно дорогое оборудование для записи/печати и сканирования (порядка нескольких сотен долларов за сканер).
3) 868Mhz UHF RFID (EPC Gen.2) - маляя емкость (единицы-сотни байт), большая дистанция считывания (10 метров и более), очень дорогое оборудование для записи/сканирования и печати (порядка 1000 USD за сканер).
С точки зрения возможностей - да примерно одинаково все - объем информации в метке ограничен размерами метки и применяемой технолгогией. Например, в ШК можно набить десяток-полтора байт, на в QR уже и килобайт втиснется (при вменяемых размерах метки). В 125Khz просто UID, а в Mifare уже до 4 кб в памяти карты. Т.е. параметры схожи.
По ограничениям технологии - ШК может быть затерт/нечитаем, но и RFID тоже может быть поврежден (надрыв антенны или удар по чипу). По ограничениям считывания и размещения - ШК должен быть виден, RFID может быть скрыт, но RFID может быть заблокирован радионепрозрачными объектами/покрытиями (человеческим телом, фольгой). По дистанции считывания у RFID однозначное преимущество, но это относится только к UHF и все равно 100% гарантии считывания нет (если метка заслонена чем-то массивным).
С точки зрения безопасности, безусловно, ШК не выдерживают никакой критики - подделать код можно по фотографии.
Так что внедрение RFID в быт вполне себе идет, но небыстро, т.к. требует капитальных затрат и не предлагает финансово оправданных преимуществ. В сфере безопасности RFID, безусловно, монополист.
Теперь ждём эмуляцию Mifare Ultralight, и Mifare Classic, и реализации nested атак
Спасибо за статью в популяризационном стиле, получилось вроде и обширно, но всё же несколько поверхностно.
Небольшие замечания по LF RFID
1) > остальные используют ту же модуляцию на физическом уровне
Можно было бы и упомянуть про разные виды модуляции и кодирования в LF, так, для общего развития.
2) > Мы изучили 3 протокола, другие протоколы протоколы пока не смотрели, не поддерживаем, софт под них не написан.
Но при этом обобщаете выводы про примитивность других протоколов, даже поверхностно не изучив. А между тем, для примера, в автомобильных иммобилайзерах до сих пор (пока ещё) используются LF протоколы и уже не один десяток лет. И там не просто тупая передача идентификатора, а всё несколько сложнее. Причём это весьма широкий сегмент, а ведь есть и другие - метки животных и прочие.
Так что ждём возможность расширения библиотеки под 134 кГц и другие протоколы.
В статье имелись в виду протоколы относящиеся к СКУД. Мы знаем что есть еще всякие протоколы типа HITAG, которые требуют двустороннего общения, но вряд ли их будет возможно поддерживать из-за некоторых особенностей приемного тракта.
Так же да, есть всякие FDX которым требуется настоящий FSK/PSK, но тракт под все это просто невозможно запихать в маленькую коробочку с не особо большим МК. По-хорошему тут нужен ару к антенне, ацп, и дальше sdr для этого всего великолепия, что выглядит как задача скорее для Flipper One.
Еще большинство меток для животных, хотя и заявляют частоту 134кгц, но вполне работают на 125кгц ценой снижения SNR. Хотя железо у нас довольно широкополосное, но опять же из-за особенностей тракта очень дорого переключать частоты считывания на лету, когда мы не знаем что именно к нам поднесли и пытаемся это понять.
Спасибо за статью. Интересно было почитать.
Все статьи про RFID сводятся к пропускам, меткам, банковским карточкам. Написано что низкочастнотная RFID метка может считываться на расстоянии. Можно ли использовать данную технологию на складах в логистике или в магазинах?
Например приклеить низкочастотную метку к товару/коробке задать ей значения серийного номера товара. При инвентаризации сканировать на расстоянии в пару метров серийный номер, выгружать отсканированное например в екзель и сравнивать с учетными данными?
LF - нет.
Для этих целей давно уже используются копеечные UHF метки.
Вот только антенна/считыватель для них дорогие.
У низкочастотных (LF) RFID меток есть существенный недостаток - коллизии. Это когда несколько карт находится рядом, и считыватель начинает захлёбываться полученными данными, так как метки искажают данные друг-друга. Есть специальные антиколлизионные методы, которые в основном применяются на высокочастотных метках.
Для складских применений часто используют UHF-метки. Для них изготавливают специальные считыватели, с возможностью читать много меток за раз.
Да, сегодня быстро всё это попадает в чёрный список, возможно даже мгновенно, но скорее интересна техническая возможность.
Мы не поддерживаем софтверно данный функционал. Тема интересная, но для статей на Хабре не очень подходит. Пример заблокированной статьи
Насчёт ключей от домофона. Как-то в наш подъезд установили домофоны ДомРу. Относительно недавно я узнал, что можно открыть дверь приложив свой смартфон.
И вот тут мне не вообще понятно, почему это можно сделать. Может кто-то знает какая информация передаётся домофону и как вообще они решили, что именно этот смартфон имеет право работать как ключ?
А метки "UHF 840-960" не поддерживаются радиочастью флиппера или они просто никому не интересны?
Мой жилой комплекс использует такие для въезда в гараж и хотелось бы уже перестать акробатически просачиваться мотоциклом между створок шлагбаума.
Существует множество RFID-протоколов, работающих на других частотах, вроде UHF 840-960 МГц. Они применяются для отслеживания грузов, оплаты проезда на платных дорогах
Это не оно?
Flex pass штата Вашингтон
Большое спасибо за интересную статью. NFC - очень классный физический интерфейс, который к сожалению не так много где используется. Было бы здорово если бы ему находилось больше интересных прикладных применений. Мне самому наиболее интересно то что относится к его использованию на мобильных устройствах. К сожалению, с NFC есть немало ограничений, особенно в условиях мобилок.
Часть из них - ограничения ОС. На iOS до сих пор нет HCE интерфейса для самостоятельной эмуляции тэгов, т.к. Apple продвигает свой проприетарный протокол эмуляции который поддерживают только производимые ими ридеры, хорошо хоть с iOS 13 завезли передачу произвольных APDU, до этого вообще можно было только NDEF тэги читать, и то далеко не все. На андроиде полноценно можно работать только с полноценными ISO-7816 тэгами, хотя многие вендоры, те же NXP на ряде продуктов специально делают отходящие от стандарта команды, благодаря чему андроид бросает исключения что это "некорректно сформированное APDU" и ничего не передаёт, или наоборот НЕ делают входящие в стандарт вещи, например до mifare plus ev1 не было поддержки команды ISO SELECT, которая по правилам должна быть первым передаваемым сообщением, т.е. их тэг полноценно работает, но сэмулировать его нельзя. Впрочем, нужно отдать им должное - на новых картах соответсвие ISO было окончательно доработано и теперь всё можно реализовать программно. Ещё на HCE в андроиде применяется ряд негласных ограничений, которые кажется даже не указаны в документации, например попробуйте передать CLA-байт отличный от 0х00, и всё упадёт с исключением, хотя тэги некоторых производителей полагаются на изменение CLA, например для передачи бита сигнализирующего о наличии шифрования или HMAC в сообщениях.
Часть из них концептуальные - многие криптографические схемы в простых картах полагаются на симметричные алгоритмы и соответсвенно, владение ключом, которому без использования SecureElement'a на андроиде практически не обеспечить надлежащую безопасность хранения, а использование SE требует системных прав. Это пожалуй главная причина по которой карты лояльности и проездные не переезжают в эмуляцию на смартфоне.
Тем не менее, использование AndroidKeystore и HCE технически позволяет делать красивые с точки зрения использования и обеспеченные безопасностью аппаратного кейстора решения. Однако всё это делается небыстро, работает не очень универсально, требует отдельной поддержки со стороны читающей аппаратуры и вероятно, к сожалению, останется только в домашних лабораториях энтузиастов экспериментаторов.
Все высокочастотные карты, работающие на базе ISO 14443-A, имеют уникальный идентификатор чипа — UID. Это серийный номер карточки, подобно MAC-адресу сетевой карты. UID бывает длиной 4, 7 и очень редко 10 байт. UID не защищен от чтения и не является секретным, иногда он даже написан на карточке.
Ну если занудствовать, то строго UID считать можно только 7 и 10 байт ID.
4-байтные ID несколько раз прошли по кругу, куча китайских аналогов и прочего. Так что их сейчас называют NUID (Not Uniq ID) так как существует довольно большая вероятность совпадения ID на больших системах (типа транспортных карт или социальных карт)
Понимаю, что дорого.... Но очень жаль что нет UHF...
А как можно будет получить флиппер с таким чехлом с русскоязычной надписью? Я оформил заказ на Flipper Zero Early Bird на кикстартере.
Низкочастотные (Low Frequency: 125 кГц) — имеют большую дальность чтения...
Высокочастотные (High Frequency: 13,56 МГц) — имеют меньшую дальность работы...
Могли бы дать источник к этой информации?
Как насчёт ISO11784 134.2 кГц?
Может кто подскажет где можно найти универсальные ключи для домофонов? Интересует 16ричный код, который эмулировать как ЕМ4100
Какие бывают RFID протоколы и как их похекать с помощью Flipper Zero