управляйте рабочим каталогом для <входной тип = “файл”>?

Из документации Google Cloud IoT Core + ATECC608 :

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

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

После того как каждый из защищенных элементов сгенерировал свои пары ключей, соответствующие открытые ключи отправляются в учетную запись Google Cloud клиента и надежно хранятся в диспетчере устройств Cloud IoT Core.

blockquote>

Таким образом, пара ключей является фиксированной для данного чипа защищенного элемента. Хотя GCP IoT Core позволяет использовать до 3 открытых ключей на каждое устройство IoT, вам потребуется физически заменить микросхему защищенного элемента, чтобы получить новую пару ключей для ключей поворота .

Идея защищенного элемента заключается в том, что закрытый ключ не может быть взломан , поэтому не нуждается во вращении (читай: не может вращаться). Хотя обычно рекомендуется вращать ключи, возможность поворачивать ключи по своей природе представляет уязвимость - плохой субъект теоретически может повернуть новый ключ по своему выбору, чтобы получить контроль над системой, поскольку существует механизм замены ключа. Если механизма не существует, то это не вектор для взлома. Существует обзор этого поведения , который вы можете прочитать для получения дополнительной информации.

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

JWT генерируется на основе ключей, но по своей конструкции JWT имеет короткий срок службы ( по умолчанию 1 час с максимум 24 часами). Таким образом, новые JWT будут генерироваться на основе тех же ключей.