ИНТЕРНЕТА ВЕЩЕЙ (ЮТ)

Область техники

[0001] Настоящее техническое решение относится к области организации схем сетевого обмена данными между множеством устройств, в частности, для обмена данными между устройствами интернета вещей (1оТ).

Уровень техники

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

[0003] Для 1оТ также существуют внедрения в области блокчейн протоколов для организации обмена данными и доверительного взаимодействия между участниками обмена в едином распределенном реестре. Например, такое решение известно из заявки US 20180183587 (VMware Inc., 28.06.2018). Сложность применения данного подхода для широкого спектра устройств является недостаточная защищенность при обмене данными 1оТ устройств, при применении конвенционных подходов реализации блокчейн-инфраструктуры на базе программной логики.

[0004] Для частичного нивелирования существующих проблем предлагается использовать защищенные аппаратные носители обмена данными, например, eSIM или UICC карты (чипы, смарт-карты), которые будут выполнять необходимые операции проверки/подтверждения пакетов данных, которыми 1оТ устройства обмениваются в процессе своей деятельности. Например, упоминание возможности таких решений изложено в заявках WO 2018066362 (NEC CORP, 12.04.2018), WO 2017082966 (Intel IP Corp., 18.05.2017).

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

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

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

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

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

регистрируют на облачной платформе список доверенных 1оТ устройств и соответствующих им идентификаторов (ГО) для осуществления информационного обмена, причем в ходе упомянутой регистрации записывают на упомянутый модуль безопасности доверенных 1оТ устройств набор ключей шифрования для выполнения упомянутых криптографических операций, причем указанные ключи являются симметричными и одноразовыми, и копия набора ключей каждого доверенного 1оТ устройства хранится в модуле безопасности облачной платформы и/или доверенных 1оТ устройствах, участвующих в обмене данными;

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

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

[0009] В одном из частных вариантов реализации способа 1оТ устройства включают в себя управляемые и/или управляющие устройства.

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

[ООП] В другом частном варианте реализации способа ключи шифрования формируются в модуле безопасности 1оТ устройства из числовой последовательности.

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

[0013] В другом частном варианте реализации способа аппаратный модуль безопасности представляет собой UICC, eUICC, Ш1СС или их сочетания.

[0014] В другом частном варианте реализации способа ID IoT устройств представляет собой IMEI номер, МАС-адрес, IP-адрес , Bluetooth адрес или их сочетания.

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

[0016] В другом частном варианте реализации способа протокол представляет собой Hyperledger Fabric.

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

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

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

[0021 ] В другом частном варианте реализации способа обработка информационного пакета включает в себя проверку контроля целостности пакета.

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

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

[0024] В другом предпочтительном варианте осуществления заявленного решения представлена система обеспечения взаимодействия устройств интернета вещей (1оТ), включающая множеством устройств 1оТ и облачную платформу, в которой

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

облачная платформа выполнена с возможностью регистрировать список доверенных 1оТ устройств и соответствующих им идентификаторов (ID) для осуществления информационного обмена, причем в ходе упомянутой регистрации записывают на упомянутый модуль безопасности доверенных 1оТ устройств набор ключей шифрования для выполнения упомянутых криптографических операций, причем указанные ключи являются симметричными и одноразовыми, и копия набора ключей каждого доверенного 1оТ устройства хранится в модуле безопасности облачной платформы и/или доверенных 1оТ устройствах, участвующих в обмене данными;

причем модули безопасности устройства инициатора обмена данными и принимающей стороны обеспечивают

обмен данными между доверенными 1оТ устройствами или по меньшей мере одним 1оТ устройством и облачной платформой;

выполнение формирования информационного пакета, содержащего данные и ID IoT устройства инициатора;

обработку упомянутого информационного пакета с помощью ключа шифрования;

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

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

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

[0025] В одном из частных вариантов реализации системы обмен данными между 1оТ устройствами и облачной платформой выполняется по протоколу беспроводной и/или проводной передачи данных.

