Design of physical access control system with integrated wireless authentication

Cover Page

Cite item

Full Text

Abstract

This article discusses the design of a physical access control system for an enterprise with various methods of authentication and user identification. A review of existing solutions in the design of physical access control systems was conducted. In the course of the work, a system design was proposed, and its components were described in detail.

Full Text

I. Введение

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

II. Проектирование

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

  • аутентификация по паре логин/пароль – самая простая аутентификация. Для ее реализации надо всего лишь проверить пару логин/пароль на наличие в базе данных пользователей. Недостатком данного метода является необходимость знать пару логин и пароль;
  • аутентификация по технологии NFC (RFID) [3, 4, 5] – преимуществом данного способа аутентификации является то, что пользователю не надо вводить какие-либо данные, сам NFC-чип уже содержит всю необходимую информацию для аутентификации пользователя. Недостатком NFC будет являться необходимость наличия физического устройства (NFC-чипа) у пользователя;
  • аутентификация по ключам iButton – обладает все теми же преимуществами и недостатками, что и NFC. Однако iButton обладает одним преимуществом перед NFC – это более простая и дешевая реализация как физического устройства, так и протокола передачи данных.

Функциональные требования

Согласно изложенным выше способам аутентификации и требованиям к системе [1], проектируемая система должна реализовывать следующие функции:

  • авторизация пользователя через Wi-Fi-сеть;
  • предоставление доступа к помещению через NFC-ключ;
  • предоставление доступа к помещению через QR-код;
  • регистрация событий открытия двери помещения с помощью обычного ключа;
  • ведение журнала доступа пользователей в помещение.

Общая концепция системы

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

Открытие двери по QR-коду

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

Авторизация посредством опознавания устройства в Wi-Fi-сети

Следующим шагом станет создание концепции автоматического входа пользователя в систему в том случае, если он зашел на форму входа из Wi-Fi-сети организации.

Так как в организации используется единая точка входа для всех клиентов Wi-Fi-сети и тип авторизации EAP, предлагается подключиться к шлюзу авторизации и при обнаружении нового пользователя в системе попытаться получить о нем информацию из шлюза авторизации Wi-Fi-сети [6].

Вход в помещение через NFC-метку,
открытие двери и событие оповещения о доступе в помещение

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

Для решения этой проблемы систему можно разделить на две части:

  1. Веб-сайт, отвечающий за авторизацию, контроль доступа и инициирование команд управления дверьми.
  2. Модуль управления замком двери, отвечающий за исполнение команды и обнаружение событий открытия двери.

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

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

Протокол взаимодействия между системами

Для взаимодействия между системами будем использовать REST [7]. Теперь необходимо определиться с системой команд и форматом обмена данными, для этого определим, какими данными необходимо обмениваться двум частям системы (в данном случае сервер – это веб-сайт, а клиент – модуль управления замком):

  • команда на открытие/закрытие замка (от сервера к клиенту);
  • команда на подтверждение доступа по карте (от клиента к серверу);
  • добавление удаления ключей;
  • событие открытие/закрытие двери (от клиента к серверу);
  • событие открытие/закрытие замка (от клиента к серверу).

Команда на открытие/закрытие замка

Данная команда предназначена для управления замком и может посылаться как от сервера к клиенту, так и от клиента к серверу. Однако значения данных команд будут немного разные:

  • Если сервер посылает данную команду клиенту, то это прямая команда на открытие замка, и клиент должен ее исполнить.
  • Если команду посылает клиент серверу, то это запрос на доступ к двери, при этом клиент должен указать дополнительные параметры в запросе, а именно ID ключа и тип ключа (NFC или iButton). В случае если сервер успешно выполнит запрос, то клиент должен открыть замок (дверь).

Данная команда может иметь следующие параметры:

  • id –уникальный идентификатор замка;
  • type – тип ключа (NFC или iButton), используется только если запрос посылает клиент;
  • key – сам ключ.

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

Формат запроса представлен на листинге 2.1.

Листинг 2.1 – Формат запроса на открытие замка в формате JSON

{

    "id": "1",

    "type": "NFC",

    "key": "123-123-321-abc-"

}

Добавление/удаление ключей

Данная команда нужна для регистрации и удаления ключей (NFC или iButton). Посылается от клиента к серверу и просто добавляет в базу один новый ключ или удаляет его.

