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

作者: 落影loyinglin | 来源:发表于2017-07-08 20:08 被阅读855次

    前言

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

    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这个属性是可以修改的;
    NSFileGroupOwnerAccountNameNSFileOwnerAccountName不能修改(真机为@"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/

    相关文章

      网友评论

        本文标题:iOS如何保证下载资源的可靠性

        本文链接:https://www.haomeiwen.com/subject/tdbfhxtx.html