Результат интеллектуальной деятельности: ВЫПОЛНЕНИЕ ПРОТОКОЛА БЕЗОПАСНОСТИ В СЕТИ

ОБЛАСТЬ ИЗОБРЕТЕНИЯ

Настоящее изобретение к системе, блоку управления сегментного контроллера и к способу для выполнения протокола безопасности в сети.

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

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

Существующие в настоящий момент радиочастотные (RF) беспроводные решения предпочтительно используют топологию ячеистой сети, например, как показано на фиг.1. Беспроводная сеть содержит центральный контроллер или сегментный контроллер 60 и множество узлов 10 (N), соединяющихся друг с другом по беспроводным коммуникационным трактам 40 в ячеистую топологию. Таким образом, узлы 10 и центральный контролер 60 могут содержать приемопередатчик для передачи или приема пакетов данных по беспроводным коммуникационным трактам 40, например посредством RF передачи. На сервере размещается сервисный центр 80 и служит для управления системой. Этот объект обычно связан с одним или несколькими центральными контроллерами 60 соответствующей сети как наладочный инструмент, отвечающий за управление или конфигурирование этой сети через канал 70 связи третьего участника, такой как Интернет или сети мобильной связи, или через проводные или беспроводные системы передачи данных. В случае осветительной системы или любой другой большой беспроводной сети сеть может также быть разделена на сегменты, так что узел 10 принадлежит исключительно одному сегменту с одним сегментным контроллером 60. Поэтому термины «сегментный контролер» и «центральный контроллер» должны пониматься как взаимозаменяемые на протяжении всего этого описания.

В общем случае, любой узел 10 ячеистой сети может связываться с сервисным центром 80 через сегментный контроллер 60. Однако в некоторых ситуациях стандарты высокой безопасности должны быть полностью соблюдены, чтобы обеспечить основные безопасные услуги. В качестве примера приведем защиту от атаки с подставкой («злоумышленник-по-середине»), т.е. предохранение конфиденциальной информации, предоставляемой неавторизованным узлам 10 или предотвращение манипулирования информацией, предоставляемой узлам 10. Например, управление наружным освещением включает в себя дистанционное управление узлами осветительных приборов, требующее линии связи между сервисным центром 80 и самими узлами 10 с помощью управляющего устройства, такого как сегментный контроллер 60. В противоположность сервисному центру 80 и узлам 10 сегментный контроллер 60, который находится посередине, часто не полностью надежен, так как им может управлять или манипулировать третья сторона, такая как установщики или потребители. Таким образом, сегментный контроллер 60 может действовать как «злоумышленник-по-середине» и манипулировать некоторыми сообщениями. Это делает выполнение протоколов безопасности затруднительным. Например, ключевой материал не может быть предоставлен сегментному контроллеру 60, поскольку он может быть неправильно использован. Поэтому требуется найти средство, которое позволит обновить и/или активировать функции программного обеспечения сетевых узлов 10 или им подобных, не опасаясь злоумышленника, способного внести вредоносные программы в узлы 10. Для этого важно гарантировать, что протокол для выполнения таких действий правильно выполнен сегментным контроллером 60.

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

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

