iOS的双向验证机制 + 各种加密算法

代码签名

hash算法：密码学中的基础算法，常用的有MD5和SHA，最终要的是就是不可逆和无冲突，所
以对代码或者数字进行hash可以保证代码或者数字的唯一性以及不可破解性

RSA签名：用私钥负责签名，公钥负责验证

RSA加密：公钥负责加密，私钥负责解密

记忆方法：既然是加密，肯定是不希望别人知道我的消息，只有我才能解密，所以才能得出公钥负责加密，私钥负责解密；同理，既然是签名，肯定不希望有人冒充我的消息，只有我才能发布这个签名，所以可以得出私钥负责签名，公钥负责验证；

数字签名：将可执行文件或者脚本进行数字签名，其实就是讲脚本或者可执行文件进行hash算法，得出32位的值，对该值进行RSA私钥签名。

代码签名：将代码通过hash得出32位的hash值，并将该值进行RSA私钥签名。

代码签名过程

iOS开发阶段的苹果双向验证原理

简单的代码签名：如果要验证，其实最简单的方式就是通过苹果官方生成非对称的一对公私

钥，公钥由iOS系统保存，私钥由苹果后台保存，苹果后台用私钥对APP进行签名，iOS系统

下载APP后，用公钥验证这个签名，若签名正确，是这个APP就是苹果后台验证的。

新的需求：

• 安装包不需要上传到AppStore，可以直接安装在手机上
• 苹果为保证系统的安全性，又必须对安装的APP有绝对的控制权（不能滥用、允许才能安装）

双重签名：

如下图所示：

双重签名

1、在mac电脑上自有的公钥M(也就是CSR文件)上传到苹果服务器，在苹果服务器中会生成一个证书，这个证书中包含公钥M、公钥M的hash值，这两者最后通过私钥A签名生成一个证书

2、在生成的APP包中，其实携带了很多的信息，包括代码可执行文件、app通过电脑的私钥M(其实是p12文件)签名，以及从苹果服务器获取的证书

3、APP安装到手机中时候，通过手机中带的公钥A对APP中的证书进行验证，并提取出公钥M

4、公钥M在对APP的签名信息进行验证，如果成功那么表示APP是授信的，否则失败

这样的话很容易出现滥用的问题，所以苹果又增加了两个限制

• 限制苹果后台注册过的设备才能安装
• 限制签名只能针对某一个具体的APP
  并且想控制App里面的iCloud、Push等权限，将这些都放在了Provisioning Profile（描述文件）中，并且将我们在苹果服务器中生成的证书也放到了里边
  

  描述文件
  
  这样，其实服务器返回的是一个描述文件，然后在mac电脑上将当前的描述文件放到了APP包中。

在当前的真机调试项目中其实也会有一个描述文件，并且mac电脑的钥匙串中，生成的证书其实都会对应一个mac电脑的私钥，这个私钥和我们生成证书时上传给苹果服务器的公钥是一对，其实私钥就是我们的p12文件

mac电脑私钥

双向签名

不同加密算法

• 哈希（散列）函数
  • MD5
  • SHA1/256/512
  • HMAC
• 对称加密
  • DES
  • 2DES
  • AES(高级密码标准，钥匙串访问)
• 非对称加密

哈希算法

算法的特点

• 算法公开
• 对相同数据运算，得到的结果是一样的
• 对不同数据运算，如MD5得到的结果默认是128位，32个字符（换成了16进制）
• 没法逆运算
• 信息摘要，信息“指纹”是用来做数据识别的

算法的用途：

• 密码加密：
  • MD5加密密码
    • 如果用RSA加密的隐患，如果服务器将密码解密，然后会将用户密码明文存储到数据库，违背了网络的原则。
      网络的两个原则：网络上不允许明文传递用户隐私信息|本地不允许明文保存用户隐私信息。
    • 可以用MD5加密密码，将MD5存放到数据库，所以不存在找回密码功能。
      但是，现在大部分的hash加密后的值可以在某些网站直接查询到对应的原始值，所以直接hash其实也是不安全的（比如网站cmd5）
    • 加盐，通过在密码后边加足够复杂的一个静态字符串（所以是很难进行反编译的），然后将结果MD5，这个时候是不可能查询到的。
      加盐的弊端，加盐是固定的，写死在程序，一旦泄露还是不安全的（比如程序员人为泄露），或者暴力破解都能够破解

