UHF RFID: Бюджетное решение для шлагбаума

?v=1

С давних времён люди пытаются придумать удобные методы аутентификации. В применении к шлагбауму это должна быть автоматизированная и защищённая система, которая требует минимальных действий со стороны пользователя и минимальное обслуживание. Один из лучших вариантов — это использование меток, наклеенных на машину. Метки позволяют не совершать какие-либо манипуляции для заезда на территорию, только ждать, пока шлагбаум откроется. Принято считать, что эти системы очень дорогие; попробуем разобраться, так ли это на самом деле…

Постановка задачи

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

Что касается пассивных меток, начиная с 2012 года компания GS1 AISBL начала публиковать стандарты, описывающие работу UHF меток. На сегодняшний день более 60 компаний выпускает оборудование для работы с UHF метками и сами метки. Это отличное решение для нас, т.к. с точки зрения пользователя достаточно наклеить себе на машину дешёвую метку, добавить её в систему и пользоваться, пока метка физически не повредится. Никаких батареек для пультов, телефонов и смс. Принято считать, что эта технология используется в основном в промышленных системах и достаточно дорогая, но после включения в игру Китая ситуация кардинально изменилась.

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

Выбор меток

UHF метки — это не просто точечка с красивой антенной, а достаточно сложное устройство, в котором есть перепрограммируемая память и алгоритмы. Список существующих на данный момент меток можно найти на сайте gs1.org. На изучение вариантов и возможностей можно убить пару недель своей жизни. Мой взгляд остановился на NXP UCODE DNA, — поддерживает AES128, 100% гарантия от взлома, если не брать в расчёт заезд в посёлок «паровозиком» и массу других подобных дыр в этом решете.

Но возвращаемся к реальности. Нас в первую очередь интересует то, что можно крайне легко купить как оптом, так и в розницу в свободной продаже. Изучая рынок России и Китая выясняем, что в массовой продаже можно найти метки от компаний Alien и NXP, модели Higgs H3/4 и UCODE 7/8 соответственно. Периодически можно встретить Impinj MINOZA 4QT/R6, Smartrac Dogbone и другие, но значительно реже и часто дороже. Начинаем изучать общие возможности меток и выясняем, что все эти метки имеют идентификатор (TID), перепрограммируемую память для идентификации (EPC) и поддержку паролей (кроме R6). Пароль позволяет заблокировать возможность «убивать метки» и менять EPC. Зная пароль, можно проверить, он ли установлен на метке, считав, например, TID с помощью него. Есть ряд функций, которые поддерживают только конкретные метки, например, NXP UCODE поддерживает блокировку памяти на чтение по паролю, но эта функция не поддерживается всеми метками, так что её брать в расчёт не будем.

Способ защиты от копирования и нелегального прохода

Изучив базовые возможности, мы продумываем максимально безопасную схему прохода:

1.1. Считыватель считывает TID без пароля,

1.2. На основании преобразований TID создаём пароль,

1.3. Считывает TID с паролем; если считать удалось, формирует событие на открытие (в нашем случае отправляет в СКУД идентификатор по wiegand).

Попробуем оценить, что должен сделать злоумышленник, чтобы скопировать метку:

2.1. Выяснить пароль от метки,

2.1.1. Применить brute-force атаку,

2.1.2. Воспользоваться другими атаками,

2.1.3. Воспользоваться сниффером непосредственно у шлагбаума,

2.2. Создать такую же метку с тем же TID,

2.2.1. Найти в продаже метки с незакрытой TID на запись,

2.2.2. Воспользоваться эмулятором UHF метки.

Многие считыватели UHF меток и почти (если не все) метки поддерживают пароли. Но по умолчанию предлагается выставить статический пароль, который будет использоваться в системе для всех меток. Это нам грозит тем, что узнав этот пароль, злоумышленник, имея решение проблемы 2.2, сможет делать копию любых меток в этой системе. В интернете уже можно найти статью «Serialized TID Numbers — A Headache or a Blessing for RFID Crackers», но вот беглый обзор не дал мне простого и дешёвого решения, как склонировать TID (но по опыту Mifare Classic, где есть даже готовые утилиты на githab) и с учётом, что мы поддерживаем любого производителя, потерять пароль по 2.1.2 становится делом времени, может быть не сейчас, но в ближайшем будущем точно. С учётом развития SDR пункт 2.1.3 не выглядит невозможным.

В итоге я решил сделать разные пароли для каждой метки на основе их TID. Даже если злоумышленник сможет скопировать одну метку, чтобы скопировать другую, ему придётся затратить столько же сил и времени, как и на первую. Минус данной технологии в том, что приходится зачитывать метку два раза вместо одного. Это увеличивает время и ошибки. Наиболее простой алгоритм формирования пароля, как мне показалось, это посчитать hash от TID и секретного ключа. В качестве алгоритма я взял sha256, а секретный ключ установил размером в 128 бит, чтобы исключить возможность подобрать его методом перебора. Почему именно sha256 и сколько его ломать? Конечно sha265 выбран из-за того, что он самый топовый алгоритм хеширования, так как используется для закрытия блоков в bitcoin. По опыту майнинга, где на данный момент успешно (минут за 10) подбирают «ключи» размером в 76 бит, подобрать 128 бит не представляется возможным…

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

