动态生成解密密钥而不是硬编码字符串文字？ （Objective-C / iPhone）
我的 iPhone 应用程序正在使用加密资产。解密密钥需要进行硬编码，但我试图避免使用字符串文字。有没有一个好的标准算法来完成这类事情？
假设我的关键是：
abcdef01-2345-6789-abcd-ef0123456789
与其这样做：
NSString *key = @"abcdef01-2345-6789-abcd-ef0123456789";
我宁愿做这样的事情：
-(NSString *)key {
//TODO: generate abcdef01-2345-6789-abcd-ef0123456789 dynamically
return generatedKey;
}
想法？
My iPhone app is using encrypted assets. The decryption key will need to be hardcoded but I'm trying to avoid using a string literal. Is there a good standard algorithm to do this sort of thing?
Assume my key is:
abcdef01-2345-6789-abcd-ef0123456789
Rather than do this:
NSString *key = @"abcdef01-2345-6789-abcd-ef0123456789";
I rather do something like this:
-(NSString *)key {
//TODO: generate abcdef01-2345-6789-abcd-ef0123456789 dynamically
return generatedKey;
}
Thoughts?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
坏主意。原因与硬编码密码相同。您可以从多个位置对最终密码进行混淆和异或运算，但有能力的黑客会监视设备的内存，并在足够的时间内对任何巧妙的协议进行逆向工程。如果他只是偷了手机，他就拥有了。或者可以发起侧通道攻击并测量执行时间或功耗，因此猜测密钥就像电影中的保险箱窃贼一样 - 一点一点地摆弄密钥并“监听”它们是否更接近目标。
因此，您可以使其变得更加困难，但如果没有硬件支持的安全存储机制（这将保护内存访问并混淆功耗、执行时间等，就像智能卡或硬件安全模块一样），就没有机会确保其安全。
密码需要保留带外信息，与设备分开。理想情况下，用户每次需要时都会输入它。当然，从用户的角度来看，这很乏味——但至少它是安全的。
Bad idea. The reason is the same as for hard-coded passwords. You can obfuscate and XOR the final password together from several places, but a capable hacker will monitor the memory of the device and reverse engineer any clever protocol with enough time. That he has if he simply steals the phone. Or could mount side-channel attacks and measure execution time or power consumption, therefore guessing the key much like safecrackers in movies would - fiddling with keys bit for bit and "listening" if they are any closer to their goal.
So you can make it harder, but without a hardware-supported secure storage mechanism (that would protect memory access and obfuscate power consumption, execution time etc. much like smart cards or hardware security modules do) there's no chance to make this secure.
The password needs to stay out-of-band information, separated from the device. Ideally, the user would enter it each time it is needed. Of course that is tedious from a user perspective - but at least it's secure.
一种可能的方法是使用两个或三个字节数组，使得 key[i] = ary1[i] ^ ary2[i] ^ ary3[i]。您应该在三个不同的位置初始化它们。您也不必在同一个循环中进行异或，可以先对两个进行异或，然后再对第三个进行异或。这取决于你想让攻击者感到多么尴尬。
它不会完全安全，但会阻止偶然的攻击者。对于非休闲攻击者，您将需要一位加密专家，但我不是。您可以为顾问支付多少费用取决于数据被盗后您将花费多少费用。
哦，还有永远不要调用你的密钥
key[]，那只是自找麻烦。 :)One possible method is to use two or three byte arrays such that
key[i] = ary1[i] ^ ary2[i] ^ ary3[i]. You should initialise them in three separate places. You don't have to XOR then in the same loop either, two can be XOR'ed first and the third later. It depends how awkward you want to make it for any attacker.It won't be perfectly secure but it will deter a casual attacker. For a non-casual attacker you will need a crypto expert, which I am not. How much you can pay for a consultant will depend on how much it will cost you if data is stolen.
Oh, and never call your key
key[], that is just asking for trouble. :)