Спецификации ITU-X700 («Management Framework for Open Systems Interconnection (OSI) for CCITT Applications»), X701 ((«Information technology - Open Systems Interconnection - System Management Overview») и Х800 («Security Architecture for Open Systems Interconnection for CCITT Applications») раскрывают работу и архитектуру OSI, чтобы разрешить взаимодействие неоднородных компьютерных систем, так чтобы можно было достигнуть полезной связи между прикладными процессами.

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

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

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

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

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

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

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

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

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

Предпочтительно, чтобы сервисный центр и узел сети совместно использовали, по меньшей мере, один общий ключ безопасности, ключ настройки, функцию шифрования, такую как хэш-функция, номер итерации хэш-функции и текущую величину хеширования. Сервисный центр может знать ключ безопасности индивидуальный для каждого сетевого узла или ключ безопасности общий для всех сетевых узлов или для одной или нескольких групп сетевых узлов. Альтернативно или дополнительно сервисный центр сохраняет цепочку хеширования или функцию хеширования для каждой сети или сегмента сети, и стартовое значение a₀ для них. Затем, узел может быть инициализирован с помощью точки привязки соответствующей цепочки хеширования или функции. Функция хеширования может быть заменена другой односторонней функцией или цепочкой, в которой итеративное применение функции дает линии цепочек или элементы, выведенные из начальной строки или начального значения, например a_i = HASH(a_i-1). Желательно, чтобы протокол и/или ответное сообщение, по меньшей мере, частично основывались на функции хеширования, такой как алгоритм SHA-2 хеширования. С помощью этих средств узел, который инициализирован точкой привязки цепочки хеширования и который отслеживает текущий элемент a_i цепочки хеширования, может подтверждать принятое сообщение с помощью проверки, удовлетворяет ли элемент a_i хеширования, включенный в принятое сообщение, условию a_i= HASH(a_i-1). Отсюда, использование цепочки хеширования или односторонней функции позволяет выполнить аутентификацию без шифрования открытого ключа.

В некоторых вариантах осуществления протокол может включать в себя представление информации одному или нескольким узлам сети. Затем, информация, предпочтительно защищается на основании секретного ключа, выведенного из мастер-секрета и информационного идентификационного номера. Информация может быть передана от сервисного центра через сегментный контроллер узлу. Таким образом, чтобы обезопасить информацию секретный ключ может быть основан на мастер-секрете, т.е. строке или значении, известных только узлу и сервисному центру, но не сегментному контроллеру. Например, мастер-секрет может относиться к ключу безопасности узла или к ключу настройки узла. Более того, секретный ключ может дополнительно включать в себя информационный идентификационный номер, например случайный номер, контрольное слово (nonce) или «соль» (строку случайных данных), посланный сервисным центром. Таким образом, в примере, в котором информация относится к обновлению программного обеспечения, идентификационный номер информации может соответствовать номеру обновления программного обеспечения или номеру программного обеспечения. Посредством этого конфиденциальная информация может быть защищена и элементы сквозного безопасного квитирования между сервисным центром и узлом могут быть имитированы.

В одном варианте осуществления сервисный центр может предоставить узлу случайный номер, «соль» или контрольное слово, конкретные для протокола. Они могут потребоваться на узле в качестве входных данных в односторонней функции, такой как функция хеширования. Желательно, чтобы «соль» или одноразовый код, составляли, по меньшей мере, 16 байт длиной. Случайный номер, «соль» или контрольное слово могут относиться к идентификационному номеру информации, описанному выше.

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

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

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

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

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

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

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

На чертежах

Фиг.1 иллюстрирует пример беспроводной ячеистой сети.

Фиг.2 показывает блок-схему, иллюстрирующую вариант осуществления настоящего изобретения.

Фиг.3 показывает схематический вид процесса на фиг.2.

Фиг.4 показывает диаграмму для процесса в соответствии вариантом осуществления настоящего изобретения.

Фиг.5 иллюстрирует принцип HASH-цепочки.

Фиг.6 показывает блок-схему, иллюстрирующую другой вариант осуществления настоящего изобретения.

Фиг.7 показывает схематический вид процесса на фиг.6.

Фиг.8 показывает блок-схему, иллюстрирующую вариант осуществления настоящего изобретения.

ПОДРОБНОЕ ОПИСАНИЕ

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

В системе телеуправления для управления освещением количество узлов 10 осветительных устройств чересчур большое. Поэтому размер сети очень большой, особенно в сравнении с обычными беспроводными ячеистыми сетями, которые обычно содержат менее 200 узлов. К тому же, узлы 10 в общем случае имеют ограниченные возможности обработки из-за соображений стоимости, так что ресурсы обработки и памяти в узлах 10 осветительных устройств будут ограничены. Таким образом, меры безопасности и протоколы связи для передачи пакетов данных между единичными узлами 10 должны подразумевать ограниченные ресурсы для эффективной работы и безопасной передачи пакетных данных. Окончательно по сравнению с другими, так называемыми специальными ячеистыми сетями, система телеуправления для сети управления наружным освещением является стационарной, т.е. узлы 10 осветительных устройств не движутся. Так как узлы 10 осветительных устройств (например, фонарные столбы) стационарны, положения узлов не меняются со временем. Таким образом, физическое положение узлов 10, например, GPS-координаты или другие данные положения могут быть известны в системе, обеспечивая географическую маршрутизацию или маршрутизацию на основании положений, используя запрограммированные или заранее определенные положения.

В дальнейшем варианты осуществления настоящего изобретения будут описаны с использованием примера протокола для обновлений программного обеспечения. Однако настоящее изобретение не ограничивается ими, а протокол, который должен быть выполнен сегментным контроллером 60, может также относиться к активации элементов узла и т.п.

На фиг.2 показан первый вариант осуществления для обеспечения безопасного выполнения протокола сегментным контроллером 60. На фиг.3 схематически изображен трафик данных в примере, показанном на фиг.2, между сервисным центром 80, сегментным контроллером 60 и сетевым узлом 10. Стрелки на фиг.3 указывают направление связи, тогда как можно считать, что время идет в направлении сверху вниз.

На первом этапе S200 сервисный центр 80 предоставляет информацию для выполнения протокола сегментному контролеру 60. Принимая эту информацию, сегментный контроллер 60 начинает выполнять соответствующий протокол. Таким образом, сегментный контроллер 60 передает первое сообщение одному или нескольким узлам 10 (S210), например, для оповещения о начале протокола. Каждый узел 10 подтверждает сообщение, принятое от сегментного контроллера 60, ответным сообщением, включающим в себя индекс или идентификатор содержания принятого сообщения, и идентификатор или ключ, указывающий идентификационные данные узла (S220). На этапе S230 сегментный контроллер 60 собирает ответные сообщения от узлов 10 и направляет их в сжатой форме, например, собранные в пакетное сообщение, сервисному центру 80. Посредством этого сервисный центр 80 может подтверждать, что сегментный контроллер 60 выполнил первый этап протокола корректно и успешно. Это может включать в себя подтверждение того, что первое сообщение включало в себя правильное содержание, что первое сообщение было успешно принято узлами 10 или что сегментный контроллер 60 передал первое сообщение правильным узлам 10, т.е. целевым узлам протокола. После определения того, что, по меньшей мере, одно подтверждение было успешным, сервисный центр 80 передает информацию для последующих этапов протокола сегментному контроллеру 60 (S240). Таким образом, на этапе S250 сегментный контроллер 60 может выполнять следующий этап протокола, например передачу второго сообщения узлам 10. Предпочтительно, чтобы второе сообщение содержало образ программного обеспечения обновления программного обеспечения, который сохраняется в узлах 10 на этапе S260. Дополнительно определенное средство идентификации может быть включено в первое сообщение и второе сообщение, так что узлы 10 могут подтверждать содержание принятого второго сообщения перед его сохранением (S260). Затем на этапе S270 узлы 10 передают сегментному контроллеру 60 второе ответное сообщение, которое зависит от принятого содержания и идентификационных данных соответствующего узла, как первые ответные сообщения. На этапе S280 сегментный контроллер 60 объединяет вторые ответные сообщения в пакет сообщений и передает их сервисному центру 80. После успешного подтверждения сервисным центром 80 сервисный центр 80 предоставляет ключ перезагрузки сегментному контроллеру 60 для активации нового программного обеспечения (S290). При приеме и успешном подтверждении ключа перезагрузки узлы 10 перезагружаются на этапе S2100. При желании сегментный контроллер 60 может принимать подтверждающие сообщения от узлов 10 после перезагрузки и направлять их в последующем пакете сообщений сервисному центру 80. Для повышения безопасности также могут быть заданы определенные временные интервалы для приема ожидаемых сообщений. Например, максимальный временной интервал может быть задан в сервисном центре 80 для инициации протокола на этапе S200 и предоставления ключа перезагрузки на этапе S290. Так же будет понятно, что таким путем управляют более чем двумя этапами протокола, т.е. что существуют дальнейшие итерации, такие как этапы S200-S230 или S240-S280.

Поэтому в соответствии с вариантом осуществления, показанном на фиг.2 и 3, узлы 10 посылают отчет сервисному центру 80 через сегментный контроллер 60, какие узлы 10 приняли сообщение от сегментного контроллера 60 и что они приняли. Только после того как сервисный центр 80 подтвердил правильное выполнение протокола, он предоставляет сегментному контроллеру 60 информацию для последующих этапов протокола. Поскольку сегментный контроллер 60 собирает вместе ответные сообщения единичных узлов 10 и направляет их в пакетном сообщении, трафик данных между сегментным контроллером 60 и сервисным центром 80 может быть понижен. Таким образом, в зависимости от ответных сообщений узлов 10 об идентификационных данных узла и о содержании сообщения, принятого от сегментного контроллера 60, сегментный контроллер 60 будет принимать только достоверные ответные сообщения при корректном выполнении протокола. Поэтому хотя протокол выполняется не полностью доверенным объектом, т.е. сегментным контроллером 60, корректное выполнение протокола может быть постепенно выполнено без необходимости высокой загрузки данных при соединении с сервисным центром 80.

На фиг.4 показан более подробный пример первого варианта осуществления настоящего изобретения. В этом примере сервисный центр 80 знает ключ K_com настройки, общий для всех узлов сети, идентификационные данные узлов или специальные узловые ключи K_node сетевых узлов 10, HASH-функцию, такую как SHA256, которая используется узлами в сети, начальную величину HASH-функции a₀ и, по меньшей мере, один номер 1 итерации HASH-функции и последний используемый элемент a_L HASH-цепочки. Сетевые узлы 10, наоборот, знают ключ K_com настройки, HASH-функцию SHA256 сети, последний элемент или точку привязки a_N HASH-цепочки и последний элемент a_L HASH-цепочки, который был открыт.

На фиг.5 показан принцип HASH-цепочки. HASH-цепочка включает в себя N элементов a_i, которые генерируются с использованием односторонней HASH-функции с a_L= HASH(a_L-1). Таким образом, каждый элемент a_i HASH-цепочки может быть генерирован только на основании предыдущего элемента a_i-1 HASH-цепочки. Поскольку только сервисный центр 80 знает начальный элемент a₀ HASH-цепочки, то только сервисный центр 80 может генерировать следующий элемент a_i+1 HASH-цепочки. Для аутентификации информации сервисный центр 80 использует элемент a_i HASH-цепочки в противоположном направлении, как показано на фиг.5. Например, сервисный центр 80 включает в себя текущий элемент a_L-1 HASH-цепочки в сообщении узлу 10. Затем узел 10, который знает только последний используемый элемент a_L HASH-цепочки, может подтвердить сообщение путем проверки верно ли a_L= HASH(a_L-1). С помощью этого средства информация может быть аутентифицирована, не нуждаясь в шифровании c открытым ключом.

Как показано на фиг.4, сервисный центр 80 начинает выполнение протокола обновления программного обеспечения, выполняемого сегментным контроллером 60, с помощью передачи первого сообщения М1 сегментному контроллеру 60. Первое сообщение М1 включает в себя предварительное уведомление, предварительное уведомление является значением функции, такой как функция сообщения с аутентификацией кода, зависящей от текущего элемента a_L-1 HASH-цепочки и от отпечатка обновления программного обеспечения. Здесь отпечаток может также относиться к значению функции или строки. Например, предварительное уведомление может быть получено с использованием следующего выражения:

М1: preack=HMAC(SHA256(E_k(SW))||salt, a_L-1),

в котором две вертикальные линии указывают соединение элементов, НМАС относится к ключевому HASH-сообщению с аутентификацией кода, SHA256 – это HASH-функция SHA-2 с 256 битовым отпечатком, Е_к относится к функции шифрования на основании ключа К шифрования, SW обозначает обновление программного обеспечения, salt - это, по меньшей мере, 16 байтовое контрольное слово, специальное для обновления программного обеспечения и a_L-1 - это текущий элемент HASH-цепочки. Ключ К шифрования может быть выведен из ключа K_com настройки и «соли», например как К=НМАС(salt, K_com). Сегментный контроллер 60 направляет сообщение М1 узлу 10, который хранит предварительное уведомление. Предварительное уведомление используется для выполнения подтверждения обновления программного обеспечения и создания содержания сообщения на следующем этапе. Так как предварительное уведомление имеет только маленькое количество информации, память на узлах может быть сохранена (сэкономлена). Затем узел 10 создает ответное сообщение М2 на основании содержания принятого сообщения М1 и специального ключа K_node узла. Например, ответное сообщение М2 узла 10 может включать в себя результат следующего выражения:

М2:SHA256(M1││K_node)

В общем случае код аутентификации сообщения выводится из М1 и K_node. Если сегментный контроллер 60 не принимает ответное сообщение М2 от адресуемого узла 10, то сегментный контроллер 60 может запросить это узел 10 послать ответное сообщение М2. Возможно определенный временной интервал задан на сегментном контроллере 60 для определения максимального временного интервала для приема ответных сообщений. После того как сегментный контроллер 60 принял ответное сообщение M2_{node_1},... M2_{node_N} от соответствующих узлов 10, он передает сообщение М3 сервисному центру 80 на основании принятых ответных сообщений M2_{node_1},... M2_{node_N}. Например, сегментный контроллер 60 собирает ответные сообщения M2_{node_1},... M2_{node_N}, например, используя HASH-функцию

М3:SHA256 (M2_{node_1}││...││M2_{node_N})

Если сервисный центр 80 не принял сообщение М3 в пределах заранее определенного времени, то сервисный центр 80 может запросить сообщение М3 от сегментного контроллера 60. При приеме сообщения М3 сервисный центр 80 может подтвердить, используя сообщение М3, что были адресованы правильные целевые узлы 10 и что все целевые узлы успешно приняли первое сообщение М1. Затем сервисный центр 80 передает сообщение М4 сегментному контроллеру 60, включающее в себя зашифрованное обновление Е_к(SW) программного обеспечения, «соль» и текущий элемент a_L-1 HASH-цепочки. Сегментный контроллер 60 вычисляет отпечаток зашифрованного обновления программного обеспечения, например SHA256(Е_к(SW)), и передает сообщение М5 узлу 10, включающему в себя отпечаток зашифрованного обновления программного обеспечения, «соль» и текущий элемент a_L-1 HASH-цепочки. Затем узел 10 определяет, идентично ли значение предварительного уведомления, принятого в сообщении М1, результату заранее определенной функции при вводе параметров, принятых с сообщением М5. Отсюда, в примере, показанном на Фиг.4, узел 10 проверяет, так ли:

preack= =HMAC(SHA256(E_k(SW))||salt, a_L-1))

