Как защитить ключ шифрования от обратного инжиниринга? - PullRequest
2 голосов
/ 23 июня 2011

Мое программное обеспечение использует AES Rijndael.

Я использую хеш SHA-256 для генерации ключа из строки произвольной длины, а затем передаю его как закрытый и открытый ключи, поскольку в этом случае мне не нужно различать эти два.

Как защитить мой ключ от взлома исполняемого файла?

Я знаю, что не нужно использовать литерал, но вместо этого генерировать ключ во время выполнения с некоторыми заранее определенными шагами, но все равно ключ все еще будет в памяти перед его отправкой в ​​функцию инициализации AES, и поэтому его довольно легко получить затем.

AES, очевидно, очень безопасен, но что толку от этого, если вместо этого кто-то ломает исполняемый файл?

Есть ли какая-то распространенная практика при решении этой проблемы?

Ответы [ 2 ]

5 голосов
/ 27 июня 2011

Этого нельзя сделать. Это основная проблема, например, Схема DRM на ПК: им нужен ключ в памяти, чтобы его можно было извлечь. Вы можете скрыть это, пока оно не используется, но это все. И если ваше приложение популярно и распространяется, то кто-то взломает вам 1002 * восхитительную схему Вот почему некоторые компании используют ключи или чипы TPM для приложений с высокой стоимостью.

3 голосов
/ 19 апреля 2012

Существует нечто - очень сложное в математической теории - называемое «криптография белого ящика». В этом случае алгоритм AES модифицируется таким образом, что он создает секрет во время шифрования. Я не знаю точно, как это достигается, но этот не должен иметь инициализированный секрет, но секрет является частью алгоритма. Злоумышленник может увидеть, что ваша реализация AES немного «отличается», но ни разу во время выполнения ключ не виден в памяти. Единственный шанс, который может получить злоумышленник, - это скопировать весь код белого ящика, но это действительно трудно реконструировать - он просто сможет его использовать. В любом случае, в зависимости от того, как вы используете AES, этого может быть достаточно для взлома.

...