Номера карт в СКУД и их конвертация

Всем привет! Меня зовут Николай Мигунов, я технический менеджер проектов в компании Sigur. Статья посвящена, в первую очередь, преобразованию и конвертации пропусков между разными системами контроля и управления доступом (СКУД), а также информации, которая в них (пропусках) хранится. Вместе мы разберем, как номера пропусков отображаются в разных системах и с какими проблемами может столкнуться пользователь в этом контексте. Эта статья будет полезна для интеграторов, разработчиков интеграций со СКУД и специалистов, непосредственно занимающихся эксплуатацией системы на объектах.

Николай Мигунов

Технический менеджер проектов Sigur

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

Вы, как читатели, можете взаимодействовать с несколькими подобными системами в своей повседневной жизни и не знать об этом (и это нормально). Прежде чем перейти к теме данной статьи, я хочу кратко познакомить с общими принципами работы СКУД читателей, далеких от отрасли систем безопасности. 

Что такое СКУД?

Если попытаться максимально упростить, то задача СКУД – разграничивать физический доступ в различные помещения согласно установленным правилам. Но, как мы понимаем, реальный список задач, относящийся к подобным системам, на этом не ограничивается: учет рабочего времени, предоставление данных при эвакуации, коммуникация с информационными системами бизнеса или система управления зданиями.

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

Достаточно просто данную систему можно разбить на следующие элементы:

• Преграждающее устройство (замок/калитка/турникет/шлагбаум и т.д.).


• Контроллер (управляет преграждающим устройством).


• Считыватель (получает идентификатор и передает его на контроллер).


• Альтернативные идентифицирующие устройства (биометрические терминалы/ радиоресиверы/системы видеоаналитики с распознаванием по лицу или гос. номеру).


• Датчик прохода (для различия факта идентификации и реального прохода).


• Кнопки (для совершения обезличенного прохода/блокировки доступа/санкции оператора системы и т.д.).


• Дополнительные средства верификации и взаимодействия с пользователем (металлодетектеры/алкотестеры/картоприемники и т.д.).


• Сервер.


• Автоматизированные рабочие места (используются для администрирования данных о сотрудниках, оперативного наблюдения за событиями в системе и т.д.).

В качестве примера рассмотрим один из возможных сценариев построения СКУД в некотором гипотетическом офисе, на производстве или в университете.

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

Идентификаторы. Какими они бывают?

Наиболее распространенными вариантами использования уникальных идентификаторов сотрудников (или иных объектов доступа) являются:

1. Карты форматов Em-Marine, Mifare, HID, iClass и прочие.


2. Штрихкоды, QR-коды.


3. UHF-метки.


4. Радиобрелоки.


5. Биометрические данные.

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

Проблема особенно остро раскрывается при появлении необходимости в масштабировании системы и отладке внезапно возникших проблем.

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

При необходимости некоторые форматы позволяют дополнительно записывать UID, либо иное значение в защищенную область памяти с указанием ключа шифрования.

Что не так с картами и есть ли среди них подходящие?

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

Мы сразу можем откинуть и не рассматривать стандарт карт Em-Marine: он подходит только в случае низких требований к безопасности проектируемой системы.

Конкурентные преимущества карт данного стандарта следующие:

• Низкая стоимость.


• Распространенный формат (приобретение дополнительных карт не будет проблемой). Возможен сценарий обслуживания уже существующей системы на картах данного формата .


• Низкий уровень безопасности (карты не защищены от копирования).


• Ограниченная длина идентификатора (многие системы работают с данным форматом только в W26, соответственно, длина идентификатора ограничена тремя байтами).

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

Например, использовать мультиформатные считыватели для систем, работающих на картах Em-Marine, чтобы обеспечить постепенную «миграции» сотрудников на обновленные и более «секьюрные» карты.

Следующими на очереди будут карты HID ProxCard II и HID iClass.

HID ProxCard II можем сразу исключить из рассмотрения из-за высокой стоимости и низкой защищенности (а также общего устаревания данного формата).