Дополнительно узел 10 определяет, мог бы последний используемый элемент a_L HASH-цепочки быть выведен с помощью применения HASH-функции к элементу a_L-1 HASH-цепочки, включенному в сообщение М5, например SHA256(a_L-1)= = a_L. Если оба этих процесса подтверждения успешны, то узел 10 принимает отпечаток зашифрованного обновления программного обеспечения и «соль», которые были приняты с сообщением М5, и переключается в режим обновления программного обеспечения. Более того, узел 10 может теперь вычислить ключ К шифрования на основании «соли» и ключа K_com настройки. Между тем или после этого сегментный контроллер 60 передает дополнительное сообщение М6 узлу 10, включающее в себя зашифрованное обновление программного обеспечения. Если узел 10 может подтвердить, что предыдущий принятый отпечаток идентичен вычисленному отпечатку зашифрованного обновления программного обеспечения, принятого с сообщением М6, то он примет обновление программного обеспечения и сохранит такое же. Однако вместо передачи сообщения М5 и М6 сегментный контроллер 60 может также просто направлять сообщение М4 узлу 10. В любом случае узел 10 возвратит второе ответное сообщение М7 сегментному контроллеру 60, включающее в себя отпечаток принятого зашифрованного обновления программного обеспечения, «соль», текущий элемент a_L-1 HASH-цепочки и специальный ключ K_node. Например, сообщение М7 может включать в себя:

