Как защитить ключ дешифрования от декомпиляции?

Question

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

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

Моя идея не в том, чтобы напрямую вставить ключ в мой код, а в то, чтобы он прошел через какое-то преобразование.Например, я мог бы написать -

private static final byte[] HC256A = Hex
            .decode("8589075b0df3f6d82fc0c5425179b6a6"
                    + "3465f053f2891f808b24744e18480b72"
                    + "ec2792cdbf4dcfeb7769bf8dfa14aee4"
                    + "7b4c50e8eaf3a9c8f506016c81697e32");

Таким образом, кто-то, смотрящий на байт-код, не может сразу его прочитать.Но придется следовать логике и применять к ней преобразования, что не будет намного проще на уровне байтов.

Так что вы, ребята, думаете?Это полезно?Что может быть лучшим преобразованием, кроме шестнадцатеричного декодирования?Существуют ли другие способы защиты ключей шифрования с жестким кодом?

Спасибо за все ваши предложения.

Answer 1

Правильный способ атаковать такое запутывание (особенно в языках байт-кода) - прикрепить отладчик к месту, куда передается ключ (если отладка невозможна, начните анализировать код с этого места).Таким образом, злоумышленнику вообще не нужно искать ключ, и ему все равно, насколько запутан ключ.Так что вам нужно переосмыслить свой дизайн.

Если вы хотите защитить только от скрытных любителей, то достаточно разделить ключ и сделать XOR его части (возможно, с разными ключами).Еще один трюк - получение ключа из текстовых констант, уже присутствующих в коде (например, имени приложения).Это делает ключ менее очевидным, чем разделение или XORing.

Answer 2

Не кодируйте ключ в исходный код вообще.Держите его отдельно, отправляйте отдельно, например, в хранилище ключей Java, и только для клиентов / сайтов / клиентов, которым вы доверяете, и добавьте некоторые юридические права в лицензию, которая возлагает на них ответственность, если они утекут в хранилище ключей.

Answer 3

Столкнулся с аналогичной проблемой (в c) Я пошел с одноразовыми прокладками XOR.Это хорошо, потому что это выглядит как мусор ... если вы действительно умны, вы можете отследить этот (неправильный) ключ в использовании.Я бы избегал всего, что вводит понятные человеку строки, поскольку они неизменно привлекают внимание к этому фрагменту кода.