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

У меня сейчас можно заливать через веб-интерфейс. Не вижу препятствий заскриптовать это дело: центральный сервер легко может сделать всё сам, нужен лишь список айпишников и файл прошивки.
Слышал, делают так, что по команде через SNMP устройство само ломится на TFTP сервер и вытягивает новую прошивку самостоятельно. Вот и один из заказчиков такое просит. Придётся делать.

Проблема надуманная.
Только если заняться нечем, то можно обсуждать.

вы и занятой, и я вас не заставляю


в том и проблема, как я буду собирать, хранить и поддерживать список в 100500 адресов ? для этого ещё 100 человек потребуется


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


шустрые пронырливые китайцы подсуетятся, вытянут прошивку и нарисуют ещё 100500000 девайсов

Сообщение отредактировал Огурцов - Dec 8 2017, 12:32

А чего обсуждать - вот оно и решение. Все как сейчас у всех: кому надо, достают файл и обновляются. Кому не надо, и так хорошо.


Бутлодер с шифрованием. Тоже типовое решение.

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

Это теперь в IoT называется deployment.
Смотрите технологию AWS Greengrass
Ключевые протоколы - TCP, TSL, JSON, MQTT, Greengrass
Ну а все это счастье теперь получаете с Amazon FreeRTOS

Не понял мысли о 100500 ключах. Зачем? Ключ один, в бутлодере. Он закрыт и не обновляется. Или вы хотите и бутлодер перепрошивать удаленно?

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

так системы шифрования не строят - скомпрометируется один девайс и все последующие версии прошивки будут скомпрометированы


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




и в чём смысл ? ключ публичный, а значит любой может сделать аналогичный девайс и залить в туда мою прошивку
а задача - ровно обратная

Сообщение отредактировал Огурцов - Dec 8 2017, 14:10

Да у вас, милейший, с пониманием принципов PKI проблема. Гугл в помощь...

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

Сообщение отредактировал Огурцов - Dec 8 2017, 14:40

Читать сюда, для начала, особенно раздел Digital signatures. Ну и гуглить туда же на тему Code signing.
100500 сертификатов и ключей вам нужно будет хранить в случае, если вы хотите для каждого из 100500 девайсов делать уникальную прошивку, которая будет работать только на данном конкретном экземпляре устройства.
Если вам нужно только удостовериться в факте того, что прошивка получена из надежного источника - обходимся одной парой private/public keys, подписываем прошивку приватным ключом, при загрузке публичным ключом проверяем сигнатуру, если валидна (поверка хеша публичным ключом пройдена) - подпись верна, поехали.
Приватный ключ хранится в тяжелом сейфе с толстыми стенками и в открытом виде нигде не появляется. Точнее, появляется, но на очень короткое время (собственно, на время генерации подписи, потом он должен исчезнуть из памяти, иначе СКЗИ сертифицировано не будет, но это уже лирика). Вы же упоминали термин "компрометация"- это как раз "уход" приватного ключа по тем или иным причинам. Из приватного ключа можно сделать публичный, наоборот - нет, на этой идее вся PKI и строится.

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

Сообщение отредактировал Огурцов - Dec 8 2017, 15:04

Это называется Mutual authentication, и тогда, действительно, тянет за собой понятия CA, SCEP/CMPv2, CRL и т.д. и т.п.