Выполнение протокола безопасности в сети
Иллюстрации
Показать всеИзобретение относится к области дистанционного управления осветительными устройствами. Технический результат – безопасное управление дистанционным осветительным устройством. Система освещения для обеспечения безопасности выполнения протокола в сети, содержащая: осветительное устройство; сервисный центр для предоставления информации протокола для управления осветительным устройством, причем упомянутая информация протокола содержит первую часть и вторую часть; и сегментный контроллер для выполнения протокола в соответствии с информацией протокола для управления осветительным устройством; причем сегментный контроллер выполнен с возможностью направлять первую часть информации протокола в осветительное устройство, причем, по меньшей мере, одно ответное сообщение осветительного устройства требуется в сегментном контроллере и причем сегментный контроллер выполнен с возможностью использовать ответное сообщение от осветительного устройства для дешифрования второй части информации протокола и для направления декодированной второй части информации протокола в осветительное устройство. 3 н. и 9 з.п. ф-лы, 8 ил.
Реферат
ОБЛАСТЬ ИЗОБРЕТЕНИЯ
Настоящее изобретение к системе, блоку управления сегментного контроллера и к способу для выполнения протокола безопасности в сети.
УРОВЕНЬ ТЕХНИКИ
В последнее время беспроводные ячеистые сети привлекают все больше и больше внимания, например, для дистанционного управления системами освещения, автоматизацией здания, мониторинговых применений, систем датчиков и медицинских применений. В частности, дистанционное управление наружными осветительными устройствами, так называемое телеуправление, становится все более и более важным. С одной стороны, оно определяется условиями окружающей среды, поскольку системы телеуправления способны использовать разные режимы управления яркостью, например, как функцию времени, погодных условий или времени года, обеспечивая наиболее эффективное использование энергии системами наружного освещения. С другой стороны, оно также определяется экономическими причинами, поскольку повышенная энергетическая эффективность также уменьшает стоимость эксплуатации. Более того, система может дистанционно контролировать потребление энергии и обнаруживать неисправности ламп, что позволяет определять наилучшее время для ремонта осветительных устройств или замены ламп.
Существующие в настоящий момент радиочастотные (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, чтобы разрешить взаимодействие неоднородных компьютерных систем, так чтобы можно было достигнуть полезной связи между прикладными процессами.
СУЩНОСТЬ ИЗОБРЕТЕНИЯ
С точки зрения вышеперечисленных недостатков и проблем в предшествующем уровне техники задача настоящего изобретения состоит в обеспечении системы, управляющего блока для сегментного контроллера и способа выполнения протокола безопасности в беспроводной сети, который допускает безопасную конфигурацию сетевых узлов от сервера, в то же время минимизируя требования по связности и загрузке на сервере, и уменьшение издержек связи.
Изобретение основано на идее заставить управляющее устройство, которое служит в качестве промежуточного объекта между сетевыми узлами и сервисным центром, выполнить конкретный протокол, по меньшей мере, одним из узлов путем обеспечения управляющего устройства соответствующей информацией протокола, в котором управляющее устройство требует заранее заданного ответного сообщения от соответствующего узла(ов), чтобы провести следующий этап протокола. Должно быть понятно, что сервисный центр, так же как и управляющее устройство или сегментный контроллер, может быть представлен определенным сетевым узлом, соответственно. Заранее заданное ответное сообщение может соответствовать правильному ответу(ам) от соответствующего узла(ов), который может быть дан узлом только в случае, когда протокол выполнен правильно. Таким образом, протокол может быть выполнен с помощью промежуточного управляющего устройства без создания большого трафика данных, как это было бы, например, в обычном безопасном квитировании, таким образом уменьшая издержки связи. Более того, выполняя протокол в зависимости от достоверности ответа узла, которым нужно управлять, может быть предотвращено манипулирование информацией, предоставляемой узлу, или неправильное использование информации управляющим устройством. Поэтому элементы сквозного квитирования между узлами и сервером могут быть реализованы в отношении безопасности. В одном примере протокол может относиться, по меньшей мере, к одному конфигурированию сетевых узлов, обновлению программного обеспечения узлов, активированию элементов узла и пуску узлов. Затем, например, информация об обновлении программного обеспечения может быть представлена узлам через управляющее устройство наряду с предотвращением манипулированием этой информацией и предохранением информации, предоставляемой узлам отличным от целевых узлов. Так как управляющее устройство может быть способно приступать к обработке протокола, только имея достоверные ответные сообщения от полномочного целевого узла(ов), то операции управляющего устройства, основанные на правильном протоколе, могут быть запущены.
В соответствии с одним аспектом настоящего изобретения представлена система для гарантирования выполнения правильного протокола в сети, такой как беспроводная ячеистая сеть, имеющая один или несколько узлов. Система содержит сервисный центр и сегментный контроллер, причем сервисный центр предоставляет информацию протокола сегментному контроллеру для выполнения протокола, по меньшей мере, одним конкретным узлом из сетевых узлов. Чтобы было возможно использовать информацию протокола, сегментный контроллер может нуждаться в информации, предоставляемой этим узлом в ответном сообщении. Это ответное сообщение может быть послано узлом после приема сообщения от сегментного контроллера, например, анонсирующее конкретную информацию или выполнение конкретного протокола. Предпочтительно, чтобы узел предоставлял достоверное ответное сообщение сегментному контроллеру только после успешной верификации предыдущего сообщения или информации, принятой от сегментного контроллера. Поэтому сегментный контроллер может быть запущен для предоставления правильной информации протокола правильному узлу, чтобы принять достоверное ответное сообщение для выполнения дальнейшего, последующего или очередного этапа протокола. С помощью этих средств корректная работа сегментного контроллера может быть отслежена узлом, который подлежит управлению, т.е. целевым узлом, таким образом предотвращая несанкционированное использование информации протокола. Подобным образом это предотвращает успешную установку вредоносных программ на узле. Поэтому может быть гарантировано без управления сервисным центром, что только информация, авторизованная сервисным центром, распространяется по сетевым узлам и что только участники, авторизованные сервисным центром, имеют доступ к распространяемой информации. Так как может потребоваться непостоянное соединение с сервисным центром в этом процессе, сервисный центр может быть частично вне сети (офлайн).
В одном варианте осуществления ответное сообщение узла включает в себя информацию об идентификационных данных узла и/или об идентификаторе сообщения, принятого от сегментного контроллера, которому узел отвечает этим ответным сообщением. Идентификатор сообщения может быть строкой или величиной, выведенной из принятого сообщения, например отпечатком сообщения от сегментного контроллера. Здесь отпечаток относится к уникальным идентифицирующим данным, путем выделения из них маленького ключа. Таким образом, идентификатор сообщения может относиться к функции контента сообщения, посланного из сегментного контроллера. Идентификационные данные узла могут относиться к индивидуальному ключу узла. В этом случае, также может быть гарантировано то, что сегментный контроллер выполняет протокол с правильным целевым узлом. Однако идентификационные данные узла могут также относиться к симметричному ключу, общему для всех узлов сети, например, к ключу настройки. Предпочтительно, чтобы этот ключ или идентификационные данные узла были неизвестны сегментному контроллеру. Таким образом, узел может генерировать проверочную величину или строчку в зависимости от содержания принятого сообщения и/или на основании его собственных идентификационных данных. Посредством этого ответное сообщение указывает идентификационные данные принимающего узла так же, как и содержание принятого сообщения, так что правильное выполнение протокола может быть легко удостоверено.
Предпочтительно, чтобы требовалось ответное сообщение от узла (или его частей), чтобы дешифровать, по меньшей мере, часть информации протокола, представленной сервисным центром сегментному контроллеру. Таким образом, сегментный контроллер может генерировать ключ для дешифрования на основании ответного сообщения от узла. Например, сегментный контроллер может быть снабжен сервисным центром, по меньшей мере, частично зашифрованным сообщением о конфигурации для конфигурирования, по меньшей мере, одного сетевого узла. Чтобы приступить к конфигурации узла, сегментный контроллер может затребовать ответное сообщение для дешифрования. Ответное сообщение может включать в себя ключ безопасности узла, например, ключ идентификации узла или ключ настройки, отпечаток сообщения или подобное ему в нераздельном или кодированном виде, так что сегментный контроллер или перехватывающие объекты не могут вывести исходные ключи безопасности. Поэтому сегментный контроллер может быть задействован, чтобы выполнить конкретный протокол конкретными узлами путем обеспечения сегментного контроллера соответственно зашифрованной информацией протокола. Таким образом, сегментный контроллер может не допустить как неправильное обращение с узлом, так и передачу информации протокола неавторизованным узлам, поскольку сегментный контроллер может дешифровать и использовать информацию протокола, только следуя протоколу. Если он не следует протоколу правильно, то он не может дешифровать информацию, и, таким образом, не может неправильно использовать информацию. После того, как сегментный контроллер дешифровал, по меньшей мере, часть информации протокола используя ответное сообщение, сегментный контроллер может отправить некоторую или всю дешифрованную информацию протокола узлу или узлам в сети.
Предпочтительно, чтобы информация протокола кодировалась на основании разных ключей. В этом варианте осуществления узел(ы) в сети могут возвращать ответное сообщение(я), соответствующее последнему принятому сообщению от сегментного контроллера. Эти/это ответные сообщения (или часть их/его) могут быть использованы поочередно сегментным контроллером, чтобы генерировать следующий ключ для дешифрования следующей части информации протокола. Например, информация для следующего этапа протокола может быть закодирована ожидаемым достоверным ответным сообщением узла для сообщения от сегментного контроллера, относящегося к предыдущему этапу протокола. Таким образом, информация протокола может быть несколько раз дешифрована. С помощью этих средств отслеживается правильная работа сегментного контроллера и гарантируется выполнение этапа за этапом.
В предпочтительном варианте осуществления сегментный контроллер снабжен информацией протокола для всех этапов протокола. В этом случае информация протокола может быть закодирована, основываясь на разных ключах. Это позволяет выполнять протокол путем введения преимущественно взаимодействий между сегментным контроллером и узлами, поскольку безопасность уже гарантирована требованием правильного ответного сообщения. Отсюда возможность подключения к серверу, нужная для выполнения протокола, так же как количество операций на сервере, может быть уменьшена.
Дополнительно сегментный контроллер может посылать запрос об информации о протоколе, относящейся к последующему этапу протокола, сервисному центру, когда сообщение запроса основывается на ответном сообщении, принятом от, по меньшей мере, одного узла. Таким образом, сервисный центр может подтверждать, используя информацию об ответном сообщении узла, включенного в сообщение запроса, что сегментный контроллер выполнил предыдущий этап протокола правильным узлом и/или правильным образом. Затем сервисный центр может снабдить сегментный контроллер дальнейшей информацией о протоколе, необходимой для выполнения следующего этапа протокола. В случае когда протокол управляет более чем одним узлом, сегментный контроллер может объединять информацию обо всех ответных сообщениях (или их наборе) от соответствующих узлов в сообщении запроса сервисному центру. Отсюда, сервисный центр может кроме того проверять, все ли узлы, которыми надо управлять, были успешно адресованы на предыдущем этапе протокола.
Предпочтительно, чтобы сервисный центр и узел сети совместно использовали, по меньшей мере, один общий ключ безопасности, ключ настройки, функцию шифрования, такую как хэш-функция, номер итерации хэш-функции и текущую величину хеширования. Сервисный центр может знать ключ безопасности индивидуальный для каждого сетевого узла или ключ безопасности общий для всех сетевых узлов или для одной или нескольких групп сетевых узлов. Альтернативно или дополнительно сервисный центр сохраняет цепочку хеширования или функцию хеширования для каждой сети или сегмента сети, и стартовое значение a0 для них. Затем, узел может быть инициализирован с помощью точки привязки соответствующей цепочки хеширования или функции. Функция хеширования может быть заменена другой односторонней функцией или цепочкой, в которой итеративное применение функции дает линии цепочек или элементы, выведенные из начальной строки или начального значения, например ai = HASH(ai-1). Желательно, чтобы протокол и/или ответное сообщение, по меньшей мере, частично основывались на функции хеширования, такой как алгоритм SHA-2 хеширования. С помощью этих средств узел, который инициализирован точкой привязки цепочки хеширования и который отслеживает текущий элемент ai цепочки хеширования, может подтверждать принятое сообщение с помощью проверки, удовлетворяет ли элемент ai хеширования, включенный в принятое сообщение, условию ai= HASH(ai-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 знает ключ Kcom настройки, общий для всех узлов сети, идентификационные данные узлов или специальные узловые ключи Knode сетевых узлов 10, HASH-функцию, такую как SHA256, которая используется узлами в сети, начальную величину HASH-функции a0 и, по меньшей мере, один номер 1 итерации HASH-функции и последний используемый элемент aL HASH-цепочки. Сетевые узлы 10, наоборот, знают ключ Kcom настройки, HASH-функцию SHA256 сети, последний элемент или точку привязки aN HASH-цепочки и последний элемент aL HASH-цепочки, который был открыт.
На фиг.5 показан принцип HASH-цепочки. HASH-цепочка включает в себя N элементов ai, которые генерируются с использованием односторонней HASH-функции с aL= HASH(aL-1). Таким образом, каждый элемент ai HASH-цепочки может быть генерирован только на основании предыдущего элемента ai-1 HASH-цепочки. Поскольку только сервисный центр 80 знает начальный элемент a0 HASH-цепочки, то только сервисный центр 80 может генерировать следующий элемент ai+1 HASH-цепочки. Для аутентификации информации сервисный центр 80 использует элемент ai HASH-цепочки в противоположном направлении, как показано на фиг.5. Например, сервисный центр 80 включает в себя текущий элемент aL-1 HASH-цепочки в сообщении узлу 10. Затем узел 10, который знает только последний используемый элемент aL HASH-цепочки, может подтвердить сообщение путем проверки верно ли aL= HASH(aL-1). С помощью этого средства информация может быть аутентифицирована, не нуждаясь в шифровании c открытым ключом.
Как показано на фиг.4, сервисный центр 80 начинает выполнение протокола обновления программного обеспечения, выполняемого сегментным контроллером 60, с помощью передачи первого сообщения М1 сегментному контроллеру 60. Первое сообщение М1 включает в себя предварительное уведомление, предварительное уведомление является значением функции, такой как функция сообщения с аутентификацией кода, зависящей от текущего элемента aL-1 HASH-цепочки и от отпечатка обновления программного обеспечения. Здесь отпечаток может также относиться к значению функции или строки. Например, предварительное уведомление может быть получено с использованием следующего выражения:
М1: preack=HMAC(SHA256(Ek(SW))||salt, aL-1),
в котором две вертикальные линии указывают соединение элементов, НМАС относится к ключевому HASH-сообщению с аутентификацией кода, SHA256 – это HASH-функция SHA-2 с 256 битовым отпечатком, Ек относится к функции шифрования на основании ключа К шифрования, SW обозначает обновление программного обеспечения, salt - это, по меньшей мере, 16 байтовое контрольное слово, специальное для обновления программного обеспечения и aL-1 - это текущий элемент HASH-цепочки. Ключ К шифрования может быть выведен из ключа Kcom настройки и «соли», например как К=НМАС(salt, Kcom). Сегментный контроллер 60 направляет сообщение М1 узлу 10, который хранит предварительное уведомление. Предварительное уведомление используется для выполнения подтверждения обновления программного обеспечения и создания содержания сообщения на следующем этапе. Так как предварительное уведомлен