М7: SHA256(E_k(SW))||salt, a_L-1||K_node))

Сегментный контроллер 60 собирает ответные сообщения M7_{node_1} ... M7_{node_N} от всех узлов 10 и соединяет их в пакетное сообщение М8, которое передается сервисному центру 80. После приема и подтверждения того, что сообщение М8 правильно, т.е. что сегментный контроллер 60 выполнил этапы протокола корректно, сервисный центр 80 предоставляет сегментному контроллеру 60 сообщение М9, включающее в себя следующий элемент a_L-2 HASH-цепочки. Он используется сегментным контроллером 60 как ключ перезагрузки для перезагрузки целевых узлов 10 и активации нового программного обеспечения. Таким образом, на последнем этапе сегментный контроллер 60 направляет сообщение М9, включающее в себя ключ перезагрузки или элемент a_L-2 HASH-цепочки, сетевым узлам 10. Если верифицировано, что элемент ключа a_L-2 HASH-цепочки достоверен, то сетевые узлы 10 могут быть перезагружены в синхронном режиме и новое программное обеспечение сетевых узлов 10 активируется. Возможно, что подтверждение успешного обновления программного обеспечения и перезагрузки поступает от узлов через сегментный контроллер 60 к сервисному центру. Следует заметить, что вместо HASH-функции SHA256 может быть использована любая другая криптографическая функция, чтобы генерировать код аутентификации сообщения.

