Автоматическая регистрация устройства
На странице онлайн-документации Cloud IOT "Защита устройства" описывается процесс подготовки устройства, при котором "поставщик" создает пару ключей и распространяет закрытый ключ на устройство. Они идут на шаг дальше и рекомендуют использовать стратегию с вращающимся ключом для дополнительной безопасности. Все этапы этого процесса создания устройства могут быть автоматизированы с помощью основных API IOT, за исключением этапа распространения ключа.
Это намекает на то, что существует способ безопасного создания пары ключей и передачи закрытого ключа на устройство программно для тысяч новых устройств, а не вручную для каждого устройства. Точно так же должен быть способ генерировать и передавать новые пары ключей в стратегии револьверных ключей.
Любые предложения о том, как это сделать? Возможно, есть стандартный метод, о котором я не знаю. Заранее спасибо за любые отзывы.
1 ответ
Это намекает на то, что существует способ безопасного создания пары ключей и передачи закрытого ключа на устройство программно для тысяч новых устройств, а не вручную для каждого устройства.
Я полагаю, что язык здесь намеренно менее конкретен, чтобы оставить место для случаев, когда у разработчика устройства есть безопасный или уникальный способ (например, зашифрованное радио) для передачи ключей на устройства. Во многих случаях у вас будет аппаратно-ориентированное или ОС-решение для обновления прошивки устройства, и этот механизм является лучшим подходом и позволяет вам отзывать и восстанавливать скомпрометированные устройства.
Я думаю, что на самом деле есть два основных подхода к распространению закрытого ключа на данное устройство:
- Распределение / инициализация на этапе производства / позднего производства (безопасный)
- Постпроизводство распространения (например, после того, как устройство было куплено / установлено / развернуто)
Для распространения при изготовлении или при позднем изготовлении вы, как правило, будете устанавливать ключи на устройство, используя что-то, что физически подключено к устройству в безопасной среде. При изготовлении я мог бы представить, что на заводе-изготовителе (контракт) производитель вызывает API, используя делегированные учетные данные, чтобы отправить Google открытый ключ, а затем безопасно устанавливает закрытый ключ на устройстве. При позднем изготовлении происходит тот же процесс регистрации и надежной установки секретного ключа, который выполняется только за пределами производственного объекта лицом, заключившим контракт на изготовление устройства.
В обоих случаях регистрации устройства при изготовлении вы можете зарегистрировать несколько сертификатов для каждого устройства, чтобы вы могли эффективно "менять свой пароль" с течением времени, чередуя сертификаты, связанные с устройством, с истечением срока действия сертификатов или отзывать подозрительные сертификаты, используя дополнительные учетные данные В некоторых случаях это хорошо, потому что, если утечка только одного из учетных данных на устройстве, вы можете переключиться на альтернативный, защищенный на устройстве. У этого подхода есть небольшой компромисс: в случае утечки нескольких учетных данных для данного устройства у вас будет банальный риск одновременной утечки нескольких учетных данных. И это приводит нас ко второму сегменту распределения ключей - постпроизводству.
Для распространения закрытого ключа после изготовления он становится немного сложнее, потому что вы эффективно создаете другой канал для устройств, которые будут управляться в вашем реестре. По этой причине сложно посоветовать, что делать, если у вас нет установленного безопасного канала для полного восстановления взломанного устройства удаленно.