СПОСОБ И СИСТЕМА АВТОРИЗАЦИИ НОСИТЕЛЯ ЦИФРОВОГО КЛЮЧА Российский патент 2019 года по МПК G07C9/00 H04W12/06 

ОБЛАСТЬ ТЕХНИКИ

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

УРОВЕНЬ ТЕХНИКИ

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

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

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

[005] Эти системы контроля доступа должны поддерживать обмен данными между средствами считывания, ключами и центром управления. В зависимости от типа системы, они делятся на два базовых типа: проводные и автономные.

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

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

[008] Из уровня техники известна заявка на патент US 20050174214 A1 «Система контроля доступа», заявитель: Salto Systems SL, опубликовано: 11.08.2005. Данное техническое решение включает в себя средства считывания для средств, кодирующих ключи и средств идентификации пользователя, включающие в себя средство хранения идентификационного кода самого считывателя, причем упомянутое средство считывания соединено с управляющим средством средства открытия устройства доступа к определенному месту, которое открывает или запрещает открытие устройства доступа при чтении закодированных ключей и средств идентификации пользователя.

[009] Недостатком данного технического решения является взаимодействие средств авторизации (носителей ключей) с подсистемой администрирования доступа через считыватель средств авторизации, подключенный к сети передачи данных, поскольку предполагается использование смарт-карт. В предлагаемом решении средства авторизации (носители цифровых ключей), которыми являются смартфоны, взаимодействуют с подсистемой администрирования доступа напрямую, что ускоряет передачу данных между контроллерами управления и подсистемой администрирования доступа. Кроме того, в указанном патенте не указан способ проверки подлинности информации, передаваемой между подсистемами, что значительно снижает безопасность системы.

СУЩНОСТЬ ИЗОБРЕТЕНИЯ

[0010] Данное техническое решение направлено на устранение недостатков, свойственных решениям, известным из уровня техники.

[0011] Технической задачей или проблемой, решаемой в данном техническом решении, является обеспечение контроля и управления доступом пользователя к объекту посредством использования цифрового ключа.

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

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

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

[0015] В некоторых вариантах реализации изобретения формируют цифровой ключ пользователя хэш-функция MD5 и/или SHA-1, и/или SHA-256, и/или RIPEMD128, и/или RIPEMD-160, и/или CRC-32.

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

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

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

КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ

[0019] Признаки и преимущества настоящего технического решения станут очевидными из приведенного ниже подробного описания и прилагаемых чертежей, на которых:

[0020] На Фиг. 1 показан пример реализации системы авторизации пользователя на основании его цифрового ключа, где 100 - носитель цифровых ключей (мобильное устройство связи пользователя), 110 - подсистема выдачи и администрирования цифровых ключей, 120 - контроллер управления,

шаг 201: передача цифровых ключей из подсистемы 110 выдачи и администрирования цифровых ключей на носитель 100 цифровых ключей;

шаг 202: передача данных (записи о доступе пользователей) от контроллера 120 управления в 110 подсистему выдачи и администрирования цифровых ключей;

шаг 203: авторизация носителя 100 цифровых ключей на контроллере 120 управления и передача команд, получение данных от контроллера 120 управления (записи о доступе пользователей);

шаг 204: передача цифровых ключей от контроллера управления 120 на носитель 100 цифровых ключей;

шаг 205: передача цифровых ключей между носителями цифровых ключей (постоянные и временные гостевые ключи);

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

[0021] На Фиг. 2 показан пример реализации формирования цифрового ключа пользователя для контроллера 120 управления в виде блок-схемы;

[0022] На Фиг. 3 показан пример реализации формирования приветственного сообщения HelloRequest на носителе 100 цифровых ключей для отправки на контроллер 120 управления;

[0023] На Фиг. 4 показан пример реализации проверки приветственного сообщения HelloRequest при получении контроллером 120 управления сообщения от носителя 100 цифровых ключей.

[0024] На Фиг. 5 показан пример реализации способа авторизации пользователя на основании его цифрового ключа в виде-блок схемы, где цифровой ключ формируется в подсистеме выдачи и администрирования цифровых ключей.

ПОДРОБНОЕ ОПИСАНИЕ ИЗОБРЕТЕНИЯ

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

[0026] Техническое решение может быть реализовано в виде распределенной компьютерной системы, компоненты которой являются облачными или локальными серверами.

[0027] В данном решении под системой подразумевается компьютерная система или автоматизированная система (АС), ЭВМ (электронно-вычислительная машина), ЧПУ (числовое программное управление), ПЛК (программируемый логический контроллер), компьютеризированная система управления и любые другие устройства, способные выполнять заданную, четко определенную последовательность вычислительных операций (действий, инструкций).

