Использование имени и/или ключей конечной точки клиента в интерфейсе начальной загрузки LwM2M.
Я читал спецификацию LwM2M (версия 1.1.1) и поигрался с Eclipse Leshan, чтобы проверить все самому. Мне удалось загрузить клиент с помощью сервера BS, а затем зарегистрироваться на сервере управления устройствами и успешно отправить туда данные. Но до сих пор я делал все это, используя режим безопасности «nosec», настраивая выделенную конечную точку для клиента на моем BS-сервере и используя то же имя для конечной точки на клиенте.
Вместо этого я попробовал использовать предварительный общий ключ (PSK) с идентификатором на сервере BS, и это работает, пока я установил имя клиента конечной точки наnullна клиенте. Я понял, что этот параметр является необязательным и может быть опущен, если он уже включен в идентификатор , но сервер начальной загрузки ДОЛЖЕН проверить имя клиента конечной точки на соответствие заданному идентификатору, если оба заданы, и вернуть «неверный запрос», если они этого не сделают. не совпадает.
Я также понял, что имя клиента конечной точки должно быть уникальным для каждого клиента (для каждого сервера).
Не означает ли это, что сервер начальной загрузки должен заранее знать всех клиентов, которые будут запрашивать у него начальную загрузку? Если каждый клиент может отправлять уникальное имя клиента конечной точки, и сервер должен проверить его, если оно задано, похоже, что сервер должен иметь список разрешенных имен и/или идентификаторов для успешной загрузки.
Раньше я планировал иметь загрузочный сервер, который мог бы обслуживать все устройства одного клиента — тысячи из них — при условии, что каждый из них запрашивает конфигурацию с использованием индивидуального идентификатора и ключа, без необходимости знать, сколько таких устройств имеется. будут или их идентификаторы, специфичные для устройства. Затем я мог бы предоставить каждому из этих устройств одну и ту же конфигурацию сервера LwM2M и просто собрать список устройств, которые были загружены (и зарегистрированы).
Но теперь кажется, что такой подход невозможен, или я что-то сильно неправильно понял в интерфейсе начальной загрузки. Что он?
Обновление:
я думаю, что мне следовало спросить, чтобы меня лучше поняли: «Все ли устройства должны быть предварительно подготовлены к серверу начальной загрузки, прежде чем они смогут запустить интерфейс начальной загрузки?»
Я пришел к выводу, что это действительно необходимо, если сервер соответствует стандарту LwM2M, в том числе и с точки зрения безопасности; серверу BS необходимо идентифицировать каждого клиента, и поскольку каждый клиент должен иметь уникальный ключ (или сертификат), сервер может распознавать только клиентов, ключи которых ему были предварительно предоставлены.
2 ответа
(Я разработчик Лэшань)
Вместо этого я попробовал использовать предварительный общий ключ (PSK) с идентификатором на сервере BS, и это работает, пока я установил имя клиента конечной точки на
nullна клиенте.
Это звучит странно. Пожалуйста, откройте проблему в репозитории Leshan , чтобы обсудить это.
Я понял, что этот параметр является необязательным и может быть опущен, если он уже включен в идентификатор, но сервер начальной загрузки ДОЛЖЕН проверять имя клиента конечной точки на соответствие заданному идентификатору, если оба заданы, и возвращать «неверный запрос», если они этого не делают. не совпадает.
Это правда, начиная с LWM2M v1.1.x. В LWM2M v1.0.x имя конечной точки является обязательным дляRegisterиBootstrapЗапрос.
В Лэшане это пока не реализовано, я создал соответствующую задачу. (не стесняйтесь комментировать, если вам это нужно)
Я также понял, что имя клиента конечной точки должно быть уникальным для каждого клиента (для каждого сервера).
Читая это , я тоже это понимаю.
Не означает ли это, что сервер начальной загрузки должен заранее знать всех клиентов, которые будут запрашивать у него начальную загрузку? Если каждый клиент может отправлять уникальное имя клиента конечной точки, и сервер должен проверить его, если оно задано, похоже, что сервер должен иметь список разрешенных имен и/или идентификаторов для успешной загрузки.
Для leshan-server-demo и leshan-bsserver-demo да, они должны знать каждое устройство. (но это всего лишь демо)
Для LWM2M в целом наличие списка всех известных устройств, вероятно, является простым решением. Но вы можете себе представить, что у вас есть своего рода шаблон или алгоритм, который позволит вам узнать, разрешено ли устройство. (Это может быть сложнее с точки зрения безопасности, чем простой список)
Для библиотеки Leshan (которая используется для сборки leshan-?server-demo) существует некоторый интерфейс, позволяющий реализовать собственное поведение. (ВидетьAuthorizer,BootstrapAuthorizer,DefaultAuthorizer,DefaultBootstrapAuthorizer,BootstrapConfigStore)
Раньше я планировал иметь загрузочный сервер, который мог бы обслуживать все устройства одного клиента — тысячи из них — при условии, что каждый из них запрашивает конфигурацию с использованием индивидуального идентификатора и ключа, без необходимости знать, сколько таких устройств имеется. будут или их идентификаторы, специфичные для устройства. Затем я мог бы предоставить каждому из этих устройств одну и ту же конфигурацию сервера LwM2M и просто собрать список устройств, которые были загружены (и зарегистрированы).
Но теперь кажется, что такой подход невозможен, или я что-то сильно неправильно понял в интерфейсе начальной загрузки. Что он?
Мне не совсем понятно, что вы имеете в виду, но я думаю, это можно сделать, если вы реализуете свой собственный сервер (по крайней мере, библиотека Leshan должна предоставить API, который позволит вам это сделать ☝)
Но имейте в виду, что таким способом довольно легко снизить уровень безопасности.
На демо-сервере Leshan это действительно так — вам необходимо определить общее имя сертификата устройства в сервисе Leshan. В общем, можно было поступить иначе. Например, вы можете иметь один закрытый ключ, который будет подписывать несколько сертификатов устройств (каждый сертификат устройства предоставляется другому устройству). Сертификат, соответствующий этому закрытому ключу, будет загружен в службу LwM2M, и облако будет идентифицировать устройства, проверив, что сертификат устройства подписан загруженным сертификатом. Вот как мы реализуем это в Izuma Cloud — https://www.izumanetworks.com/