iOS 本地数据安全存储方案探索

更新 - 2020-5-25
单纯的随机数，同时也是伪随机的，可能这个随机因子不那么足够。那么要依赖本机产生一个真随机，可以通过设备运动状态、物理状态垂直位移、水平位移、角度等，转换成一个数值作为随机因子，再与随机数结合，提高随机性。

前言：

一般app都支持本地记录登录状态，并支持离线的情况下加载用户数据，为了满足这样的场景，就需要把相关信息保存到本地。对于iOS持久化方面，无论使用userDefault、plist文件、归档、数据库等存储方式，都需要考虑一个问题，如何安全的存储数据？对于这个问题，可以对数据加密保存，至于选择哪种持久化方式，并不是那么重要。

加密方案

说到对数据进行加密，那么肯定是要有一套安全的加密方案才行。以下是一些方案例子：
A. 一些摘要算法或编码处理。
B. 使用特定的秘钥执行某种对称加密。
C. 使用特定的公私钥执行某种非对称加密。
D. 某种自定义加密算法。
对于A，这只是一种把明文转为非明文的一种方式。摘要算法不可逆，但数据无法还原，不符合需求。编码处理，可以反编码还原明文，实际上数据并没有变得更安全，也是不符合需求。但采用编码的方式，还是比直接使用明文要好那么一点点。
对于B.使用公开的对称算法进行加解密，只要保证秘钥的安全，是可行的。
对于C.同B，但相对于对称加密，非对称加密效率较低，所以在保证秘钥安全的前提下，选择B，而不是选择C。但C的安全系数会比B高。两者都已经满足数据破解的成本超过其获取的价值的要求。
对于D，自定义算法，就要具体分析了， 破解难度因算法本身设计有关，但这个一般都是比较有实力的公司才这么搞吧，但一般都安全性比较高。是最好的方案之一，但其存在一定设计成本和测试成本。

从安全范围的角度去考虑

到了这里，又面临了一个秘钥安全的问题，一般来说，我们可能会把秘钥硬编码到代码中，但我们的二进制文件存在一个字符串常量区，只要这个字符串在代码中被引用了，那么编译器就会把其写进字符串常量区。如果这样，稍微的分析下二进制文件，就可能把秘钥获取。所以秘钥硬编码是比较危险的。面对这个问题，可以通过把秘钥分拆成多个字符串，再通过某些处理生成真正的秘钥，来提高安全性。这里会存在一个更值得思考的问题，为了引出这个问题，先回归到方案的探索。

到目前为止讨论到的都是本地怎么安全保存数据，到如何安全保存秘钥，都是围绕着单体方案去考虑，而没有从整体上去考虑。从安全范围的角度去考虑，如果在每一个客户端都是同样的加密算法，同样的秘钥，那么只要其中一个被破解，整个大厦立马倒塌。

为此，可以给安卓和苹果分别分配不同的秘钥，这样就能把两个平台，这块的安全性隔离。既然有了这样的想法，那么前进一步，如果每个客户端都拥有不同的秘钥，并且是一种随机秘钥（随机安全性更高，当然可能伪随机，虽然伪随机实际上是通过算法来生成的，有规律，但其破解难度很大），那么就能把这块的安全性做到客户端隔离。

最终选择的方案：

使用AES对称加密算法；使用随机算法生成本地秘钥，秘钥中添加时效性信息，并保存到keyChain中。

优点：客户端隔离、对称加解密效率高，随机秘钥破解难度大。
缺点：由于客户端隔离，秘钥都不一样，数据无法统一分析，因此也影响了适用场景。

demo:LocalEncryptDemo