Я думаю, что ваш вопрос: как проверить происхождение файла для данного компьютера, даже если этот компьютер скомпрометирован?
Давайте посмотрим на общий план.
- Вы создаете приложение.
- Пользователь на другом компьютере устанавливает ваше приложение на свой компьютер.
- Пользователь генерирует файлы.
- Компьютер пользователя взломан.
- Пользователь открывает файл в вашем приложении.
Теперь по вопросам:
Какой тип компромисса мы проектируем против?
Перед лицом полного компромисса решения не существует. В полном компромиссе злоумышленник может изменить любое приложение или функцию операционной системы.
Итак, против каких компромиссов мы можем придумать?
Должны быть некоторые функции, которым мы все еще можем доверять. Злоумышленник может скомпрометировать ваше приложение, и в этом случае любая проверка, выполненная вашим приложением, не может быть доверенной. Злоумышленник может поставить под угрозу операционную систему. Это небольшой шаг от компрометации операционной системы к компрометации приложения. Итак, давайте предположим, что злоумышленник не скомпрометировал операционную систему или ваше приложение. Предположим, что злоумышленник имеет возможность изменять любой файл в системе, кроме файла, содержащего ваш исполняемый файл, и файлов, содержащих основные компоненты операционной системы.
Как мы аутентифицируем происхождение?
Хеш-значения, такие как SHA1 и MD5, используются для проверки целостности. Значение хэша для файла может только сказать вам, был ли файл неизменен, так как хэш был создан. Он не говорит вам, откуда пришел файл. Цифровая подпись обеспечивает проверку происхождения. Цифровая подпись сообщает, что подписанные данные были получены от лица, которое контролирует ключ, используемый для подписи сообщения.
Теперь, если вы хотите проверить, что файл на компьютере был создан с этого компьютера, тогда на каждом компьютере должен быть свой ключ для подписи цифровых сообщений.
Это не проблема, если у вас есть только одна копия приложения на одном компьютере. Но когда у вас их больше, вам нужно подумать о генерации и распределении ключей. Генерация и распространение ключей - очень сложная проблема. Цифровые подписи требуют наличия пары открытого личного ключа. Закрытый ключ должен быть защищен, и он должен быть уникальным для каждого компьютера. Ранее мы предполагали, что злоумышленник не может изменить ваше приложение, но я думаю, что будет справедливо предположить, что злоумышленник может прочитать ваш исполняемый файл. Это предположение делает ваш исполняемый файл плохим местом для хранения вашего закрытого ключа. Вы можете зашифровать свой ключ, но тогда вам понадобится другой ключ для расшифровки вашего ключа. Здесь есть несколько возможных ответов:
- Использование операционной системы для генерации ключа и создания подписей.
- Используйте доверенную службу подписи и проверки сети.
- Запомни свой ключ. Или запомните пароль или пин-код, используемый для шифрования вашего ключа.
Использование операционной системы работает только в том случае, если операционная система предоставляет эти функции. Основная проблема здесь в том, как узнать, что у каждого компьютера есть уникальный ключ?
Сетевой сервер очень похож на операционную систему, но вы можете обеспечить большую защиту для сервера, чем для отдельного компьютера. При наличии достаточной защиты вы можете предположить, что будет обнаружен компромисс, и в этом случае он остановит службу подписи и проверки. Это также дает вам гарантию уникальных ключей, потому что сервер будет генерировать новый уникальный ключ для каждого экземпляра приложения.
Я думаю, что мы все знакомы с проблемами, связанными с запомненными паролями и булавками. Небольшой вариант здесь заключается в том, что вы можете использовать более короткий или более простой пароль для шифрования более крупного и сложного ключа. Недостатком более короткого / более простого пароля является то, что становится проще взломать принудительную расшифровку более длинного / сложного ключа.