[0028] Под устройством обработки команд подразумевается электронный блок либо интегральная схема (микропроцессор), исполняющая машинные инструкции (программы).

[0029] Устройство обработки команд считывает и выполняет машинные инструкции (программы) с одного или более устройства хранения данных. В роли устройства хранения данных могут выступать, но, не ограничиваясь, жесткие диски (HDD), флеш-память, ПЗУ (постоянное запоминающее устройство), твердотельные накопители (SSD), оптические приводы, облачные хранилища данных.

[0030] Программа - последовательность инструкций, предназначенных для исполнения устройством управления вычислительной машины или устройством обработки команд.

[0031] Контроллер - устройство управления в электронике и вычислительной технике.

[0032] Ключ цифровой подписи - элемент секретных данных, специфичный для субъекта и используемый только данным субъектом в процессе формирования цифровой подписи.

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

[0034] Электронная подпись (ЭП), Электронная цифровая подпись (ЭЦП), Цифровая подпись (ЦП) - реквизит электронного документа, полученный в результате криптографического преобразования информации с использованием закрытого ключа подписи и позволяющий проверить отсутствие искажения информации в электронном документе с момента формирования подписи (целостность), принадлежность подписи владельцу сертификата ключа подписи (авторство), а в случае успешной проверки подтвердить факт подписания электронного документа (неотказуемость).

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

[0036] Цифровой ключ содержит данные криптографического ключа пользователя, права клиента, удостоверенные подсистемой 110 выдачи и администрирования цифровых ключей. В некоторых вариантах реализации цифровой ключ задает возможные способы подключения к устройству контроля доступа, который подключен к контроллеру 120 управления. В случае задания способов подключения (например, по протоколам передачи данных Bluetooth, Bluetooth LE, WIFI, NFC и т.д.) к устройству контроля доступа получают идентификатор контроллера 120 управления, сетевой адрес контроллера 120 управления, а также идентификатор канала подключения (UUID). Уникальный идентификатор контроллера 120 управления может быть как числовым, так и символьным, не ограничиваясь. Данные цифрового ключа могут включать криптографический ключ пользователя и случайную бинарную последовательность, с помощью которой сформированы права клиента, удостоверенные подсистемой 110 выдачи и администрирования цифровых ключей, при помощи формирования подписанного токена.

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

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

[0039] Компактная конструкция устройства контроля доступа позволяет устанавливать его, например, на дверной раме, на парковках, в жилых комплексах, в гостиницах, офисах, тренажерных залах, конференц-залах, на входах для персонала, ночных входах для гостей.

[0040] Контроллер 120 управления доступом предназначен для контроля и управления доступом, например, устройства контроля доступом при помощи смартфона и представляет собой микропроцессорное электронное устройство. Контроллер 120 управления может использоваться для управления доступом через двери, шлагбаумы, турникеты и другие средства ограничения доступа как самостоятельно, так и в составе Системы контроля и управления доступом (СКУД). В некоторых вариантах осуществления термин "контроллер" может подразумевать микроконтроллер или просто некое понятие в узком смысле аппаратного средства в виде контроллера. Микроконтроллер может быть размещен таким образом, что его функции будут разделены, например контроллерная часть (управляющая) будет отделена от вычислительной части, находящейся в другом чипе. Контроллер 120 управления может быть снабжен защищенной от стирания внутренней памятью, предпочтительно EEPROM-типа. Для достижения приемлемого уровня безопасности контроллер 120 управления может также содержать модуль загрузки (загрузчик операционной системы) для контроля за несанкционированным вмешательством в загружаемую прикладную программу контроллера 120 управления. Загрузчик операционной системы может размещаться в защищенной части памяти процессора контроллера, предназначенной только для чтения, причем он запускается после каждого сброса устройства в исходное (нулевое) состояние. Загрузчик выполняет функцию контроля, отслеживая, не претерпели ли изменения операционная система или прикладные программы в результате несанкционированного вмешательства. После каждого сброса на нуль загрузчик вычисляет значение хеш-функции (электронно-цифровая подпись) на основе содержимого внешней флэш-памяти программы, в которой хранятся операционная система и прикладные программы. Затем он сравнивает полученный результат со значением, которое хранится во внешней EEPROM-памяти. Если данные совпадают, загрузчик передает управление операционной системе. Если данные не совпадают, загрузчик уменьшает на единицу регистрируемое счетчиком число неудачных попыток, а затем останавливает операцию. В том случае, если счетчик достигает значения нуля, запуск контроллера 120 управления становится невозможным. В указанной памяти может храниться операционная система (как начало и конец адресуемой области), притом, что значение хеш-функции для емкости памяти (электронно-цифровая подпись) сохраняется в контроллере при первом сохранении операционной системы и приложения (прикладной программы). В дальнейшем произвести изменение этих данных будет невозможно.

