[Отказ от ответственности: я профессионал в области безопасности / криптозащиты и каждый день занимаюсь вопросами архитектуры безопасности.]
Вы столкнулись с проблемой хранения учетных данных таким образом, чтобы автоматический процесс мог получить к ним доступ, а злоумышленник - нет. Это хорошо известная и очень сложная проблема.
Если ваше устройство IoT имеет встроенное в материнскую плату аппаратное хранилище ключей, такое как некоторые TPM, или эквивалент аппаратного хранилища ключей Android или Apple Secure Enclave, то вы можете использовать его.
На традиционных серверах вы можете использовать HSM или смарт-карты, но единственное полное программное решение, о котором я знаю, - это получить ключ AES из своего рода «аппаратного отпечатка», созданного путем объединения серийных номеров всех аппаратных устройств. Затем используйте этот ключ AES для шифрования учетных данных. Процесс, запущенный на том же сервере, может восстановить ключ AES и расшифровать учетные данные, но после извлечения файла с сервера это по существу не расшифровывается.
IoT вбивает в это ключ по двум причинам:
Предположение, что аппаратные серийные номера являются уникальными, вероятно, не имеет места, и
В отличие от серверов, злоумышленники имеют физический доступ к устройству, поэтому, вероятно, могут получить на устройстве оболочку для запуска программы расшифровки.
И аппаратное шифрование (TPM), и шифрование «аппаратного отпечатка» в лучшем случае являются обфускацией, потому что, по сути, если локальный процесс может расшифровать данные, то злоумышленник, способный запустить этот локальный процесс, может также расшифровать его.
Таким образом, стандартный трюк выглядит так, как будто он здесь не работает. Первый вопрос, который вам нужно задать себе:
- Какова моя модель угроз / где находится этот проект в
Secure <--> Convenientмасштабе?
В конечном счете, я думаю, что вам нужно либо решить это, security > convenienceи заставить человека вводить учетные данные после каждой загрузки (используя что-то вроде ответа @ BenceKaulics ), либо вы решаете это security < convenienceи просто помещаете учетные данные на устройство, возможно, используя некоторое запутывание, если вы чувствую, что имеет значение.
Это сложная проблема, которая усугубляется природой устройств IoT.
Для полноты полного промышленного решения этой проблемы:
- Предоставьте каждому устройству IoT уникальный открытый ключ RSA во время изготовления. Запишите этот открытый ключ в БД относительно серийного номера устройства.
- Храните конфиденциальные учетные данные на соответствующем сервере, назовем его «шлюзом».
- Когда устройство IoT аутентифицируется на шлюзе (используя свой ключ RSA), шлюз открывает для него сеанс с использованием сохраненных учетных данных и передает маркер сеанса обратно на устройство.
- Для обеспечения максимальной безопасности, шлюз является физическим (или VPN) шлюзом, так что весь трафик с устройства IoT проходит через шлюз, и вы имеете больший контроль над правилами межсетевого экрана и другими вещами - в идеале, предотвращая прямое подключение устройства (без VPN-туннелирования) Доступ к сети Интернет.
Таким образом, злоумышленник, который скомпрометирует устройство, может открыть сеанс, но никогда не имеет прямого доступа к учетным данным.