加盐

• HMAC方案
  • 注意这是一个加密的方案
  • 涉及到的api - CCHmac，将加密方案和key以及需要加密的内容传进来
  • 使用一个密钥（key）加密，并且做两次散列（HASH）；在实际开发中，密钥（key）来自服务器（动态的，类似动态盐）；一个账号对应一个key
  • 注册的时候，或者换设备登录登录成功之后的时候服务器将key发送给客户端，并保存到手机中的钥匙串访问中；或者当原来设备允许的时候，新设备才能接受到服务器的key；并且服务器和客户端协商逻辑之后可以定期更换key
  • 虽然把密码加密了，但是如果拿到发送给服务器的散列值别拿到之后，完全可以模拟我们的登录状态，那么我们如何避免这种？
    • 那么我们需要保证发给服务器的东西是不同的，可以利用时间戳。
    • 比如我们在散列之后（服务器也是存的当前的散列值），可以加一个服务器返回的时间戳（服务器的本地时间），重新进行hash，并传递给服务器，那么服务器收到之后，服务器将本地保存的散列值加上当前的时间戳重新进行散列，同时和客户端的散列值进行比较，如果一致，那么验证成功
    • 如果不通过，那么服务器继续将服务器的本地时间的上一分钟和散列值进行hash，重新和客户端比较是否一致
    • 这种时间+散列值的拼接规则是我们自定义的，可以继续添加其他的东西，再进行散列也行，反正这个规则黑客是不知道的

    • 这样我们就保证了每次上传给服务器的值不一样，黑客没办法截取
      

      HMAC方案

• 拆词搜索，搜索引擎
  • 将每个词进行MD5，然后按位相加，得到的权重值和我们数据库中的权重值进行比对，找到答案
• 版权
  • 腾讯课堂将我们录制的视频进行hash，防止其他的非正版上传到腾讯课堂，非正版的判断就是hash的比较
  • 百度云的文件上传秒传就是判断的hash
• 数字签名
  • 传递数据的时候验证数据的完整性，即hash
  • 为了保证中间传输时候hash值没有被改过，所以我们可以用RSA私钥对hash值进行签名，接收到数据之后，我们可以用公钥进行解密，数字签名就是原始数据进行hash+RSA签名

对称加密

对称加密是可逆的

分类

• DES ，数据加密标准（用的少，因为强度不够）
• 3DES，使用3个秘钥，对相同的数据执行3次加密，强度增强
• AES，高级密码标准

应用模式

• ECB，电子密码本加密。每一块数据，独立加密，就是通常理解的加密
• CBC，链接模式，使用一个秘钥和一个初始化向量对数据执行加密，加密是上下文相关的，是分组的，如果一个分组丢失，全部作废，所以保证密文的完整性

方法

• 都用到了key，根据是否传入iv进行判断是ECB还是CBC

  
  
  

  CCCrypt开始加密解密

• 苹果常用的加密解密的算法都在库里

• 可以用DES+CBC/ECB或者AES+CBC/ECB进行不同的加密，其实苹果还有很多对称加密方式，常用的及时这几种方式

隐患

在逆向过程中其实主要是分析的函数的调用，如果在函数调用（比如调用CCCrypt）过程中我们把隐私的数据传递给了函数，那么我们的隐私就会暴露，如何避免这个隐患那？

• 我们需要在函数内部对某些敏感的信息加一些自己的逻辑（比如异或），进行这种加密后再进行函数赋值，这样就保护了我们的敏感信息。

重点总结

HASH

• 特点：不可逆、数据指纹
• 运用：密码、MD5+盐、HMAC、时间戳、数字签名（HASH+RSA）

对称：DES、3DES、AES

• 明文（秘钥）加密密文
• 密文（秘钥）解密明文
• 加密方案：ecb&cbc（iv加密算法都喜欢结合几何）
• 代码：CCCrypt
• 安全问题：CCCrypt函数 数据加密之前，对数据本身做一个处理