[0026] В другом частном варианте реализации системы протокол выбирается из группы: WLAN, WAN, Wi-Fi, GSM, GPRS, LTE, 5G, ZigBee, LPWAN, LoRaWan, Bluetooth, BLE, TCP/IP, ModBus, NB-IoT, Z-Wave, Sigfox, Ethernet.

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

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

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

[0030] При этом ключи шифрования являются неизвлекаемыми из модуля безопасности.

Описание чертежей

[0031] Фиг. 1 иллюстрирует общий вид 1оТ устройства.

[0032] Фиг. 2 иллюстрирует основные компоненты модуля безопасности.

[0033] Фиг. 3 иллюстрирует общий вид системы взаимодействия 1оТ устройств.

[0034] Фиг. 4 иллюстрирует пример взаимодействия устройств с использованием ключей шифрования.

[0035] Фиг. 5 иллюстрирует пример генерирования ключей шифрования.

[0036] Фиг. 6— Фиг. 7 иллюстрируют пример работы заявленного решения с помощью смарт-контрактов.

[0037] Фиг. 8 иллюстрирует осуществление решение на примере каршеринга. Осуществление изобретения

[0038] На Фиг. 1 представлен общий вид примера 1оТ устройства (100), применяемого в рамках реализации заявленного решения. Настоящее техническое решение осуществляется за счет снабжения участвующих в информационном обмене устройств Интернета вещей или 1оТ устройств (100) специализированным модулем безопасности (105), который обеспечивает защищенное исполнение необходимых процедур по обмену данными между участниками 1оТ инфраструктуры.

[0039] В общем виде устройство (100) содержит вычислительный модуль (101), одно или более средств памяти (102) или устройств оперативного или постоянного хранения данных, средства ввода/вывода информации (103), интерфейсы ввода/вывода информации (104), модуль безопасности (105) и средство сетевого взаимодействия (106). Элементы устройства (100) могут, в частности, связываться между собой посредством шины данных (110), либо же соединяться с помощью иных известных принципов, исходя из конкретной реализации и аппаратного воплощения устройства (100). При этом специалистам должно быть очевидно, что набор элементов устройства (100) может быть различным при его частных случаях реализации.

[0040] Вычислительный модуль (101) может представлять собой один или более процессоров, микроконтроллер, ПЛИС с интегрированным вычислительным средством, микросхему или иное средство, обеспечивающее обработку данных для осуществления операций и/или команд, выполняемых устройством (100).

[0041 ] Память (102) представляет собой одно или более средств накопления данных, например, оперативную память (RAM) и/или постоянную память (ROM). Постоянная память выбирается из такого спектра устройств, как: жесткий диск (HDD), твердотельный накопитель (SSD), флэш-память (EEPROM, NAND, SD/TF/Memory Stick -Card и т.п.), оптические накопители (CD/DVD/MD/Blue-Ray диски) и т.п. Память (102) выполняет оперативное и/или постоянное запоминание необходимых инструкций и данных для осуществления функционирования устройства (100).

[0042] Средства В/В (103) выбираются из ряда средств, которые присуще конкретному воплощению устройства (100), например, в качестве таких средств могут выступать: дисплей (в том числе сенсорный дисплей), клавиатура, манипулятор типа мышь, трекбол, тач-пад, световое перо, сенсорный планшет, проектор, динамики, световой индикатор и т.п.

[0043] Также в качестве средств В/В (103) могут выступать АЦП/ЦАП для частных примеров воплощения 1оТ устройств (100). [0044] Интерфейсы В/В (104) могут выбираться из следующей реализации, в зависимости от типа 1оТ устройства (100), например, PCI, VGA, AGP, DVI, SATA, USB (Type-C, micro-. Mini-), PS/2, RJ45, LPT, FireWire, RS232, Lightning, COM, HDMI, Display Port, Audio Jack, GPIO, ЦАП/АЦП и т.п.

[0045] Модуль безопасности (105) представляет собой элемент устройства (100), обеспечивающий безопасное хранение ключей шифрования, различных данных, например, необходимых для операций информационного обмена, прошивки чипа и т.п., выполнение криптоопераций и обработку и формирование информационных пакетов для взаимодействия 1оТ устройств (100). Детальное описание работы модуля (105) будет представлено далее.