[0041] В некоторых вариантах реализации изобретения в качестве контроллера управления может использоваться обычный микроконтроллер на базе микропроцессора разрядностью 8 бит, 16 бит, 32 бита или 64 бита.

[0042] При установке контроллера 120 управления на парковке используется внешняя направленная антенна. Пользователи могут открывать контроллер 120 управления тремя способами:

• Автоматически по приближению;

• С помощью жеста;

• По кнопке из приложения.

[0043] В случае, когда въезд и выезд осуществляются через разные шлагбаумы, установленные рядом, антенны для обоих направлений должны быть направлены на подъезжающие автомобили и разнесены на максимальное расстояние. По приближению или жесту будет срабатывать контроллер 120 управления, антенна которого будет ближе к смартфону.

[0044] При установке контроллера 120 управления на подъезде пользователи также могут открывать контроллер 120 управления тремя способами:

• Автоматически по приближению;

• С помощью жеста;

• По кнопке из приложения.

[0045] Обычно, антенна устанавливается снаружи подъезда, за счет этого автооткрытие срабатывает при входе в подъезд с улицы. Для выхода из подъезда используется кнопка выхода, либо датчик движения, подключаемый к контроллеру 120 управления как внешнее устройство.

[0046] При установке контроллера 120 управления в офисе могут использовать варианты контроллера 120 управления в корпусах для монтажа стену, в котором используется направленная или всенаправленная антенна. Вариант контроллера 120 управления в корпусе на стену устанавливается снаружи помещения рядом с дверью.

[0047] В случае использования корпуса на стену пользователи могут открывать контроллер следующими способами:

• поднести смартфон к контроллеру на расстояние 5-10 см;

• с помощью кнопки или датчика на стене;

• с помощью жеста смартфоном;

• по кнопке из мобильного приложения на смартфоне.

[0048] Способ авторизации пользователя на основании его цифрового ключа, как показано на Фиг. 5, может включать следующие шаги.

[0049] Шаг 501: формируют по меньшей мере один цифровой ключ по меньшей мере одного пользователя в подсистеме выдачи и администрирования цифровых ключей.

[0050] В подсистеме 110 выдачи и администрирования цифровых ключей осуществляют предварительно формирование цифровых ключей пользователей, как показано на Фиг. 2.

[0051] Подсистема 110 выдачи и администрирования цифровых ключей содержит по меньшей мере один модуль связи, который может представлять собой модем мобильной связи, поддерживающий такие режимы связи, как GSM, GPRS, EDGE, CDMA, EVDO, UMTS, LTE, WiFi и спутниковую связь, или же может представлять собой модем стационарной связи, поддерживающий такие сети стационарной связи, как сеть ADSL или кабельная сеть.

[0052] Различные описанные здесь варианты осуществления подсистемы 110 выдачи и администрирования цифровых ключей можно реализовать в любой компьютерной системе или среде, имеющей любое количество блоков памяти или запоминающих устройств и любое количество приложений и процессов, выполняющихся на любом количестве запоминающих устройств. Эта среда включает в себя, но без ограничения, среду, где компьютеры-серверы и компьютеры-клиенты обеспечены в сетевой среде или в распределенной вычислительной среде, имеющей удаленное или локальное хранилище.

[0053] Существует ряд систем, компонентов и сетевых конфигураций, которые поддерживают распределенные вычислительные среды. Например, вычислительные системы могут быть соединены друг с другом проводными или беспроводными каналами передачи данных, локальными сетями или глобальными сетями. В настоящее время, многие сети подключены к Интернету, который обеспечивает инфраструктуру для широко распределенных вычислений и охватывает большое количество различных сетей, хотя любую сетевую инфраструктуру можно использовать для иллюстративных средств связи, присущих методам, описанным в различных вариантах осуществления.

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

[0055] В сетевой среде, где сетью/шиной связи является Интернет, серверы могут быть web-серверами, с которыми клиенты осуществляют связь по любому из разнообразных известных протоколов, например, протоколу передачи гипертекстовых файлов (HTTP). Серверы также могут выступать в качестве клиентов и т.д., что может служить характеристикой распределенной вычислительной среды.

[0056] В некоторых вариантах осуществления формирование цифровых ключей осуществляют на контроллере 120 управления.