А вот HID iClass выглядит гораздо разумным решением, однако остается достаточно нишевым решением из-за своей стоимости, а также особенностей логистики и нюансов работы с данными картами. Хотя в определенной степени оправдывает это своей «секьюрностью».

Рассмотрев особенности других карт, мы подобрались к наиболее оптимальным картам – Mifare.

Принципиальное отличие данного семейства карт от стандартов Em-Marine и HID ProxCard II (на не от HID iClass) заключается в возможности записи идентификатора во внутреннюю память карты (совместно с шифрованием). Ниже мы подробнее рассмотрим наиболее распространенные форматы семейства Mifare.

Карты Mifare Classic можно считать морально устаревшими как минимум 
из-за алгоритма шифрования CRYPTO-1 (а как максимум – из-за того, что данные карты появились аж в 1994). Данный формат давно скомпрометирован (“backdoor key in FM11RF08S”; полный реверс-инжиниринг выполнен в 2008 году; хорошая презентация на эту тему – MIFARE Classic: completely broken).

Карты Mifare Plus пришли на смену Mifare Classic, чтобы исправить указанный выше недостаток. Организация и структура памяти аналогична Classic: память также подразделяется на сектора и блоки.

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

Всего их 4:

• SL0 – «транспортная конфигурация». Иными словами, это только что выпущенные чистые карты. Память карты никак не защищена.


• SL0-SL1 – на этом уровне используется шифрование CRYPTO-1 (такое
  же, как и в Mifare Classic). То есть максимальный уровень защищенности карт
  Mifare Classic соответствует именно этому уровню.


• SL2 – почти нигде не используется в чистом виде, так как на данном уровне используется шифр CRYPTO-1 c динамически сгенерированными ключами, а не со статическими (как в SL1). По сути, просто промежуточный уровень для перевода карты из режима SL1 в SL3).


• SL3 – максимально возможный уровень защищенности для карт Mifare, при котором для получения доступ к памяти используется шифрование AES-128. Оно позволяет преобразовать исходное сообщение в неузнаваемый вид. При этом из результата шифрования невозможно получить исходные данные без знания ключа. Это обеспечивает надежную защиту информации.
  Теоретически ключ можно подобрать, однако на это уйдут годы. Поэтому содержимое памяти такой карты невозможно скопировать на «болванку».

Карты Mifare DESFire являются наиболее защищенным стандартом и обеспечивают высокую скорость передачи данных.

Их применение в СКУД не так распространено, как использование двух предыдущих типов карт, поскольку изначально они предназначались для иных целей. Такие карты обычно используются для оплаты проезда в общественном транспорте, бронирования билетов и выпуска бонусных карт постоянного покупателя.

Организация и структура памяти уже иные. Карты MIFARE DESFire поставляются с предустановленным ПО (операционная система DESFire), предусматривающим наличие файловой системы. В памяти карты можно создавать отдельные приложения.

Высокий уровень защищенности также обеспечивается за счет использования алгоритма шифрования AES.

В любом случае даже Mifare Classic будет лучше, чем Em-Marine и HID ProxCard II. Но для обеспечения наибольшей безопасности лучше присмотреться к более современным форматам карт Mifare.

А что с кодами?

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

Для этого существует несколько стандартов передачи информации от считывателя к контроллеру доступа. Все они достаточно похожи друг на друга и отличаются только длиной уникального номера пропуска (наиболее распространена длина в 3, 4, 7 байт, но также встречаются и другие) и количеством битов четности (1-2 бита в зависимости от формата).

Расскажу на примере W26 о предоставлении данных в этих форматах на уровне информации, хранимой на самих картах.

В формате Wiegand 26 на карте хранится 3 байта значимого кода пропуска и 2 бита четности. К сожалению, даже при использовании одинакового формата пропусков в разных системах они могут отображаться по-разному. По этой причине при переходе на другую СКУД, либо при использовании нескольких СКУД в рамках одного объекта возникает необходимость в конвертации пропусков из представления одной системы в представление другой.