В схеме обнаружился один неприятный минус, метки Impinj Minoza R6 не поддерживают пароли. А учитывая то, что я купил в том числе и их (200 штук), пришлось делать обходные пути, а именно, если мы выяснили, что метка R6, то возвращаем TID. Да, это позволит регистрировать любую метку, но сама СКУД просто не примет код. Т.е. мы лишились пункта защиты 2.1, но сохранили 2.2.

Выбор считывателя для улицы

В России найти бюджетные считыватели мне не удалось, так что пришлось воспользоваться китайским рынком, там есть множество предложений, близких к noname, которые предоставляют SDK для работы. Выяснилось, что некоторые не умеют работать с паролями, другие не имеют нормального описания. Есть варианты контроллер + антенна, есть варианты «всё в одном». Зная российский менталитет и опыт общественных проектов в нашем посёлке, любая ошибка в покупке привела бы к тому, что её пришлось бы оплачивать её самому либо выслушивать обвинения в коррупционной составляющей этого проекта. Короче говоря, бюджета на эксперименты с разными считывателями не было, пришлось выбрать максимально брендовый вариант с минимальными рисками, но всё равно «на удачу», а дальше пытаться выжать из этого решения максимум. Считывателем оказался CHAFON CF-RU5306.

Выбор оказался не тупиковый, в целом считыватель умеет работать автономно, т.е. можно записать туда параметры: читать EPC с какой-то позиции и выбрасывать в WG26, например, раз в секунду. В него даже встроено реле, которое можно замыкать, выполняя тем самым какие-то действия. Можно установить пароль, но только один, который будет использоваться при чтении всех меток.

К сожалению, нам все эти функции оказались не нужны, такой режим работы не подходит. Ещё в автономном режиме оказалась ошибка с зачитыванием TID с ненулевого смещения. Т.е. использовать TID для идентификации нельзя, только EPC. А это значит, что копирование меток будет элементарной задачей даже для школьника (даём обойти п. 2.2). Я конечно написал производителю о проблемах, на что они мне ответили: «Anyway, please use your controller to get data, our demo software it is for demonstrate only.», как бы заявляя, что автономный режим у них это «демо версия».

Пришлось копнуть глубже, я разобрал это устройство. Оно представляет собой МК STM32 и модуль UHR MagicRF M100, слева есть разьём для запайки какого-то ещё модуля, по пинам очень напоминающий ESP-12S. И… Бинго! Это оно. А значит мы теперь сможем реализовать всю логику считывателя на wifi модуле и получим возможность связываться по wifi как приятный бонус. Я конечно же написал производителю с просьбой прислать прошивку для ESP-12S, на что он конечно же отправил меня куда подальше (на китайский рынок купить считыватели с wifi), но по причинам, которые я описывал выше (нет права на ошибку), это было сделать уже невозможно.

Я запаял туда ESP-12S, перерезав RX/TX дорожки. RX/TX подключил к STM32, что дало возможность иметь тот самый «your controller», как побочный эффект ещё и получил wifi, а значит сэкономил на монтаже этой системы. Ложка дёгтя — считыватель находится в металлической коробке, который гасит wifi сигнал; после запуска на объекте получилось около -80 dBm, что крайне мало. Побегав вокруг антенны с роутером, выяснил, что wifi получился такой же направленный, как и антенна. Сбоку и сзади от читывателя сигнала почти нет; если стоять перед считывателем — сигнал просто отличный. В итоге заказал модули ESP-07, где есть возможность подключить внешнюю антенну, чтобы избавиться от этой проблемы. Что касается прошивки, как я писал в статье ранее, с теоретической точки зрения самое логичное — написать программу, используя прошивку на NodeMCU под lua или MicroPython, но практический опыт у меня оказался крайне печальным. В итоге я взял Tasmota (мой полоумный дом дал мне много опыта работы с ней) и добавил туда поддержку считывателя. 

Первоначально я сделал работу через MQTT: сообщения отправляются на MQTT сервер и выплёвываются в wiegand-32 для СКУД. Сам MQTT сервер, как и его клиент, запущены на самом роутере. Роутер я взял тот, что валялся у меня уже лет 10 без дела — TP-Link MR3220. Из минусов этого роутера — размер flash в 4 Mb. Такие роутеры поддерживает только старая прошивка LEDE (OpenWRT), которая оставляет только 70 кб на пользовательское приложение. С учётом, что вывод по wiegand я сделал на silabs cp2104 (который поддерживает GPIO), работающий через libusb (т.к. в старой прошивки в ядре ещё не было поддержки GPIO cp2104), и взял полноценный MQTT клиент Paho (т.к. он поддерживает автоматические реконнекты), размер бинарного файла вышел значительно больше 70 кб… После некоторого времени игры в «тетрис» пришлось отказаться от LuCI (web интерфейса для настройки роутера).

