Однако существуют ли какие-либо современные, более совершенные подходы к созданию таких «автономных установочных ключей»?
Есть два очевидных подхода:
- Одним из них является использование кода аутентификации сообщения (MAC); это криптографический алгоритм, который принимает строку и секретный ключ и генерирует «метку»; идея состоит в том, что, не зная секретного ключа, трудно сгенерировать другую пару строк/тегов, которая проверяется.
Итак, что вы должны сделать как производитель, так это выбрать случайный секретный ключ (который вы вставите в свои продукты). Чтобы сгенерировать «ключ продукта» (этикетку, прикрепленную к продукту), вы должны взять порядковый номер, запустить его через MAC для создания тега и сделать порядковый номер и тег ключом продукта.
Затем, когда продукт установлен, пользователь вводит ключ продукта; программное обеспечение разделяет порядковый номер и тег; затем он запускает порядковый номер через MAC (используя секретный ключ, который вставил производитель) и сравнивает этот вычисленный тег с тегом, который был в ключе продукта — если они совпадают, вы продолжаете установку.
Плюсы в том, что это просто и что длину ключа продукта можно легко контролировать (при хорошем MAC, скажем, HMAC, 20-битный тег сделает вероятность случайного угадывания менее одной на миллион на предположение — если это недостаточно низко, просто выберите более длинный тег).
Недостатком этого является то, что если хороший хакер взломает ваш продукт, он может извлечь секретный ключ, а затем продолжить и сгенерировать свои собственные ключи продукта по своему желанию. Были попытки разработать реализации, устойчивые к этому («криптография белого ящика»); они оказались разочаровывающими. Однако если усилия злоумышленника превышают усилия по распространению заведомо исправного ключа продукта, это может быть приемлемо.
- Другой подход — использовать алгоритм подписи с открытым ключом (с короткой подписью).
Эта идея аналогична, за исключением того, что производитель генерирует пару открытого/закрытого ключа и вставляет открытый ключ в устройство.
Производитель использует закрытый ключ для создания «ключей продукта»; при установке программное обеспечение использует свою копию открытого ключа для проверки ключа продукта.
Положительным моментом является то, что нам больше не нужно беспокоиться о том, что хакер получит возможность создавать новые ключи продукта — для этого ему нужен закрытый ключ, а его нет на устройстве.
Недостатком является длина тега - даже алгоритмы с самой короткой подписью (я считаю, что это BLS) по-прежнему имеют умеренно длинные подписи (например, 256 бит для 100 бит безопасности); и, в отличие от случая с MAC, их нельзя обрезать.
Были компании, которые использовали подписи для своих ключей продукта — я полагаю, что они были в меньшинстве.