Данные, передаваемые считывателем на контроллер в формате Wiegand 26:

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

Что касается отображения и хранения номера пропуска в разных системах, существуют относительно «общепризнанные» или популярные стандарты (на самом деле – нет). Но чаще всего различные вендоры предпочитают хранить номера пропусков в том виде, который они считают правильным. При этом подходы разных производителей зачастую сильно различаются.

К примеру, мы (Sigur) отображаем W26 в виде «фасилити-код» + «код пропуска» (123,45678), где фасилити-код занимает 1 байт, а код пропуска – 2 байта. Соответственно, номера пропусков от «000,00001» до «255,65535» (коды пропуска, состоящие исключительно из нулей и единиц, по понятным причинам не используются).

Wiegand-коды большей разрядности мы отображаем в шестнадцатеричном формате (W34, W36, W37, W42, W58) и десятичном формате (W58DEC).

Проблемы при работе с пропусками

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

Из этого вытекает сразу несколько проблем (или кейсов, если вы достаточно оптимистичны):

1. Переход на иную систему.
   Масштабирование или модернизация СКУД иногда требует смены вендора (общее устаревание, недостаток функционала, недовольство работой системы). Как следствие, появляется необходимость в конвертации пропусков из представления в одной системе в другую.


2. Объединение разрозненного состава СКУД в рамках создания единой верхнеуровневой системы.
   
   Нередки случаи внедрения разных СКУД в рамках филиалов одной компании. Как следствие, возникает необходимость в создании единого интерфейса управления СКУД всех филиалов: работа в одном окне, отсутствие необходимости вручную поддерживать несколько кадровых баз. В данном случае необходимо предусмотреть автоматизацию конвертации при синхронизации данных между системами, чтобы не приходилось повторно вносить новые пропуска в разных системах.


3. Синхронизация данных из сторонней системы (ERP, CRM и т.д.) в СКУД.
   
   Достаточно распространенная ситуация, при которой возникает необходимость «подружить» две и более системы, решающие разные бизнес-задачи. К примеру, CRM для фитнеса и СКУД. В CRM клиент ведет кадровую базу клиентов, учет оплаченных услуг и выдачу идентификаторов, чаще всего в исполнении браслетов (в данном случае клиенты также стремятся к «работе в одном окне»).
   
   Задача похожа на предыдущий пункт и также подразумевает автоматизированную конвертацию номера пропуска при синхронизации данных. Конечно, в рамках данного кейса возможны и другие подходы к решению задачи, но не будем на этом останавливаться.

Теперь, ответив на вопрос «зачем это нужно», перейдем к основной теме нашей статьи.

Как конвертируются карты из разных СКУД?

В некоторых случаях разработчики систем добавляют дополнительный «мусор» к номеру пропуска. И тут возникает логичный вопрос, а зачем? Возможно, чтобы считывать больше информации с карты (спойлер: она может быть одинаковой для всей партии карт) либо специально шифруют отображаемый номер пропуска в ПО (видимо, чтобы усложнить миграцию на другую систему).

Если же мы посмотрим на формат представления пропуска в базе данных, то он будет уже существенно отличаться от отображаемого в ПО: содержать зашифрованные данные (чтобы их было сложнее извлечь из БД), а также специализированные флаги в одном или нескольких байтах перед или после номера пропуска (к примеру, байт, обозначающий разрядность номера пропуска).

Часто пользователи сталкиваются с трудностями при переходе на новую систему. Как разработчик СКУД, мы часто сталкиваемся с задачами миграции данных в нашу систему (в основном связанными с конвертацией пропусков). Благодаря этому мы уже успели «набить руку» в данном спектре задач и можем поделиться нашим опытом.

Ниже я приведу несколько примеров конвертации пропусков из сторонних СКУД в Sigur:

Вендор №1 – мы имеем следующий пул пропусков:

Давайте сравним пропуска в двух системах и создадим алгоритм конвертации.