После запуска системы она работала крайне нестабильно, это было связано, как я уже писал, из-за очень слабого сигнала wifi. Обещанный MQTT реконнект, конечно, работал, но явно не соответствовал моим ожиданиям. В конечном счёте я решил отказаться от MQTT вовсе и сделать отправку кода минимально возможным количеством сообщений. Я стал посылать udp broadcast пакеты, которые содержали ключ и имя считывателя (имя задается через web интерфейс Tasmota). Broadcast выбрал, чтобы избавиться от ненужного в нашем случае arp обмена. Ну и конечно заказал внешнюю антенну для роутера и модуль ESP-07, т.к. ожидать стабильной работы с таким уровнем сигнала себе дороже. Из плюсов использования UDP возвращение LuCI на роутер, т.к. бинарный файл стал значительно меньше и необходимость устанавливать там MQTT сервер отпала (как и надежды, что драйвер RU5300 включат в Tasmota).

Выбор считывателя для офиса

Из всего разнообразия считывателей выясняется, что почти все продают продукты с одинаковым API. Я приобрёл Chafon CF-RU5102 и ещё какой-то LJYZN-105, документация на них различалась только первой страницей. Разобрав оба, я обнаружил, что везде срезаны названия контроллеров. В целом там стоит преобразователь USB→UART, какой-то контроллер для UHF и какой-то управляющий MK.

Несмотря на наличие SDK, версии под GNU/Linux не оказалось, пришлось вооружиться документацией и написать самостоятельно. С учётом хобби и дефицита времени была реализована работа только с теми командами, которые необходимы непосредственно для программирования меток: дублирование TID в EPC, установка пароля, блокировка чтения и записи.

Первоначально был план написать программу для отправки кодов прямо в СКУД сервер, но к сожалению «бесплатное ПО» этих СКУД (не будем показывать пальцем на Эру) заставило нагородить костылей. В считывателе от Chafon используется USB→UART преобразователь SILABS CP2102, в котором есть неиспользуемые выходы RTS и DTR. Я допаял туда два провода, получив тем самым D0, D1 для wiegand. Единственное, что в этой системе было плохо, это 3.3v. В нашем случае это не критично, так как контроллеры от СКУД регистрировали 3.3 вольта как »1», но в общем случае нужно, конечно, использовать какую-нибудь развязку.

В связи с тем, что проект затянулся, я не стал делать прошивку для работы с офисным считывателем на ESP, а упростил себе задачу и использовал самый дешёвый из известных мне PC — OrangePI Zero. Из плюсов использования ESP или OrangePI + считыватель — это возможность получить переносное устройство с использованием батареек (powerbank), что очень полезно для перепрошивки всех меток, которые мы уже приклеили на машины, пока тестировали дальнобойность CF-RU5306.

Итого

Систему удалось проверить на таком оборудовании:

  • считыватель для десктопа: CF-RU5102, LJYZN-105

  • считыватель для улицы CF-RU5306

  • протестированные метки успешно: Alien Higgs 4, NXP UCODE 8, Impinj Monza 4QT

  • протестированные метки с проблемами: Impinj Monza R6, пришлось отказаться от пароля для них

  • ещё потестировали метки с бирок магазина Декатлон, там оказались метки NXP какой-то неизвестной модели 0×890

  • ещё мне обещали дать погонять NXP DES, но обещания не реализовались

Цены:

  • CF-RU5102 — 1x — $55 — $55

  • CF-RU5306 — 4x — $130 — $520

  • ESP-12S — 4x — $1.5 — $6

  • OrangePi Zero — 1x — $17 — $17

  • SD cards — 1x — $8 — $8

  • Метки 500 шт — 500 — $0.176 — $88

  • Роутер и всякая рассыпуха — ~ $25

  • Для отладки пришлось купить ещё LJYZN-105 и CF-RU5300 (отладочную плату) ~ $100

Мы получили бюджетный и достаточно безопасный вариант системы доступа по меткам с ценой менее $1000 (около $800). Это с учётом, что мы планируем установить 4 считывателя, так как у нас две полосы, каждая из которых должна иметь возможность использоваться на въезд и на выезд, и сделали независимый отладочный стенд,

Решение получилось даже дешевле варианта использования RF 433 брелоков, так как 500 китайских брелоков обошлись бы в те же $800 (это без учёта цены на RF считыватель). 

В дополнение к этому нам просадили бюджет контроллеры СКУД ~$260, но это vendor lock, на который мы когда-то сели и который теперь приходится терпеть.

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

Спасибо за внимание.

© Habrahabr.ru