Параметры:

  • id – id в формате UUID;
  • type – тип ключа;
  • action – тип операции (добавить (add) или удалить (remove).

Формат запроса представлен на листинге 2.2.

Листинг 2.2 – Формат запроса на открытие замка в формате JSON

{

    "id": "123-321",

    "type": "ibutton",

    "action" : "remove"

}

Событие открытие/закрытие двери

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

Имеет 2 параметра:

  • id – идентификатор двери;
  • status – что произошло с дверью (возможные состояния открыта (open) и закрыта (close).

Пример запроса представлен на листинге 2.3.

Листинг 2.3 – Команда оповещения сервера о состоянии двери в формате JSON

{

    "id": "123-321",

    "status": "close"

}

Событие открытие/закрытие замка

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

Имеет 4 параметра:

  • id – идентификатор замка;
  • status – что произошло с замком (возможные состояния открыта (open) и закрыта (close);
  • key – id ключа (если событие было вызвано с использованием ключа);
  • type – тип ключа (если событие было вызвано с использованием ключа).

Пример запроса представлен на листинге 2.4.

Листинг 2.4 – Команда оповещения сервера о состоянии замка в формате JSON

{

    "id": "123-321",

    "status": "open",

    "key": "123-123",

    "type": "NFC"

}

Проектирование базы данных

Для начала необходимо определить, какие данные мы будем хранить в системе:

  1. Список дверей.
  2. Состояние дверей (замков).
  3. Пользователи и их права.
  4. Журнал доступа.

На основе каждого из этих пунктов составим схему базы данных (рис.).

 

Рисунок – Схема базы данных

 

III. Заключение

В результате проделанной работы была спроектирована система контроля удаленного доступа (СКУД) с электромеханическими замками с возможностью доступа к системе посредством NFC-чипов, iButton-ключей, QR-кода, корпоративной беспроводной сети (Wi-Fi) или же простого входа по паре логин/пароль.

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

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

×

About the authors

Evgeny A. Godovnikov

Ugra State University

Author for correspondence.
Email: judchin@rambler.ru

Candidate of Technical Sciences; Associate Professor, Institute of Digital Economics, Yugra State University

Russian Federation, Khanty-Mansiysk

Anatoliy V. Shicelov

Ugra State University

Email: anatoliy.shitselov@gmail.com

Senior Lecturer, Institute of Digital Economics

Russian Federation, Khanty-Mansiysk

Ruslan T. Usmanov

Ugra State University

Email: usmanovruslan322@gmail.com

Senior Lecturer, Institute of Digital Economics

Russian Federation, Khanty-Mansiysk

References

  1. Годовников, Е. А. СКУД офисного помещения. Выбор архитектуры / Е. А. Годовников, Р. Т. Усманов, А. В. Шицелов. – Текст : непосредственный // Евразийское научное объе-динение. – 2018. – № 46. – С. 67–69.
  2. Максимов, Р. Л. Разработка автоматической СКУД повышенной безопасности на базе типового решения СКУД BioSmart с использованием автоматного подхода / Р. Л. Мак-симов, А. Г. Рафиков. – Текст : непосредственный // Вопросы кибербезопасности. – 2015. – № 13. – C. 73–80.
  3. Нуйкин, А. В. Использование RFID-технологии в экосистеме интернета вещей / А. В. Нуйкин, А. С. Кравцов. – Текст : непосредственный // Сборник тезисов 3-й Междуна-родной научной конференции «Международный форум «Микроэлектроника-2017». – Москва, 2017. – С. 279–281.
  4. Исхаков, А. Ю. Схемы аутентификации пользователя в СКУД с использованием QR ко-дов и передачи данных по технологии NFC / А. Ю. Исхаков, Р. В. Мещеряков. – Текст : непосредственный // Информационное противодействие угрозам терроризма. – 2014. – № 22. – С. 11–15.
  5. Рабинович, А. С. Аутентификация пользователя информационной системы с использо-ванием технологии NFC / А. С. Рабинович, О. В. Казарин. – Текст : непосредственный // Вестник Московского финансово-юридического университета. – 2015. – № 1. – С. 166–171.
  6. Hill, Brian. Cisco: The Complete Reference / B. Hill. – McGraw-Hill Osborne Media, 2002. – 1300 p. – Text : direct.
  7. Меньшенин, А. О. Защищенный протокол взаимодействия «хост – считыватель NFC» / А. О. Меньшенин, А. В. Кораблин. – Текст : непосредственный // Безопасность инфор-мационных технологий. – 2012. – № 2. – С. 72–76.

Supplementary files

Supplementary Files
Action
1. JATS XML
Download

Copyright (c) 2019 Godovnikov E.A., Shicelov A.V., Usmanov R.T.

Creative Commons License
This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.

This website uses cookies

You consent to our cookies if you continue to use our website.

About Cookies