[0057] В данном техническом решении для формирования цифровых ключей могут использоваться любые хэш-функции, удовлетворяющие выбранному уровню криптографической стойкости, например: MD5, SHA-1, SHA-256, RIPEMD128, RIPEMD-160, CRC-32 и другие, не ограничиваясь. В качестве функций шифрования могут использоваться любые известные из уровня техники блочные и/или поточные симметричные алгоритмы шифрования, например: AES, DES, 3DES, RC4 и др.

[0058] Таким образом, формируют цифровой ключ пользователя для контроллера 120 управления по следующему алгоритму.

[0059] В подсистеме 110 выдачи и администрирования цифровых ключей для каждого контроллера 120 управления хранится мастер-ключ и возможные способы подключения к контроллеру. Мастер-ключ является бинарной последовательностью, длина которой зависит от выбранной хэш-функции и алгоритма шифрования (например, 64, 128, 256, 512, 1024, 2048 бит). Посредством любого генератора псевдослучайных чисел, известного из уровня техники, в подсистеме 110 выдачи и администрирования цифровых ключей формируют модификатор клиентского ключа (в криптографии еще называют термином "соль"), представляющий собой случайную бинарную последовательность. В качестве генератора псевдослучайных может использоваться алгоритм RC4, ISAAC, SEAL, SNOW, алгоритм Блюм - Блюма - Шуба, а также счетчики с криптографическими хеш-функциями или криптостойкими блочными шифрами вместо функции вывода.

[0060] В некоторых вариантах реализации изобретения могут использоваться следующие варианты генераторов псевдослучайных чисел: генераторы с несколькими регистрами сдвига, генераторы с нелинейными преобразованиями, мажоритарные генераторы шифрования А5/х.

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

[0062] Затем на основании мастер-ключа контроллера 120 управления и сформированного на предыдущем шаге модификатора клиентского ключа используют хэш-функцию и определяют клиентский ключ.

[0063] Из набора параметров, требующих удостоверения цифровой подписью (клиентский модификатор сообщения (клиентская соль), идентификатор пользователя, признак административных прав пользователя, время начала действия прав, время окончания действия прав и др.), формируют данные токена клиентского ключа посредством объединения (или другими словами конкатенации) блоков данных входящих в него параметров (запись наборов строк друг за другом). Для этого значения определяют электронную цифровую подпись Signature, которая является бинарной последовательностью, полученной в результате вычисления хеш-функции от данных токена клиентского ключа и мастер-ключа контроллера 120 управления. Далее формируют права клиента (токен), удостоверенные подсистемой 110 выдачи и администрирования цифровых ключей, посредством объединения данных токена клиентского ключа и его цифровой подписи, которые впоследствии могут шифроваться с использованием мастер-ключа контроллера 120 управления.

[0064] В итоге (права клиента) токен может иметь следующий вид:

[0065]

[0066] Цифровой ключ создается как объединение блоков данных следующих параметров, причем каждый представляет собой численную или символьную последовательность: способы подключения к контроллеру, криптографический ключ клиента, токен.

[0067] Шаг 502: передают сформированный по меньшей мере один цифровой ключ по меньшей мере одного пользователя из подсистемы выдачи и администрирования цифровых ключей носителю цифрового ключа.

[0068] В варианте реализации, когда цифровой ключ формируют на контроллере управления, передают соответственно сформированный по меньшей мере один цифровой ключ по меньшей мере одного пользователя из контроллера управления носителю цифрового ключа.

[0069] После формирования цифрового криптоключа осуществляют авторизацию носителя 100 цифрового ключа, которым может быть мобильное устройство связи пользователя (мобильный телефон, смартфон, планшет и так далее), на контроллере 120 управления.

[0070] Для этого отправляют сообщение HelloRequest от носителя 100 цифрового ключа на контроллер 120 управления. В некоторых вариантах реализации данного изобретения контроллер 120 управления может быть установлен рядом с точкой доступа пользователя, которой может быть дверь, шлагбаум, турникет, ворота, и т.п., не ограничиваясь.

[0071] Приветственное сообщение HelloRequest формируется на носителе 100 цифровых ключей для отправки на контроллер 120 управления следующим образом, как показано на Фиг. 3.

[0072] С помощью любого генератора псевдослучайных чисел в носителе 100 цифровых ключей генерируется параметр helloSalt - случайная бинарная последовательность, которая также называется солью приветственного сообщения.

[0073] Затем формируют данные приветственного сообщения (в рамках процесса "рукопожатия") как конкатенацию блоков данных следующих параметров: идентификатор сообщения с начала сессии (сессия открывается с отправкой первого сообщения HelloRequest), права клиента, удостоверенные подсистемой 110 выдачи и администрирования цифровых ключей, текущее время системы, имя носителя 100 цифровых ключей.