Таким образом, отпечаток обновления программного обеспечения может быть распределен по заранее определенным целевым узлам 10 или по всем узлам 10 сети, и узлы 10 могут быть перезагружены в синхронном режиме. Этот подход использует два звена HASH-цепочки, чтобы обозначить отпечаток программного обеспечения и сообщение о перезагрузке соответственно. Более того, обновление программного обеспечения самостоятельно защищается секретным ключом К шифрования, специальным для обновления программного обеспечения, так что сегментный контроллер 60 не имеет доступа к обновлению программного обеспечения. Поэтому в соответствии с первым вариантом осуществления настоящего изобретения безопасный и экономичный протокол для обновлений программного обеспечения может быть предоставлен без необходимости в шифровании с открытым ключом.

Однако этот вариант осуществления имеет несколько ограничений. Например, он требует, чтобы сервисный центр 80 находился в режиме он-лайн, так как обновление программного обеспечения может быть закончено только после предоставления ключа перезагрузки в сообщении М8. Более того, протоколом можно манипулировать, чтобы сохранить другое программное обеспечение на сетевых узлах 10, при этом без возможности активировать это программное обеспечение. Эта атака загрузки фальшивого программного обеспечения может встречаться в следующих ситуациях: после приема сообщения М4, сегментный контроллер 60, подвергающийся манипуляции, может посылать множество фальшивых сообщений М1, c тем чтобы узлы 10 удалили действительное сообщение М1, предоставленное сервисным центром 80. Затем сегментный контроллер 60 может генерировать фальшивое сообщение М5 на основании фальшивого обновления программного обеспечения. Если у сегментного контроллера есть такой же доступ к ключу K_com настройки, то сегментный контроллер 60 сможет сгенерировать достоверный ключ К шифрования программного обеспечения, используя «соль», принятую с сообщением М5 от сервисного центра 80 и поставить другое программное обеспечение на узел 10. В общем случае, однако, у сегментного контроллера 60 не будет доступа к ключу K_com настройки и поэтому он не сможет создавать достоверный ключ К шифрования. В этом случае сегментный контроллер 60 сможет только заполнить память узла 10 бесполезной информацией. При этом, в любом из этих случаев сегментный контроллер 60 не сможет активировать фальшивое программное обеспечение, потому что он нуждается в элементе a_L-2 HASH-цепочки в качестве ключа перезагрузки.