[0046] Средство сетевого взаимодействия (106) представляет собой одно или несколько устройств, предназначенных для обеспечения приема и передачи данных посредством вычислительной сети, например, обеспечивающее передачу информации с помощью протоколов WLAN, WAN, Wi-Fi, GSM, GPRS, LTE, 5G, ZigBee, LPWAN, LoRaWan, Bluetooth, BLE, TCP/IP, ModBus, NB-IoT, Z-Wave, Sigfox, Ethernet и т.п. Передача информации с помощью устройства (106) может выполняться как по проводному, так и беспроводному информационному каналу, или в комбинации известных способов обмена данными.

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

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

[0049] На Фиг. 2 представлена общая концепция реализации модуля безопасности (105). Модуль безопасности (105) может выполняться в виде программного, программно-аппаратного или аппаратного решения, которое установлено на 1оТ устройстве (100). Модуль (105) обеспечивает хранение ключей шифрования, необходимых для формирования информационных пакетов для обмена данными в среде взаимодействия 1оТ устройств, обеспечение доверенной защищенной среды обработки данных и выполнение необходимых криптоопераций для обмена данными между устройствами ( 100).

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

[0051] Модуль безопасности (105) может представлять собой программную логику, хранящуюся в памяти (102) устройства (100) и взаимодействующую с вычислительным модулем (101) для реализации предписанных функций.

[0052] В случае программно-аппаратной или аппаратной реализации модуль (105) может выполняться в виде таких решений, как UICC, eUICC, iUICC, eSIM и т.п. Примеры аналогичных решений широко известны в уровне техники, например, в документе WO 2018007461 (GEMALTO SA, 11.01.2018).

