iOS App场景中的安全密钥，安全吗? [英] Secure keys in iOS App scenario, is it safe?
问题描述
我试图隐藏我在我的一个应用中使用的 2 个秘密.
据我所知，钥匙串是个好地方，但在提交应用程序之前我无法添加它们.
我想到了这个场景 -
- 在我的应用程序的 CoreData 数据库中预先播种秘密，方法是将它们传播到其他实体中以隐藏它们.(我在该应用中已经有一个种子数据库).
- 当应用首次启动时，生成密钥并将其移动到钥匙串中.
- 从 CoreData 中删除记录.
这是否安全，或者黑客可以看到这种情况并获得这些密钥吗?
*第三次编辑**很抱歉没有从头开始解释这个场景 - 该应用程序有很多级别，每个级别都包含文件(音频、视频、图像).用户可以购买一个级别 (IAP)，购买完成后我需要将文件下载到他的设备上.
对于 iOS6，文件使用 Apple 新的托管内容"功能存储.对于 iOS5，文件存储在 amazon S3 中.
所以在整个过程中，我有 2 个键:1. IAP 密钥，用于在 Apple IAP 上验证购买.2. S3 密钥，用于 iOS5 用户从 S3 获取文件:
NSString *secretAccessKey = @"xxxxxxxxx";NSString *accessKey = @"xxxxxxxxx";我需要保护这些密钥吗?恐怕人们无需购买关卡就可以从 S3 获取文件.或者，黑客将能够构建一个预下载所有级别的黑客版本.
让我试着把你的问题分解成多个子问题/假设:
假设:
a) 钥匙扣是安全的地方
实际上，它并不那么安全.如果您的应用程序安装在越狱设备上，黑客将能够从钥匙串中获取您的密钥
问题:
a) 有没有办法将一些密钥放入应用程序(从 AppStore 提供的二进制文件)中并完全安全?
简短的回答是否定的.只要您的二进制文件中有内容，就可以对其进行逆向工程.
b) 混淆会有所帮助吗?
是的.这将增加黑客弄清楚的时间.如果您在应用中拥有的密钥的成本"低于在逆向工程上花费的时间 - 一般来说，您很好.
但是，在大多数情况下，通过默默无闻来确保安全是不好的做法，它让您感觉自己很安全，但实际上并非如此.
因此，这可能是一种安全措施，但您还需要采取其他安全措施.
c) 在这种情况下我该怎么办?*
如果不了解您正在尝试做什么的背景，很难为您提供好的解决方案.
例如，为什么每个人都应该访问同一个 Amazon S3?他们是否需要只读或写入(如 Kendall Helmstetter Gein 所指出的).
我相信最安全的场景之一应该是这样的:
- 您的应用程序应受密码保护
- 第一次进入应用程序时，它会要求用户向服务器进行身份验证(输入用户名、密码)
- 这会针对您的服务器或其他身份验证提供商(例如 Google)进行身份验证
- 服务器向设备发送一些身份验证令牌(通常是某种类型的 cookie).
- 您根据应用程序密码的哈希值加密此令牌，并以这种形式将其保存在钥匙串中
- 现在您可以执行以下两项操作之一:
- 将特定密钥从服务器移交给客户端(因此每个客户端都将拥有自己的密钥)并使用您的应用程序密码的散列对其进行加密
- 在服务器上使用 S3 处理所有操作(并要求客户端发送)
这样您就可以抵御多种可能的攻击.</p>
c) Whoooa.... 我不打算实施你刚刚写的所有这些东西，因为这将花费我几个月的时间.有没有更简单的?
我认为这会很有用，如果您每个客户端有一组密钥.
如果这太多了，那么请从服务器下载加密密钥并将它们以加密形式保存在设备上，并将解密密钥硬编码到您的应用程序中.我会说它是微创的，至少你的二进制文件中没有密钥.
附言肯德尔和罗布都是对的.
更新 1(基于新信息)
首先，你有没有看到在应用购买编程指南中.
Server Product Model 下有很好的绘图.此模型可防止未购买新关卡的人.您的应用程序中不会嵌入亚马逊密钥，您的服务器端将在收到购买收据时移交级别.
没有完美的解决方案可以防止有人购买了内容(并决定从您的应用程序中窃取)，因为最终您的应用程序会将内容下载到设备上，并且需要明文(未加密形式)在某个时间点.
如果您真的很担心这种情况，我建议您加密您的所有资产，并将其以加密形式从服务器与加密密钥一起移交.应为每个客户端生成加密密钥，并使用它对资产进行加密.
这不会阻止任何高级黑客，但至少可以防止有人使用 iExplorer 并且只是复制文件(因为它们将被加密).
更新 2
关于更新 1 的另一件事.您应该存储未加密的文件并将加密密钥存储在某处(例如在钥匙串中).
如果您的游戏需要互联网连接，最好不要在设备上存储加密密钥.您可以在每次应用启动时从服务器获取它.
I am trying to hide 2 secrets that I am using in one of my apps.
As I understand the keychain is a good place but I can not add them before I submit the app.
I thought about this scenario -
- Pre seed the secrets in my app's CoreData Database by spreading them in other entities to obscure them. (I already have a seed DB in that app).
- As the app launches for the first time, generate and move the keys to the keychain.
- Delete the records from CoreData.
Is that safe or can the hacker see this happening and get those keys?
*THIRD EDIT** Sorry for not explaining this scenario from the beginning - The App has many levels, each level contains files (audio, video, images). The user can purchase a level (IAP) and after the purchase is completed I need to download the files to his device.
For iOS6 the files are stored with Apple new "Hosted Content" feature. For iOS5 the files are stored in amazon S3.
So in all this process I have 2 keys: 1. IAP key, for verifying the purchase at Apple IAP. 2. S3 keys, for getting the files from S3 for iOS5 users:
NSString *secretAccessKey = @"xxxxxxxxx";
NSString *accessKey = @"xxxxxxxxx";
Do I need to protect those keys at all? I am afraid that people will be able to get the files from S3 with out purchasing the levels. Or that hackers will be able to build a hacked version with all the levels pre-downloaded inside.
Let me try to break down your question to multiple subquestions/assumption:
Assumptions:
a) Keychain is safe place
Actually, it's not that safe. If your application is installed on jailbroked device, a hacker will be able to get your keys from the keychain
Questions:
a) Is there a way to put some key into an app (binary which is delivered form AppStore) and be completely secure?
Short answer is NO. As soon as there is something in your binary, it could be reverse engineered.
b) Will obfuscation help?
Yes. It will increase time for a hacker to figure it out. If the keys which you have in app will "cost" less than a time spend on reverse engineering - generally speaking, you are good.
However, in most cases, security through obscurity is bad practice, It gives you a feeling that you are secure, but you aren't.
So, this could be one of security measures, but you need to have other security measures in place too.
c) What should I do in such case?*
It's hard to give you a good solution without knowing background what you are trying to do.
As example, why everybody should have access to the same Amazon S3? Do they need to read-only or write (as pointed out by Kendall Helmstetter Gein).
I believe one of the most secure scenarios would be something like that:
- Your application should be passcode protected
- First time you enter your application it requests a user to authenticate (enter his username, password) to the server
- This authenticates against your server or other authentication provider (e.g. Google)
- The server sends some authentication token to a device (quite often it's some type of cookie).
- You encrypt this token based on hash of your application passcode and save it in keychain in this form
- And now you can do one of two things:
- hand over specific keys from the server to the client (so each client will have their own keys) and encrypt them with the hash of your application passcode
- handle all operation with S3 on the server (and require client to send)
This way your protect from multiple possible attacks.
c) Whoooa.... I don't plan to implement all of this stuff which you just wrote, because it will take me months. Is there anything simpler?
I think it would be useful, if you have one set of keys per client.
If even this is too much then download encrypted keys from the server and save them in encrypted form on the device and have decryption key hardcoded into your app. I would say it's minimally invasive and at least your binary doesn't have keys in it.
P.S. Both Kendall and Rob are right.
Update 1 (based on new info)
First of all, have you seen in app purchase programming guide.
There is very good drawing under Server Product Model. This model protects against somebody who didn't buy new levels. There will be no amazon keys embedded in your application and your server side will hand over levels when it will receive receipt of purchase.
There is no perfect solution to protect against somebody who purchased the content (and decided to rip it off from your application), because at the end of days your application will have the content downloaded to a device and will need it in plain (unencrypted form) at some point of time.
If you are really concerned about this case, I would recommend to encrypt all your assets and hand over it in encrypted form from the server together with encryption key. Encryption key should be generated per client and asset should be encrypted using it.
This won't stop any advanced hacker, but at least it will protect from somebody using iExplorer and just copying files (since they will be encrypted).
Update 2
One more thing regarding update 1. You should store files unencrypted and store encryption key somewhere (e.g. in keychain).
In case your game requires internet connection, the best idea is to not store encryption key on the device at all. You can get it from the server each time when your app is started.
这篇关于iOS App场景中的安全密钥，安全吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