У вендора №1 имеем следующий алгоритм конвертации:

1. Берем правые 4 байта и отбрасываем последний и преобразуем первый байт в фасилити-код.


2. В получившемся 3-х байтном коде берем левый байт и переводим его в десятичный вид.


3. Переводим два оставшихся байта в десятичный вид.


4. Преобразуем код, записываем первый байт в десятичной,
   ставим запятую и записываем два оставшихся байта в десятичном виде.

Далее мы более подробно разберем подобные преобразования.

Вендор №2 – имеем несколько пропусков и их номера в двух системах:

Изучив большое количество пропусков в системе вендора №2, можно заметить, что в них не встречается цифра больше 7. Из-за чего мы делаем вывод, что пропуска хранятся в восьмеричном виде. Каким образом мы можем конвертировать пропуск из системы вендора №2 в нужный нам вид?

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

Зависимости не находим. Но мы не отчаиваемся.

Попробуем инвертировать в записи номер пропуска из системы вендора №2. Получаем 37467152000100->00100025176473 и повторно рассмотрим его и пропуск в Sigur в бинарном виде:

В результате мы находим искомую для нас информацию и можем подготовить алгоритм конвертации:

1. Инвертируем в записи код системы вендора №2.


2. Берем правые 3 байта (в любом виде записи).


3. Левый байт переводим в десятичный вид, ставим запятую, переводим два правых байта также переводим в десятичный вид.

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

Мы молодцы!

Вендор №3 – рассмотрим следующий пул пропусков от третьего вендора и его соответствие в Sigur:

Берем одну из пар пропусков в бинарном виде:

Находим зависимость для конвертации.
Остается только составить корректный алгоритм для перевода (наша любимая часть).

Для удобства по байтам разворачиваем пропуск от вендора №3:
Нам остается взять правые три байта и отобразить их в нужном нам виде.

По итогу имеем следующий алгоритм конвертации:

1. По байтам разворачиваем код пропуска из системы вендора №3.


2. Берем три правых байта.


3. Переводим левый из них в десятичный вид, добавляем запятую и переводим два оставшихся байта в десятичный вид.

Еще один алгоритм конвертации готов.

Мы большие молодцы, кажется, нас не остановить!

В данном случае рассмотрим преобразование на примере одного идентификатора:

О нет! Кажется нас остановили.

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

Такой вариант хранения идентификаторов в системе значительно повышает вероятность совпадения значащей части идентификаторов, что, в целом, достаточно плохо.

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

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

Мы соотносим несколько пропусков в двух системах и находим в стороннем номере пропуска место хранения необходимых нам данных. На основе этой информации мы готовим формулу конвертации для переноса пропусков в Sigur.

Бывают случаи, что системы смотрят на разные части номера карты (UID). К примеру, в случае с Em-Marine мы работаем исключительно в W26 и используем последние 3 байта номера пропуска (перед ними идет незначащая информация).

Описанных выше формул для конвертации будет достаточно при «единоразовом» переходе на СКУД другого вендора. Если же планируется использование нескольких СКУД на одном объекте, стоит задуматься об автоматизированной синхронизации данных между этими системами.

В качестве примера приведу одно из наших внедрений на большом объекте.

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

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

В результате клиент создает сотрудника, добавляет ему пропуск и заносит необходимую информацию в СКУД другого вендора. Мы через ODBC-коннектор подключаемся к его базе данных и с помощью запроса получаем и конвертируем необходимую нам информацию.

В нашем ПО клиенту остается только выдать допуск на точки доступа и назначить необходимый для сотрудника режим (рабочий график/режим доступа).

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

Заключение

Конвертация номеров пропусков является важным аспектом при работе с несколькими вендорами СКУД. При небольших масштабах объекта, либо переходе на другую систему, может быть достаточно единоразово конвертировать номера пропусков, либо добавлять карты в несколько СКУД’ов параллельно (ведя несколько баз персонала).

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

Спасибо что уделили время и прочитали статью до конца!