[0053] Модуль безопасности (105) также предназначен для хранения набора ключей шифрования для осуществления доверенного и безопасного обмена данными между 1оТ устройствами (100). Под модулем безопасности (105) в настоящих материалах заявки стоит также понимать элемент безопасности (например, htps://www.iustoskgemalto.com/en/what-is-a-secure-element/).

[0054] На Фиг. 3 представлен пример общей концепции системы взаимодействия 1оТ устройств (100). Устройства (100i)-(100 _h ) взаимодействую друг с другом и 1оТ инфраструктурой посредством облачной платформы (200) с помощью различных каналов передачи данных (150).

[0055] Устройства (100i)-(100 _h ) при начале взаимодействия в 1оТ инфраструктуре осуществляют первичную регистрацию в облачной платформе (200). Регистрация выполняется с помощью, например, программного приложения, установленного на устройстве (100), с помощью заранее установленной логики в модуле безопасности (105) взаимодействия с облачной платформой (200).

[0056] Регистрация заключается в передаче на облачную платформу (200) идентифицирующей 1оТ устройство (100) информации, например, ID устройства, который может представлять собой, но не ограничиваться: UID, IMEI, SSID, MAC -адрес, Bluetooth ID, IP-адрес, PIN/PUK-код, серийный номер чипа или иного элемента устройства (100), их комбинации и т.п. На основании полученной информации устройство (100) заносится в перечень доверенных устройств. Для каждого из доверенных IoT устройств (100) с помощью облачной платформы (200) генерируется набор ключей шифрования, которые записываются в модуль безопасности (105) IoT устройства (100).

[0057] Облачная платформа (200) представляет собой сервер (облачный сервер) или несколько серверов (например, кластер), который также содержит модуль безопасности (205). Модуль безопасности облачной платформы (205) является по своему функционалу не уступает архитектуре модуля безопасности IoT устройств (105). При каждой регистрации IoT устройства (100), в модуль безопасности (105) устройства (100) записывается набор ключей шифрования, и соответствующая копия такого набора также записывается в модуль безопасности (205) облачной платформы (200) с привязкой упомянутого набора соответствующему идентификатору регистрируемого устройства (100). Ключи шифрования являются симметричными и неизвлекаемыми из модулей безопасности (105) и (205).

[0058] Набор ключей может также быть заранее сформирован для устройств (100) и содержаться в модуле безопасности (105). Такой вариант применяется, если устройства (100) на заводском уровне предназначены для работы только в доверенной среде, обеспечиваемой взаимодействием с облачной платформой (200). В этом случае платформа (200) содержит соответствующие копии наборов ключей в памяти модуля безопасности (205), которые привязаны в памяти облачной платформы (200) к соответствующим идентификаторам устройств (100).

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

[0060] На Фиг. 4 представлен пример взаимодействия IoT устройств (100i)-(1002) посредством облачной платформы (200). Как было указано выше, в каждом из модулей (105) IoT устройств содержится соответствующий набор ключей шифрования (110)-(120) для обеспечения операций по информационному обмену. Копия каждого набора ключей (210) дублируется на облачной платформе (200) в модуле безопасности (205).

[0061] При обмене данными между одним из 1оТ устройств (110i)-(110 ₂ ) с облачной платформой (200) или при взаимодействии устройств друг с другом (110i)-(1102), выполняется формирование информационного пакета, который содержит как минимум идентификатор (ID) 1оТ устройства и данные для выполнения того или иного типа взаимодействия (команда, код, алгоритм и т.п.). Например, под типом взаимодействия может пониматься: осуществление предписанных устройством операций (открытие замка, передача данных расчет температуры, активация устройства и т.п.), обеспечение передачи данных, программный код и т.п.

[0062] При формировании информационного пакета осуществляется использование ключей шифрования. Как показано на Фиг. 4, при формировании информационного пакета устройства (110i)-(110 ₂ ) (или одно из устройств) использует один из набора ключ шифрования (110)-(120). Информационный пакет может шифроваться с помощью криптографических процедур в модуле безопасности (105) 1оТ устройства (100), формирующего пакет, для последующей его передачи на одно или более получающих 1оТ устройств.

[0063] Информационный пакет может также проверяться получающим модулем безопасности (105) (или (205)) на предмет его целостности. Для этой процедуры может также применяться ЭЦП для устройств, осуществляющих обмен информационным пакетом. В качестве известных примеров контроля целостности информационных пакетов могут также выступать известные алгоритмы, например, симметричные схемы аутентификации сообщений, основанные на блочных шифрах, алгоритмы проверки кодов аутентификации (НМАС) и др.

[0064] На принимающем устройстве (100) и/или облачной платформе (200) при получении информационного пакета от устройства отправителя, упомянутый пакет обрабатывается с помощью модуля безопасности (105) (и/или (205)). При обработке информационного пакета осуществляется его дешифрование с помощью соответствующего ключа шифрования принимающего устройства (100) или устройств (100 _п ), в случае если информационный пакет на устройстве отправителе был зашифрован. И в случае успешной обработки информационного пакета на принимающей стороне осуществляется предписанная логика информационного взаимодействия.

[0065] При использовании ключа шифрования из одного или двух наборов (110)- (120), как это представлено на Фиг. 4, с учетом их симметричности и одноразовости, производится отметка в модуле безопасности (105) каждого из устройств, участвующих в информационном обмене, и модуле безопасности (205) облачной платформы (200) об использовании соответствующего ключа. Далее выполняется назначение следующего ключа из набора (110)-(120) взаимодействующих устройств и назначение соответствующей ему копии из набора (210) модуля безопасности облачной платформы (200). Специалистам в данной области техники должно быть очевидно, что порядок использования ключей может быть различным и диктоваться логикой шифрования, заложенной в модулях безопасности (105) 1оТ устройств (100), приведенный пример лишь отражает частный случай использования очередности ключей шифрования.

[0066] В частном варианте реализации, облачная платформа может не участвовать в обмене данными между устройствами (110г)-(1 Юг). В этом случае использование ключей шифрование в модулях безопасности (105) и их последующее назначение осуществляется после выполнения обмена информационными пакетами указанных устройств.

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

[0068] Набор ключей шифрования в модуле безопасности (105) 1оТ устройств (100) и модуле безопасности облачной платформы (205), может динамически обновляться в случае его исчерпания или необходимости обновления набора ключей. Данный процесс может быть частью программной логики, хранящейся на облачной платформе (200), или при участии дополнительного доверенного органа (300). При осуществлении взаимодействия через доверенный орган (300), последний может содержать установленную логику в части обновления или дополнения набора ключей шифрования на 1оТ устройствах (100), например, при подключении новых абонентов в доверенный контур информационного обмена. В таком примере, доверенный орган (300) может выступать мобильным оператором или поставщиком иного типа услуг, с возможностью предоставления набора ключей шифрования для организации взаимодействия 1оТ устройств (100). [0069] На Фиг. 5 представлен пример генерирования ключей шифрования. Набор ключей может формироваться из числовой или буквенно-числовой последовательности. Принцип генерирования ключей шифрования может быть различным. Как пример, но не ограничение, одним из принципов формирования ключей может являться способ выбора следующего набора символов, следующих после использованной последовательности. То есть, после применения набора для формирования Ключа 1, следующие части общей последовательности будут применяться для формирования следующих ключей. Количество символов для формирования ключа может быть различным и устанавливаться логикой алгоритма формирования ключей.

[0070] Заявленное техническое решение может также быть реализовано с помощью технологии блокчейн. Формируемые информационные пакеты в этом случае записываются в общий распределенный реестр, который может храниться как на 1оТ устройствах (100), так и на одной или более облачной платформе (200). Шифруемые информационные пакеты представляют собой доверенные блоки для выполнения транзакционных операций.

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

[0072] На Фиг. 6 - Фиг. 7 представлен процесс информационного взаимодействия 1оТ устройств (100) с помощью реализации на базе смарт-контрактов (СК) (400). Для данного взаимодействия целесообразно использовать блокчейн протокол, который не будет нести значимой вычислительной нагрузки на сеть, например, примером такого протокола является Hyperledger Fabric, разработанный компанией IBM™. Выполнение СК осуществляется с помощью формируемых информационных пакетов в модулях безопасности (105i)-(1052) IoT устройств (100i)-(100 ₂ ), взаимодействующих в рамках блокчейн платформы (500).

[0073] Как правило, под СК (400) понимается распределенное приложение, исполняемое на блокчейн-платформе (500). СК (400) предназначен для выполнения каких-либо заранее предопределенных действий (или единого действия) при наступлении определенных условий для его реализации, например, выполнение IoT (100) устройством предопределённой условием СК (400) одной или нескольких функций. Таким образом, безопасность СК (400) (в смысле надежности и однозначности исполнения алгоритма) во многом зависит от точности данных, поступающих в СК (400), а также от точности команд, доставляемых от СК (400) на устройства.

[0074] СК (400) подходит для интеграции устройств IoT (100i)-(100 ₂ ) друг с другом.

Например, простейший сценарий, представленный на Фиг. 7, при нажатии виртуальной кнопки (120) на экране смартфона (100i) пользователя должна загореться лампа (100 ₂ ). При повторном нажатии - потухнуть. Условие: нажатие кнопки (120), действие (команда) - изменить состояние лампы. В терминах безопасности необходимо, чтобы лампа (100 ₂ ) реагировала только на нажатие кнопки (120) на доверенном управляющем устройстве (смартфоне) (100i) и никаком другом. При нажатии кнопки (120) на экране смартфона (100i) формируется информационный пакет, подписывается в модуле безопасности (105i) смартфона (100i) с использованием ключей шифрования и отправляется на облачную платформу (200). В данном примере шифрование не применяется, так как конфиденциальность не важна в данном случае. С помощью платформы (200) выполняется подтверждение условий исполнения СК (400) для передачи пакета на управляемое IoT устройство - лампочку (100 ₂ ).

[0075] На платформе (200) информационный пакет от смартфона (100i) поступает в СК (400), и далее необходимо удостовериться, какое устройство является отправителем пакета и что пакет не изменился во время доставки, т.е., что пакет был сформирован доверенным устройством и направлен так же на доверенное устройство. Тут возможны два варианта архитектуры: 1) каждый СК (400) имеет свой модуль безопасности, который связан с модулями безопасности устройств ( 1051)-( 105 ₂ ), задействованных в СК (400); 2) платформа (200) имеет модуль безопасности (205), единый для всех СК на данной платформе (единый логически, он может представлять собой множество пространственно распределенных сущностей).

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

