Поворот ключа с помощью безопасного элемента
У меня есть основной вопрос о повороте ключа для устройств IoT.
Мы планируем использовать безопасный элемент ( пример) для генерации пар ключей. Поэтому пары ключей генерируются на чипе, на устройстве IoT.
После того, как открытый ключ изначально загружен в Google IoT, как можно выполнить вращение ключа?
Используя существующий закрытый ключ, устройство может подписать JWT и аутентифицировать себя в Google IoT. Можно ли использовать JWT после создания новой пары ключей на устройстве для аутентификации при загрузке нового открытого ключа в реестр?
Пожалуйста, поделитесь примерами ротации ключей для этого типа платформы. Спасибо!
0 ответов
Из документации по Google Cloud IoT Core + ATECC608:
Например, закрытый ключ генерируется самим защищенным элементом, а не внешней стороной (CA). Чип использует генератор случайных чисел для создания ключа, что делает практически невозможным его получение. Закрытый ключ никогда не покидает чип, никогда. Используя закрытый ключ, чип сможет генерировать открытый ключ, который может быть подписан выбранным центром сертификации компании.
Microchip выполняет эту подпись в специализированном защищенном объекте в США, где изолированный завод будет хранить промежуточные ключи CA клиента на высоконадежном сервере, подключенном к производственной линии. Все пары ключей и сертификаты генерируются в этой строке в нормативной среде, которая позволяет проводить аудит и обеспечивать высокий уровень шифрования.
После того как каждый из защищенных элементов сгенерирует свои пары ключей, соответствующие открытые ключи отправляются в учетную запись Google Cloud клиента и надежно сохраняются в диспетчере устройств Cloud IoT Core.
Таким образом, пара ключей является фиксированной для данного чипа защищенного элемента. Хотя GCP IoT Core позволяет использовать до 3 открытых ключей на каждое устройство IoT, вам придется физически заменить микросхему защищенного элемента, чтобы получить новую пару ключей для поворота ключей.
Идея защищенного элемента заключается в том, что закрытый ключ не может быть скомпрометирован, поэтому его не нужно вращать (читай: нельзя вращать). Хотя обычно рекомендуется вращать ключи, возможность поворачивать ключи по своей природе представляет уязвимость - плохой субъект теоретически может повернуть новый ключ по своему выбору, чтобы получить контроль над системой, поскольку существует механизм замены ключа. Если механизма не существует, то это не вектор для взлома. Существует обзор этого поведения, который вы можете прочитать для получения дополнительной информации.
По моему опыту, наиболее распространенным вариантом использования этого является случай, когда у вас есть устройство в поле, и вы заменяете "главную плату", которая включает в себя элемент безопасности. Вы можете добавить открытый ключ нового защищенного элемента, который был отправлен в качестве замены, в IoT Core, чтобы при замене "основной платы" новая пара ключей уже была зарегистрирована и устройство могло автоматически получать информацию о состоянии и конфигурации из IoT. ядро. Пока устройство синхронизирует данные конфигурации и состояния с IoT Core, новая "основная плата" может стать тем же устройством, но с новым "мозгом" и новой парой ключей.
JWT генерируется на основе ключей, но по своей конструкции JWT имеет короткий срок службы (по умолчанию 1 час, максимум 24 часа). Таким образом, новые JWT будут генерироваться на основе тех же ключей.