[0074] На основании криптографического клиентского ключа и сформированной соли создают бинарную последовательность, которую получают в результате вычисления хеш-функции двух этих значений.

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

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

[0077] Итоговое сообщение HelloRequest формируется как сумма блоков данных заголовка транспортного пакета (Header), данных приветственного сообщения и цифровой подписи. Пример сообщения:

[0078] {type=1}.

[0079] {id=1

[0080] соль равна "V1 U0WEs4NGI5N0tI";

[0081] текущее время равно 98876623775;

[0082] имя носителя цифрового ключа равно "smart1234";

[0083] цифровая подпись равна следующему значению

[0084] Таким образом сформированное сообщение HelloRequest отправляется носителем 100 цифрового ключа в контроллер 120 управления.

[0085] Шаг 503: осуществляют авторизацию носителя цифрового ключа на контроллере управления при подходе пользователя в заранее заданную зону действия сигнала контроллера управления.

[0086] При получении контроллером 120 управления сообщения HelloRequest, предварительно он проверяет права клиента (токен), как показано на Фиг. 4, следующим образом. Вычисляет значение цифровой подписи посредством определения хэш-функции от мастер-ключа и данных токена. Если вычисленное значение цифровой подписи Signature совпадает с полученным в токене, значит контроллер доверяет правам клиента, иначе HelloRequest отклоняется. В примерном варианте осуществления данный шаг происходит следующим образом.

[0087] Полученные в HelloRequest права клиента, удостоверенные подсистемой 110 выдачи и администрирования цифровых ключей имеют следующий вид.

[0088] Клиентский ключ состоит из токена и модификатора и токена

[0089] Соль клиентского ключа имеет значение "ZhbVC8vnm0aOTSd".

[0090] Уникальный идентификатор клиента в системе имеет значение "8dAIHdWTBk2jwKfDAOuWJQ''.

[0091] Пользователь не является администратором системы, поэтому IsAdmin=false. Время начала действия права имеет значение 1418122051, а время окончания действия права 1428122051. Цифровая подпись имеет значение "JBVq5USV0DP87pfMrON4ExRP8m9rYXfvRzGim378XFY=".

[0092] Определенное контроллером 120 управления значение цифровой подписи совпадает с полученным в HelloRequest, в связи с чем контроллер 120 управления доверяет полученным правам клиента.

[0093] В некоторых вариантах реализации изобретения проверяют дополнительные параметры, такие как соль, уникальный идентификатор пользователя, является ли пользователь администратором, время начала действия прав, время окончания действия прав. Если текущее время находится за пределами данного периода, значит пользователь не обладает необходимыми правами для управления контроллером 120 управления. Если пользователь обладает дополнительными правами администратора, то ему позволяется расширенный перечень операций с контроллером 120 управления, включая настройку и обновление.

[0094] Аналогичным образом проверяется значение HelloRequest, как показано выше.

[0095] Ответ контроллера 120 управления носителю 100 цифровых ключей HelloResponce формируется следующим образом.

[0096] Генерируют соль (модификатор) для сессии как случайную бинарную последовательность. Затем формируют ответное сообщение как конкатенацию блоков уникального идентификатора сообщения с начала сессии, состояния исполнительных устройств (для устройства контроля доступа это состояния "Открыто" и "Закрыто") и соли сессии.

[0097] Затем формируют сетевой пакет как конкатенацию ответного сообщения и заголовка сетевого пакета (Header). после чего для сетевого пакета формируют цифровую подпись посредством получения хэш-значения от сетевого пакета ответного сообщения и хэш-значения от клиентского ключа и соли.

[0098] Итоговое ответное сообщение HelloResponce отправляется контроллером 120 управления носителю 100 цифровых ключей. Носитель 100 цифровых ключей проверяет ответное сообщение HelloResponce посредством определения цифровой подписи и вычисления хэш-функции от сетевого пакета ответного сообщения и хэш-значения от клиентского ключа и соли, которая является бинарной последовательностью. Если определенное значение цифровой подписи совпадает с полученным в HelloResponce, значит носитель 100 цифрового ключа доверяет HelloResponce, иначе сообщение отклоняется.

[0099] Шаг 504: в случае успешной авторизации направляют по меньшей мере одну команду из носителя цифрового ключа на по меньшей мере один контроллер управления.

[00100] После авторизации носитель 100 цифрового ключа может отправлять контроллеру 120 управления команды. Команды для контроллера 120 управления могут формироваться следующим образом. Вычисляют ключ сессии как хэш от соли сессии и хэш-значения от клиентского ключа и соли, которая является бинарной последовательностью. Затем из заданного набора полей создается команда, которая содержит поле Т, которое хранит время, прошедшее с момента подключения носителя 100 цифрового ключа к контроллеру 120 управления (или любого другого момента, смещенного на заданное время) до момента отправки команды. Данное время защищает от атаки путем перехвата сообщения и отправки его позднее. Для каждой команды набор необходимых полей может варьироваться. Создают сетевой пакет, содержащий команду и заголовок пакета (Header), для которой формируется цифровая подпись посредством определения хэш-значения от ключа сессии и сетевого пакета. Итоговая команда отправляется носителем 100 цифрового ключа в контроллер 120 управления.

[00101] Шаг 505: проверяют права на выполнение полученной по меньшей мере одной команды посредством контроллера управления.

[00102] При получении команды на контроллере 120 управления проверяют команду. Контроллер проверяет цифровую подпись команды следующим образом. Определяют хэш-значение от ключа сессии и сетевого пакета. Если вычисленное значение цифровой подписи совпадает с полученным в команде, значит контроллер 120 управления доверяет команде, иначе выполнение команды отклоняется. Также контроллер 120 управления проверяет время отправки команды. Время Т, пришедшее в команде от носителя 100 цифрового ключа, сравнивается с вычисленным в контроллере 120 управления временем Т2. Если разница между Т2 и Т больше заданного значения, команда отклоняется.

[00103] В некоторых вариантах реализации контроллер 120 управления проверяет права на выполнение команды. Контроллер сравнивает команду с правами, разрешенными в правах клиента, удостоверенных подсистемой 110 выдачи и администрирования цифровых ключей. Если команда разрешена правами, контроллер 120 управления ее выполняет, иначе отказывает в выполнении.

[00104] Команды, не ограничиваясь, могут быть следующими:

• сообщение для инициализации сессии между мобильным клиентом и контроллером;

• открыть/закрыть контроллер;

• запрос информации о версии прошивки контроллера;

• транзитное сообщение от сервера к контроллеру;

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

• запрос на получение конфигурации контроллера;

• запрос на обновление конфигурации контроллера;

• команда автооткрытия контроллера, когда мобильный клиент находится ближе порогового значения;

• запрос логов контроллера для передачи на сервер;

• команда перегрузиться контроллеру;

• запрос текущего состояния контроллера;

• произвольное сообщение.

[00105] В других вариантах реализации настоящего изобретения осуществляют авторизацию и проверку носителя 100 цифрового ключа с использованием шифрования сообщений, которая состоит из нескольких стадий: авторизация, отправка команды и проверка команды.

[00106] Сообщение HelloRequest формируется носителем 100 цифрового ключа следующим образом.

[00107] Носитель 100 цифрового ключа получает от контроллера 120 управления соль - случайную бинарную последовательность. Контроллер 120 управления меняет соль каждые t секунд и хранит последние n солей. Носитель 100 цифрового ключа использует эти соли при формировании приветственного сообщения. При получении сообщения от клиента неизвестно, какую именно соль он использовал и перебирают все. При этом если клиент использовал соль старше 10 с - ее отклоняют, что обеспечивает защиту от перехвата и отправки сообщения позднее.

[00108] Затем формируют данные приветственного сообщения (в рамках процесса рукопожатия) как конкатенацию блоков данных следующих параметров: время с момента подключения, идентификатор клиентского ключа, права клиента, удостоверенные подсистемой 110 выдачи и администрирования цифровых ключей, текущее время системы, имя носителя 100 цифровых ключей, команда контроллеру 120 управления.

[00109] На основании уникального клиентского ключа и полученной от контроллера 120 управления соли создают бинарную последовательность, которую получают в результате вычисления хеш-функции двух этих значений.

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

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

[00112] Затем осуществляют шифрование данных приветственного сообщения на helloKey любым блочным или поточным симметричным шифром с достаточным уровнем криптографической стойкости (например, AES, DES, 3DES, RC4 и др.), получается зашифрованное сообщение HelloRequest, к которому перед отправкой добавляют посредством конкатенации соль.

[00113] В итоге сформированное сообщение HelloRequest отправляется носителем 100 цифрового ключа на контроллер 120 управления, где осуществляется его проверка.

[00114] При получении контроллером 120 управления сообщения HelloRequest, предварительно он проверяет определяет значение клиентского ключа посредством определения хэш-функции от мастер-ключа и соли клиента. Далее определяется значение helloKey посредством определения хэш-функции от клиентского ключа и соли, сохраненной ранее на контроллере, которая определяется посредством перебора значений.

[00115] Затем с помощью значения helloKey расшифровывают сообщение HelloRequest. Для сетевого пакета определяют цифровую подпись посредством определения хэш-функции от helloKey и данного сетевого пакета.

[00116] Если определенное значение цифровой подписи совпадает с полученным в приветственном сообщении HelloRequest, значит контроллер 120 управления доверяет носителю 100 цифровых ключей и удаляет использованную соль из сохраненных значений, иначе HelloRequest отклоняется.

[00117] Данная процедура проверки сообщения HelloRequest ниже приводится в качестве примера реализации.

[00118] Полученное на контроллере 120 управления сообщение имеет следующий вид:

[00119] type=1;

[00120] id message=1;

[00121] значение соли="V1U0WEs4NGI5N0tI";

[00122] текущее время=98876623775;

[00123] имя носителя="smart1234".

[00124] Электронная цифровая подпись имеет значение:

[00125] {signature="BwoEYfmkX1kdI19GD7kPwMUJ5nNtFUZ5VklyAXohnuA="}

[00126] Вычисленное значение клиентского ключа принимает следующее значение HASH(мастер-ключ, соль клиента)=

[00127] Вычисленное значение helloKey принимает следующее значение HESH (клиентский ключ, соль) =

[00128] Сетевой пакет имеет следующий вид:

[00129] {type=1}.

[00130] {id=1

[00131]

[00132] текущее время = 98876623775;

[00133] имя носителя = "smart1234".

[00134] Вычисленное значение электронной цифровой подписи принимает следующее значение HASH(helloKey, сетевой пакет)

[00135] Оно совпадает с полученным в HelloRequest значению электронной цифровой подписи, значит контроллер 120 управления доверяет полученным правам носителя 100 цифрового ключа.

[00136] Отправка команды контроллеру 120 управления по аналогичной выше процедуре, только сама команда предварительно шифруется значением helloKey и затем аналогичным образом расшифровывается при получении.

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

[00138] Композитные ключи для заданного периметра доступа формируются следующим образом:

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

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

[00139] Композитный цифровой ключ может включать в себя следующие данные:

- Список цифровых ключей;

- Идентификатор пользователя;

- Название;

- Изображение;

- Период действия;

- Координаты объекта доступа;

- Информацию о стоимости услуг доступа;

- Контакты администратора доступа и технической поддержки.

[00140] Элементы заявляемого технического решения находятся в функциональной и конструктивной взаимосвязи, а их совместное использование приводит к созданию нового и уникального технического решения.

[00141] Все компоненты, используемые в системе, могут быть реализованы с помощью электронных компонент, используемых для создания цифровых интегральных схем, что очевидно для специалиста в данном уровне техники. Не ограничиваясь, могут использоваться микросхемы, логика работы которых определяется при изготовлении, или программируемые логические интегральные схемы (ПЛИС), логика работы которых задается посредством программирования. Для программирования используются программаторы и отладочные среды, позволяющие задать желаемую структуру цифрового устройства в виде принципиальной электрической схемы или программы на специальных языках описания аппаратуры: Verilog, VHDL, AHDL и др. Альтернативой ПЛИС могут быть программируемые логические контроллеры (ПЛК), базовые матричные кристаллы (БМК), требующие заводского производственного процесса для программирования; ASIC специализированные заказные большие интегральные схемы (БИС), которые при мелкосерийном и единичном производстве существенно дороже.

[00142] Обычно, сама микросхема ПЛИС состоит из следующих компонент:

• конфигурируемых логических блоков, реализующих требуемую логическую функцию;

• программируемых электронных связей между конфигурируемыми логическими блоками;

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

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

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

[00145] Однако следует иметь в виду, что все эти и подобные термины должны быть связаны с соответствующими физическими величинами, и что они представляют собой просто удобные метки, применяемые к этим величинам. Если иное специально и недвусмысленно не указано в нижеследующем описании, следует принимать, что везде по тексту такие термины как "определение", "вычисление", "расчет", "получение", "установление", "изменение" и т.п., относятся к действиям и процессам вычислительного устройства или аналогичного электронного вычислительного устройства, которое работает с данными и преобразует данные, представленные в виде физических (например, электронных) величин в регистрах и памяти вычислительного устройства, в другие данные, аналогичным образом представленные в виде физических величин в памяти или регистрах вычислительного устройства, либо других подобных устройствах хранения, передачи или отображения информации.

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

Изобретение относится к области вычислительной техники. Техническим результатом является повышение безопасности авторизации носителя цифрового ключа для управления распределенными контроллерами управления, не подключенными к сети передачи данных. Раскрыт способ авторизации носителя цифрового ключа, включающий следующие шаги: формируют по меньшей мере один цифровой ключ по меньшей мере одного пользователя в подсистеме выдачи и администрирования цифровых ключей; передают сформированный по меньшей мере один цифровой ключ по меньшей мере одного пользователя из подсистемы выдачи и администрирования цифровых ключей носителю цифрового ключа; осуществляют авторизацию носителя цифрового ключа на контроллере управления при подходе пользователя в заранее заданную зону действия сигнала устройства контроля доступа, с которым соединен контроллер управления, причем контроллеры управления не подключены к сети передачи данных, а взаимодействие между контроллерами и подсистемой администрирования осуществляется через носители цифровых ключей, подключенных к сети передачи данных; в случае успешной авторизации направляют по меньшей мере одну команду из носителя цифрового ключа на по меньшей мере один контроллер управления; проверяют права на выполнение полученной по меньшей мере одной команды посредством контроллера управления, причем если команда разрешена правами, контроллер управления ее выполняет, иначе отказывает в выполнении. 3 н. и 7 з.п. ф-лы, 5 ил.

1. Способ авторизации носителя цифрового ключа, включающий следующие шаги:

• формируют по меньшей мере один цифровой ключ по меньшей мере одного пользователя в подсистеме выдачи и администрирования цифровых ключей;

• передают сформированный по меньшей мере один цифровой ключ по меньшей мере одного пользователя из подсистемы выдачи и администрирования цифровых ключей носителю цифрового ключа;

• осуществляют авторизацию носителя цифрового ключа на контроллере управления при подходе пользователя в заранее заданную зону действия сигнала устройства контроля доступа, с которым соединен контроллер управления, причем контроллеры управления не подключены к сети передачи данных, а взаимодействие между контроллерами и подсистемой администрирования осуществляется через носители цифровых ключей, подключенных к сети передачи данных;

• в случае успешной авторизации направляют по меньшей мере одну команду из носителя цифрового ключа на по меньшей мере один контроллер управления;

• проверяют права на выполнение полученной по меньшей мере одной команды посредством контроллера управления, причем

если команда разрешена правами, контроллер управления ее выполняет, иначе отказывает в выполнении.

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

• получают мастер-ключ контроллера управления;

• посредством генератора псевдослучайных чисел формируют соль;

• на основании мастер-ключа контроллера управления и сформированной на предыдущем шаге соли определяют клиентский ключ как хэш-значение;

• формируют электронную цифровую подпись прав пользователя на основании мастер-ключа.

3. Способ по п. 1, характеризующийся тем, что формируют цифровой ключ пользователя с использованием хэш-функций MD5, и/или SHA-1, и/или SHA-2, и/или RIPEMD128, и/или RIPEMD-160, и/или CRC-32.

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

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

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

7. Способ авторизации носителя цифрового ключа, включающий следующие шаги:

• формируют по меньшей мере один цифровой ключ по меньшей мере одного пользователя в контроллере управления;

• передают сформированный по меньшей мере один цифровой ключ по меньшей мере одного пользователя из контроллера управления носителю цифрового ключа;

• осуществляют авторизацию носителя цифрового ключа на контроллере управления при подходе пользователя в заранее заданную зону действия сигнала устройства контроля доступа, с которым соединен контроллер управления, причем контроллеры управления не подключены к сети передачи данных, а взаимодействие между контроллерами и подсистемой администрирования осуществляется через носители цифровых ключей, подключенных к сети передачи данных;

• в случае успешной авторизации направляют по меньшей мере одну команду из носителя цифрового ключа на по меньшей мере один контроллер управления;

• проверяют права на выполнение полученной по меньшей мере одной команды посредством контроллера управления, причем

если команда разрешена правами, контроллер управления ее выполняет, иначе отказывает в выполнении.

8. Система авторизации носителя цифрового ключа, содержащая:

• подсистему выдачи и администрирования цифровых ключей, выполненную с возможностью

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

передачи сформированного по меньшей мере одного цифрового ключа по меньшей мере одного пользователя носителю цифрового ключа;

• по меньшей мере один носитель цифровых ключей, выполненный с возможностью

направления по меньшей мере одной команды на по меньшей мере один контроллер управления в случае успешной авторизации на данном контроллере управления;

• по меньшей мере один контроллер управления, выполненный с возможностью

осуществления авторизации носителя цифрового ключа при подходе пользователя в заранее заданную зону действия сигнала контроллера;

управления по меньшей мере одним устройством контроля доступа;

проверки прав на выполнение полученной по меньшей мере одной команды от носителя цифрового ключа, причем

если команда разрешена правами, контроллер управления ее выполняет,

иначе отказывает в выполнении.

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

9. Система по п. 8, характеризующаяся тем, что контроллером управления является микроконтроллер.

10. Система по п. 8, характеризующаяся тем, что носителем цифрового ключа является мобильное устройство связи пользователя.