[0077] В этом случае СК (400) формирует информационный пакет на изменение состояния лампы (100 ₂ ), который поступает в модуль безопасности СК (400) или платформы (205) для подписи, и подписанный информационный пакет отправляется на лампу (100 ₂ ). Поступив на лампу (100 ₂ ) через сетевой модуль (например, Bluetooth или Wi-Fi) пакет поступает в модуль безопасности (105 ₂ ), где проходит проверку подписи. В случае положительной проверки модуль безопасности (105 ₂ ) формирует команду чипу лампы (100 ₂ ) на изменение состояния, т.е. на исполнение команды, полученной от устройства (100i).

[0078] Изменив состояние лампы (100 ₂ ), чип лампы (100 ₂ ) формирует пакет-отчет с актуальным состоянием лампы (100 ₂ ) (например, включено/ выключено/ нужен сервис и т.п.). Пакет-отчет проходит обратный путь через СК (400), модуль безопасности платформы (205) и поступает на вход модуля безопасности смартфона (100i) или иного управляющего устройства.

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

[0080] СК (400) отправляется пакет в модуль безопасности платформы (205), где он расшифровывается и проверяется его подпись (т.е. подпись доверенного устройства, которое инициировало его передачу), после чего СК (400) формирует информационный пакет, шифрует и подписывает его и отправляет на смартфон пользователя (100i). На смартфоне (100i) пакет расшифровывается и проверяется подпись, содержащаяся в нем, после чего актуальное состояние лампы (100 ₂ ) отражается на смартфоне (100i) (например, кнопка меняет цвет).