На фиг.6 проиллюстрирован второй вариант осуществления настоящего изобретения, который может преодолеть, по меньшей мере, некоторые из этих недостатков первого варианта осуществления. Фиг.7 - это схематический вид варианта осуществления, описанного в соответствии с фиг.6, указывающий направление передачи данных между разными объектами. Главное отличие этого варианта осуществления от первого варианта осуществления заключается в том, что сегментный контроллер 60 снабжается информацией для выполнения протокола первым сообщением от сервисного центра 80, когда информация для разных этапов протокола шифруется на основании разных ключей. Посредством этого трафик данных между сервисным центром 80 и сегментным контроллером 60 может быть минимизирован, так что сервисный центр 80 должен будет только запускать протокол обновления программного обеспечения и дополнительно принимать подтверждение, как только протокол завершается. Таким образом, это дает возможность для работы офлайн сервисного центра 80, так как сервисный центр 80 должен только предоставить первое сообщение М0 и затем может находиться в режиме офлайн все остальное время.

На первом этапе S500 на фиг.6 сервисный центр 80 обеспечивает сегментный контроллер 60 всей информацией, требующейся для выполнения протокола обновления программного обеспечения. К тому же, только первая часть этой информации не закодирована и может, таким образом, использоваться сегментным контроллером 60. Сегментный контроллер 60 направляет эту часть информации соответствующим целевым узлам 10 (S510). Каждый узел 10 возвращает ответное сообщение на основании содержания принятого сообщения и идентификационных данных своего узла (S520). Используя ответное сообщение от узлов 10, сегментный контроллер 60 теперь способен генерировать первый ключ (S530) шифрования, чтобы декодировать последующую часть информации протокола. Поскольку ответное сообщение зависит от идентификационных данных узла и от содержания сообщения, переданного узлу, и поскольку сегментный контроллер 60 способен декодировать только последующую часть информации протокола с достоверным ответным сообщением, то сегментный контроллер 60 инициирован, чтобы предоставить правильное содержание правильным узлам 10, чтобы иметь возможность приступить к протоколу. Используя генерированный ключ шифрования, сегментный контроллер 60 может декодировать вторую часть информации протокола и направить ее сетевым узлам на этапе S540. Возможно, что сетевые узлы 10 подтвердят вторую часть информации протокола перед ее сохранением (S550). На этапе S560 узлы 10 передают вторые ответные сообщения сегментному контроллеру 60. На основании вторых ответных сообщений сегментный контроллер 60 может генерировать второй ключ (S570) шифрования и декодировать дальнейшую часть информации протокола. Эти этапы могут быть повторены до тех пор, пока сегментный контроллер 60 сможет декодировать ключ перезагрузки, включенный в состав информации протокола, принятой от сервисного центра 80, и направлять ключ перезагрузки узлам (S580). Если ключ перезагрузки определяется как достоверный, узлы 10 перезагружаются и новое программное обеспечение активируется (S590). Предпочтительно, чтобы протокол завершался передачей подтверждающего сообщения сервисному центру 80 на этапе S5100. Это подтверждающее сообщение может относиться к уведомлениям узлов 10, собранных сегментным контроллерам 60, которое может соответственно включать в себя идентификационные данные узла или специальный ключ узла и отпечаток активированного программного обеспечения. Посредством этого подтверждающего сообщения сервисный центр 80 может подтвердить, все ли узлы 10 были успешно обновлены и было ли использовано правильное программное обеспечение. Отсюда также в этом варианте осуществления выполнение правильного протокола сегментным контроллером 60 запускается этап за этапом и активация нового программного обеспечения узла возможна только после успешного подтверждения отдельных этапов протокола.

