如何保护解密密钥不被反编译？答案

【问题标题】：How to protect decryption key from decompilation?如何保护解密密钥不被反编译？
【发布时间】：2011-08-29 12:28:54
【问题描述】：

我是一名初学 Java 程序员。我正在开发一个解密一些数据的应用程序。解密密钥被硬编码到软件中，因此可以通过分析字节码来查看。

我知道无法完全防止逆向工程，所以我正在尝试做的是让这个过程尽可能困难。

我的想法不是直接将密钥放入我的代码中，而是让它经过某种转换。例如，我可以写 -

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

这样查看字节码的人就无法立即读取它。但必须遵循逻辑并对其应用转换，这在字节级别不会那么容易。

那你们觉得呢？这有用吗？除了十六进制解码之外，最好的转换是什么？有没有其他方法可以保护硬编码的解密密钥？

感谢您的所有建议。

【问题讨论】：

你可以监听调试器连接（在 C++ 中工作，不知道如何在 Java 中做到这一点），如果是，从内存中删除值。
被解码的数据的敏感度是多少？这将有助于指导为保护该数据付出多少努力。在字节码中隐藏密钥的任何形式都相对容易被击败。此外，这将要求软件的每个用户都拥有相同的密钥，并且需要重新编译才能更改为密钥。
数据相当敏感。这是一种数字媒体印刷品，如果泄露会给公司带来严重的问题。

标签： java security reverse-engineering encryption drm

【解决方案1】：

攻击这种混淆的正确方法（尤其是在字节码语言中）是将调试器附加到传递密钥的位置（如果无法调试，则从该位置开始分析代码）。这样，攻击者根本不需要寻找密钥，也不关心密钥的混淆程度。所以你需要重新考虑你的设计。

如果您只想保护业余潜伏者，那么拆分密钥并对它的各个部分进行异或（可能使用不同的密钥）就足够了。还有一个技巧 - 从代码中已经存在的文本常量（例如应用程序名称）中派生密钥。这使得密钥不如拆分或 XORing 明显。

【讨论】：

+1 回答 both 为什么你不应该这样做以及如何去做 ;-)
@Joachim 实际上这两部分涵盖了不同的攻击者集合 :)

【解决方案2】：

根本不要将密钥编码到源代码中。分开存放，分开运输，例如在 Java 密钥库中，并且只提供给您信任的客户/站点/客户，并在许可证中添加一些法律术语，如果他们泄露密钥库，则由他们承担责任。

【讨论】：

【解决方案3】：

面对类似的问题（在 c 中），我选择了一次性 XOR 垫。这很好，因为它看起来像垃圾......如果你真的很聪明，你可以窥探正在使用的（不正确的）密钥。我会避免任何注入人类可读字符串的东西，因为它们总是会引起人们对那段代码的注意。

【讨论】：

应用了一些位移的 XOR 垫可能和它得到的一样好：它并不是真正的好预防，但它挫败了那些简单地打电话给 javah 并希望直接转储密钥。