[0081] Возможен и иной вариант: устройства (100i)-(100 ₂ ) отправляют информационные пакеты друг другу непосредственно, а на платформу (200) отправляются копии информационных пакетов, где они обрабатываются СК (400), пишется журнал событий и фиксируются случаи нештатной работы системы.

[0082] Взаимодействие СК (400) в системе может осуществляться посредством блокчейн платформы (500) (блокчейн протокола).

[0083] На Фиг. 8 представлен пример осуществления решения на примере каршеринга. Доступ к услуге аренде автомобиля (620) осуществляется с помощью обмена данными с доверенным устройством пользователя (610). Автомобиль (620) содержит ряд 1оТ устройств, например, контроллер двигателя (621), контроллер центрального замка (622), контроллер управления электроникой (623) и единый вычислительный модуль (625). Модуль (625) может выступать в роде общего узла, обеспечивающего информационный обмен с устройствами автомобиля (620).

[0084] Модуль (625) может содержать модуль безопасности, который обеспечивает обмен информационными пакетами со смартфоном пользователя (610), который связан с автомобилем (610) с помощью облачной платформы (200). При регистрации устройства пользователя (610) с помощью платформы (200) или дополнительно через доверенный орган (300), в системе предоставления услуг каршеринга, в модуль безопасности устройства (610) записывается соответствующий набор ключей шифрования для применения соответствующей услуги по аренде автомобиля (620).

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

[0086] По аналогии с примером на Фиг. 7 для данного примера также может применяться СК (400), который будет содержать соответствующую программную логику. Организация каршеринга может осуществляться с помощью блокчейн платформы (500), которая будет осуществлять техническое взаимодействие пользователя с арендуемым автомобилем (620) посредством СК (400). СК (400) в этом случае является программным воплощением юридического договора между пользователем и владельцем (арендодателем) автомобиля. В целях безопасности СК (400) делает проверку информационных пакетов на модуле безопасности по аналогии в предыдущим примером.

[0087] В этом случае, устройство пользователя (610) может в модуле безопасности содержать криптокошелек, который будет использоваться для формирования пакетов, неооходимых для аренды автомобиля 620).

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