На фиг.8 проиллюстрирован более подробно пример для второго варианта осуществления в соответствии с настоящим изобретением. Подобно примеру, проиллюстрированному на фиг.4, сервисный центр 80 знает ключ K_com настройки сети, конкретные ключи K_node узлов или идентификационные данные узлов, HASH-функцию сети, например SHA256, начальный элемент a₀ HASH-цепочки и последний элемент a_L HASH-цепочки или номер итерации HASH-функции 1. Узел 10 знает о своем конкретном ключе K_node узла или идентификационных данных своего узла, ключе K_com настройки, HASH-функции SHA256, последнем элементе или точке привязки HASH-цепочки a_N и последнем используемом элементе a_L HASH-цепочки. Для запуска протокола сервисный центр 80 передает первое сообщение М0, включающее в себя предварительное уведомление и, по меньшей мере, два дополнительных информационных блока, которые зашифрованы на основании разных ключей K_i шифрования_. В показанном примере показаны только две дополнительные части информации, зашифрованные ключом К1 и К2 шифрования, соответственно. Таким образом, сообщение М0 может содержать:

М0: preack; E_K1(SHA256(E_K(SW)), salt, a_L-1, E_K(SW)); E_K2(a_L-2)

С сообщением М0 сегментный контроллер 60 мог бы выполнять протокол, например, для обновления программного обеспечения на узлах 10 без дальнейших помех от сервера. Однако, так как только предварительное уведомление не кодируется, сегментный контроллер 60 может только использовать предварительное уведомление в начале. Таким образом, сегментный контроллер 60 передает сообщение М1, включающее в себя предварительное уведомление для узла 10. Значение предварительного уведомления было генерировано сервисным центром 80 на основании «соли» или случайного номера, конкретного для обновления программного обеспечения, текущего элемента a_L-1 HASH-цепочки и отпечатка зашифрованного обновления программного обеспечения. Например, значение предварительного уведомления может быть выведено, как описано выше для первого варианта осуществления. После приема предварительного уведомления с сообщением М1 узлы 10 сохраняют предварительное уведомление и возвращают первое ответное сообщение М2, которое могло бы зависеть от отпечатка содержания сообщения М1 и соответствующего конкретного ключа K_node узла. Например, сообщение М2 может включать в себя значение функции SHA256(М1││K_node). Как описано выше, заранее определенные временные интервалы могут быть заданы так же и в этом варианте осуществления для нахождения максимального временного интервала между двумя сообщениями или этапами протокола. Например, если сегментный контроллер 60 не принимает ответные сообщения M2_{node_1}, … M2_{node_N} от всех узлов 10 в пределах заранее определенного временного интервала, то сегментный контроллер 60 может затребовать ответное сообщение М2 от соответствующего узла 10. Когда все ответные сообщения M2_{node_1}, … M2_{node_N} приняты, сегментный контроллер 60 может определять первый ключ К1 шифрования, например используя функцию выработки ключа как следующую функцию:

К1 = SHA256(M2_{node_1},││ … ││M2_{node_N}),

Используя этот ключ К1 шифрования, сегментный контроллер 60 может дешифровать вторую часть информации протокола, в вышеописанном примере относящуюся к отпечатку зашифрованного обновления SHA256 (EK(SW)) программного обеспечения, «соли», текущему элементу a_L-1 HASH-цепочки и обновлению EK(SW) программного обеспечения, зашифрованному ключом К шифрования. Ключ К шифрования может быть основан на ключе K_com настройки и «соли», как описывалось выше. Затем сегментный контроллер 60 направляет дешифрованный отпечаток зашифрованного обновления SHA256 (EK(SW)) программного обеспечения, «соль» и текущий элемент a_L-1 HASH-цепочки в сообщении М3 узлу 10. После принятого сообщения М3 от сегментного контроллера 60 узел 10 определяет, идентично ли значение предварительного уведомления, принятое с сообщением М1, заранее заданной функции отпечатка зашифрованного обновления программного обеспечения, «соли» и текущему элементу a_L-1 HASH-цепочки и достоверен ли элемент HASH-цепочки, включенный в сообщение М3. В этом случае узел 10 принимает «соль» и отпечаток зашифрованного обновления программного обеспечения, включенные в сообщение М3 как отпечаток программного обеспечения, и переключается в режим обновления программного обеспечения. На основании «соли» и ключа K_com настройки узел 10 может вычислить ключ К шифрования. Затем, сегментный контроллер 60 передает дополнительное сообщение М4, включающее в себя обновление программного обеспечения, зашифрованное ключом К шифрования узлу 10. Если результат данной функции отпечатка принятого зашифрованного обновления программного обеспечения идентичен ранее определенному отпечатку, например если отпечаток = SHA256(E_KSW)_received)), то узел 10 допускает обновление программного обеспечения. Вместо передачи двух сообщений М3 и М4 узлу 10 сегментный контроллер 60 может также передавать только одно сообщение, включающее в себя отпечаток зашифрованного обновления программного обеспечения, «соль», текущий элемент a_L-1 HASH-цепочки и зашифрованное обновление программного обеспечения. В любом случае узел 10 передает ответное сообщение М5 сегментному контроллеру 60, включая значение вычисленного на основании отпечатка зашифрованного обновления программного обеспечения, «соли», текущего элемента a_L-1 HASH-цепочки и конкретного ключа K_node узла. Например, значение может быть вычислено на основании следующего выражения:

