iOS如何保证下载资源的可靠性

前言

有时需要在本地存储资源，并且从服务器下载资源，因为涉及到运行期间的安全性，有必要添加校验的逻辑，因此有了本文的一些思考。

ipa包被篡改的情况

首先思考的是ipa包的安全性问题。通过iTunes，我们可以下载ipa并且解压，修改包中的文件，再压缩成ipa包。

• 1、如果开发者A拿到应用P的ipa包，修改其中的任何文件，都会导致签名失效，ipa包无法安装。（签名存放在.app文件的_CodeSignature文件夹）
• 2、如果开发者B拿到应用P的ipa包，安装到自己手机中，再直接修改Bundle/Application 下的配置文件，此时应用P仍旧可以运行。
• 3、如果开发者C拿到应用P的ipa包，修改其中的某些配置文件，用自己的证书重签名并通过其他渠道发布出去，ipa包可以正常安装。

应用在正常使用过程中，app包的文件是无法修改的，只有越狱的机子才会出现情况2；情况3中重签名的ipa包无法上传AppStore。
真机app安装目录是 var/mobile/Containers/Bundle/Application
沙盒目录是 var/mobile/Containers/Data/Application
类似的，模拟的安装目录同样在/Bundle下，沙盒在/Data下；

下载资源的验证

下载的资源存在沙盒目录，在未越狱的情况下，开发者并不能修改其中的文件。但是，下载资源通常使用http进行资源下载，http通过使用代理，可以很方便的修改下载的资源。为了保证下载资源的可靠性，采用了一套基于RSA算法的验证方案，具体的要点有:
1、开发者产生一对密钥：公钥和私钥，私钥保存在配置平台（后台），公钥放到客户端。
2、当文件上传到配置平台后，配置平台对文件进摘要（hash）得到md5str，并私钥对md5str进行签名得到signStr，然后把 文件和signStr下发给客户端。
3、客户端下载文件和signStr，计算文件的摘要（md5）得到md5str，用md5str和公钥验证signStr的有效性。

解释：
非对称加密算法的计算比较复杂 ，所以只对摘要（md5值）进行加密；
具体的流程图如下：

iOS的RSA算法

RSA算法的两种加密方式：

• 公钥加密，私钥解密。（一般用于公钥持有方（客户端）向私钥持有者（后台）发送消息）
• 私钥加密，公钥解密。（一般用于签名和验证，私钥加密相当于签名，公钥解密相当于验证）

苹果提供的Security.framework，有以下四个方法：

• SecKeyEncrypt—encrypts a block of data using the specified key.（使用公钥对数据进行加密）
• SecKeyDecrypt—decrypts a block of data using the specified key. （使用私钥对数据进行解密）
• SecKeyRawSign—signs a block of data using the specified key.（使用私钥对数据签名）
• SecKeyRawVerify—verifies a signature against a block of data and a specified key. （使用公钥对数字签名进行验证）

类比到OpenSSL，其提供了以下四个接口：

int     RSA_public_encrypt(int flen, const unsigned char *from,
                unsigned char *to, RSA *rsa,int padding);
int     RSA_private_encrypt(int flen, const unsigned char *from,
                unsigned char *to, RSA *rsa,int padding);
int     RSA_public_decrypt(int flen, const unsigned char *from,
                unsigned char *to, RSA *rsa,int padding);
int     RSA_private_decrypt(int flen, const unsigned char *from,
                unsigned char *to, RSA *rsa,int padding);

因为RSA算法的计算量较大，一般不会直接使用RSA对数据进行加密，而是对AES的密匙进行加密，再用AES对数据加密。
RSA算法原理 ，这里有一篇详细介绍RSA算法原理的文章。

数字签名的保存

拿到后台下发的签名后，就需要保存签名，可以选择：保存在文件中、保存到NSUserDefault、保存到数据库等。除此之外，是否可以保存在文件属性？
写了一段代码进行测试：

    NSMutableDictionary *changedAttrDict = [[NSMutableDictionary alloc] init];
    [changedAttrDict setObject:@"loying" forKey:NSFileOwnerAccountName];
    [changedAttrDict setObject:@"NSFileGroupOwnerAccountName" forKey:NSFileGroupOwnerAccountName];
    [changedAttrDict setObject:[NSDate dateWithTimeIntervalSinceNow:3600] forKey:NSFileCreationDate];
    
    NSError *error;
    
    BOOL ret = [[NSFileManager defaultManager] setAttributes:changedAttrDict ofItemAtPath:encodedDataPath error:&error];

经过测试，NSFileCreationDate这个属性是可以修改的；
NSFileGroupOwnerAccountName和NSFileOwnerAccountName不能修改（真机为@"mobile"）；模拟器不可以修改两个属性，最大的可能性是因为模拟器运行产生的文件，权限不够修改文件属性；
createDirectoryAtPath:withIntermediateDirectories:attributes:这个方法同样有这个限制。
写入文件属性还有其他的限制，当文件在不同硬盘格式（HFS+ and FAT32）拷贝的时候，文件附带的属性可能会消失。

NSFileProtectionKey 是后台模式下的文件读写

为了开发方便，可以选择保存到NSUserDefault的方式。
新建NSMutableDictionary，用文件作为key，用FileConfig作为value。FileConfig是验证相关的属性封装，便于后续开发。

1、NSUserDefault所有的属性最终会写入Libary/Preference/下的plist文件中，所以NSUserDefault中不能存储敏感信息。

2、如果遇到错误：Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: 'Attempt to insert non-property list object
那是因为NSUserDefault只能存基本类型，如果dict里面存有自定义类型，需要先转成NSData再存储；（plist里面没有结构信息，只有key-value）

总结

任何手段都无法完全防止恶意的攻击，只能提高门槛。

附录

iOS使用Security.framework进行RSA 加密解密签名和验证签名
http://blog.methodname.com/da-zao-yin-xing-ji-jia-mi/