SHA256 (E_K(SW))││salt││a_L-1 ││K_node)

В случае когда сегментный контроллер 60 не принимает ответное сообщение М5 от соответствующего узла 10 в пределах заранее заданного временного интервала, сегментный контроллер 60 может запросить это ответное сообщение М5. Используя принятые ответные сообщения M5_{node_1}, … M5_{node_N}, сегментный контроллер 60 может вычислить второй ключ К2 шифрования и дешифровать третью часть информации протокола, которая была включена в сообщение М0 от сервисного центра 80. Например, ключ К2 шифрования может быть вычислен на основании следующего выражения:

К2 = SHA256 (M5_{node_1},││ … ││M5_{node_N})

По возможности второй ключ К2 шифрования может также быть использован сегментным контроллером 60 как подтверждающее сообщение, чтобы быть переданным сервисному центру 80. На последнем этапе сегментный контроллер 60 передает сообщение М7 узлу 10, включающее в себя следующий элемент a_L-2 HASH-цепочки, который используется как ключ перезагрузки и был включен в состав третьей части информации протокола. Узел 10 подтверждает ключ перезагрузки путем определения, верен ли элемент HASH-цепочки, например, путем определения, верно ли

SHA256 (a_L-2)= = a_L-1

Если это такой случай, то узел 10 перезагружается и новое программное обеспечение активируется.

Сущность этого варианта осуществления основывается на том факте, что информация, которую сегментный контроллер 60 должен распределить сетевым узлам 10 в сообщениях М3, М4 и М7, зашифровывается разными ключами К1 и К2. Эти ключи шифрования зависят от уведомлений от соответствующих сетевых узлов 10. Таким образом, сегментный контроллер 60 может только дешифровать и таким образом использовать следующую информацию протокола, если все сетевые узлы 10 отправляют ожидаемые уведомления или ответные сообщения. Таким путем запускается корректная работа и обеспечивается правильное поведение сегментного контролера 60: если сегментный контроллер 60 не следует протоколу, то он не может использовать информацию протокола для следующих этапов протокола, потому что информация зашифрована. Если сегментный контроллер 60 ведет себя правильно, он может дешифровать информацию и следовать ожидаемой работе протокола. Более того, связь с сервисным центром 80 может быть ослаблена, так как связь занимает в основном место между частично доверенным сегментным контроллером 60 и узлами 10 без уменьшения безопасности системы. Это дает возможность работы офлайн сервисного центра 80.

Поэтому в соответствии с настоящим изобретением услуги от сервера могут быть обеспечены запущенной корректной работой промежуточного объекта, которому не полностью доверяют. Более того, трафик данных к серверу и операции на сервере могут быть минимизированы, таким образом упрощая сетевое управление. Поскольку линия связи между сегментным контроллером 60 сети и сервисным центром 80 на сервере часто основывается на инфраструктурах третьей части, такой как GPRS, это также уменьшает затраты на обслуживание сети. Варианты осуществления настоящего изобретения являются, в частности, подходящими для больших беспроводных сетей, таких как наружные осветительные системы для выполнения услуг от сервисного центра 80, например, для обновления шаблонов уменьшения яркости узлов 10 осветительных устройств в уличной осветительной системе или для передачи другой конфигурации или информации о настройки. Здесь важно гарантировать, что только узлы 10 сети принимают информацию. Однако варианты осуществления настоящего изобретения также применимы к любому другому протоколу, приложению, системе или сети, показывающим связь и достоверный шаблон, как описано выше, например упрощенный ZigBee-IP.