iOS 签名机制
前言
学习iOS签名机制，可参考如下学习路线：
加密解密(对称DES 3DES AES、非对称RSA)--->单向散列函数(MD4、MD5、SHA1-3)--->数字签名--->证书--->签名机制
一、加密解密
1.1 对称和非对称
为了防止传输信息被窃听，需要对传输信息进行加解密。根据密钥的使用方法，可以将密码分为 2 种，即对称密码和非对称密码(也称公钥密码)。对称密码中使用的加密和解密密钥相同，非对称密码中使用的密钥不同。
对称密码算法有 DES、3DES、AES 等。DES 是一种将 64bit 明文加密成 64bit 密文的对称密码算法，密钥长度是 56bit 。由于 DES 每次只能加密 64bit 的数据，遇到比较大的数据，需要对DES加密进行迭代（反复），目前已经可以在短时间内被破解，所以不建议使用 DES；3DES是将DES重复 3 次所得到的一种密码算法，也叫做 3 重 DES，目前还被一些银行等机构使用，但处理速度不高，安全性逐渐暴露出问题；AES 的密钥长度有 128、192、256bit 三种，目前 AES ，已经逐步取代 DES、3DES，成为首选的对称密码算法。一般来说，我们也不应该去使用任何自制的密码算法，而是应该使用 AES，它经过了全世界密码学家所进行的高品质验证工作。
非对称密码算法中，目前使用最广泛的公钥密码算法是RSA。
1.2 如何传输密钥？
对称加密体系中，密钥不能直接传输，否则可能被截取，截获者也能破解密文。有以下几种密钥传输方式：
- 1、事先共享密钥：即通过非通讯手段，私下直接给出密钥。
- 2、密钥分配中心：所有密钥有分配中心管理，分配中心通过特殊安全手段下发。
- 3、借助非对称密码体系：由消息的接收者，生成一对公钥、私钥，将公钥对外公开发给消息的发送者，消息的发送者使用公钥加密消息，接受者使用私钥解密。整个过程只有消息接收者具有私钥，其他任何人没有私钥不具备解密能力。
1.3 混合密码系统（Hybrid Crypto System）
对称密码不能很好地解决密钥配送问题，但是加解密速度快；非对称密码加密解密速度比较慢，但是能很好的解决密钥配送问题。所以采取对称密码和公钥密码的优势相结合的方法（即混合密码系统），可以很好的解决对称密码密钥配送问题以及加解密速度慢的问题。包括 https 中也是采用类似的混合密码系统，https 中的服务端相当于消息接收者，客服端相当于消息发送者。具体步骤如下：
加密步骤：
- 1、接收者生成私钥和公钥(非对称密码体系)，并将公钥发给消息发送者；
- 2、发送者生成会话密钥(对称密码体系)，使用会话密钥加密消息，使用公钥加密会话密钥；
- 3、发送者将加密消息以及机密会话密钥一并发给消息接收者；
解密步骤：
- 1、消息接收者用私钥解密出会话密钥；
- 2、再用会话密钥解密出消息；
二、单向散列函数
2.1 单向散列函数特点
单向散列函数又被称为消息摘要函数(哈希函数)，具备以下特点：
- 可以根据根据消息内容计算出固定长度散列值。散列值的长度和消息的长度无关，无论消息是1bit、10M、100G，单向散列函数都会计算出固定长度的散列值；
- 计算速度快，能快速计算出散列值，消息不同，散列值也不同；
- 具备单向性，即可以根据消息计算出散列值，但是根据散列值无法计算出消息；
2.2 常见单向散列函数
- MD4、MD5：MD就是Message Digest的缩写，产生128bit 的散列值，目前已经不安全。Mac 终端上默认可以使用
md5 文件名命令获取散列值。 - SHA-1：产生160bit的散列值，目前已经不安全。
- SHA-2：SHA-256、SHA-384、SHA-512，散列值长度分别是 256bit、384bit、512bit。
- SHA-3：全新标准，目前还在研发中。
2.3 单向散列函数的应用场景
- 1、单向散列函数可以监测文件是否被篡改，文件被篡改后的散列值和篡改前的散列值如果不同，则说明文件被篡改过。
-
2、用户密码加密，一般不会将用户密码明文传给服务器保存到服务器对应的数据库中，如果后端数据库被攻破，成千上百的用户账号信息直接将被泄露。所以通常做法是获取密码散列值传给后端，这样服务端也不知道用户密码是什么，所以一般用户忘记密码后就无法找回，只能通过重置密码解决。如果一个平台可以找回密码，说明该平台是不安全的。另外，为了防止用户密码相同或过于简单，增加安全性可以采取先加盐再获取散列值的策略。
用户密码散列值
三、数字签名
3.1 数字签名过程
消息接收者可以借助数字签名的方式来识别消息是否被篡改、保证消息发送者无法抵赖消息。数字签名，其实就是将公钥密码反过来使用。在非对称密码体系中，任何人都可以使用公钥进行加密，只有消息接收者才拥有私钥解密消息；在数字签名中，任何人都可以使用公钥验证签名，只有消息发送者才能拥有私钥，并借助私钥签名。
上图可以看出签名的制作过程，将消息生成对应的散列值，然后消息发送者使用私钥加密消息散列值。发送者会将加密消息和加密的签名一起发送个消息接收者。消息接收者接受到消息后，借助消息发送者的公钥解密消息散列值，同时再用自己的公钥解密消息并生成另一个消息散列值，比较两个散列值，若一样则说明消息没有被篡改，否则消息说明消息被篡改。
3.2 小结
数字签名的作用不是为了保证机密性，仅仅是为了能够识别内容有没有被篡改以及防止消息发送人否认。数字签名其实就是将公钥密码反过来使用。数字签名中用私钥加密，公钥解密；非对称密码中用公钥加密，私钥解密。
四、证书
4.1 证书的作用
如果出现中间人攻击，中间人冒充消息接收者，中间人自己生成公钥和私钥，并将自己的公钥发给消息接收者。所以如果想防止中间人攻击，消息发送者必须确保拿到公钥的合法性。通过证书相关手段可以确保公钥的合法性，消息发送者通常要通过权威机构获取公钥。
证书是由权威机构认证的。密码学中的证书，全称叫公钥证书（Public-key Certificate，PKC），和现实生活中的毕业证、驾驶证等类似，里面有个人信息、此人的公钥以及权威认证机构（Certificate Authority，CA）对公钥施加的数字签名三个部分组成。CA 是指能够认定“公钥确实属于此人”并能够生成数字签名的个人或者组织。
4.2 证书的利用
从上图中可以看出消息接收者需要生成密钥对，并将自己的公钥给权威认证机构，权威机构会用自己私钥对消息接收者的公钥施加数字签名，制作成证书并保存在权威机构的仓库中。于此同时，消息发送者可以通过正规渠道获取拿到权威机构公钥(一般是提前内置的，如 iPhone 设备中包含 apple 的公钥)，并能下载证书，此时可以用权威机构的公钥验证证书的合法性。映射的现实生活相当于：教育机构工作人员从教育机构获取到一个可以用于检测任意学历证书(证书)真伪的工具(权威机构公钥)。
五、iOS 签名机制
5.1 iOS 签名机制作用
iOS签名机制主要是保证安装到用户手机上的APP都是经过Apple 官方允许的，如果篡改了 App 本身的源码或资源文件，签名值将无法对应上，便无法安装。实际开发过程中不管是真机调试，还是发布APP，开发者都需要经过一系列复杂的步骤，这些步骤都是为了防止随意安装 App。
利用签名机制，也可以在原有项目中实现App自签名功能代码，对资源文件、源码、证书签名，在App 启动时做签名校验，当有人改动资源文件，签名校验就会失败，则直接调用 exit 退出 App，为了防止逆向可将该功能相关代码通过 C 语言形式实现或者整个应用实现代码混淆。网上有不少介绍 App 自签名的实现代码，但是笔者认为自签名功能很鸡肋，因为逆向的本质是通过插件的形式更改内存中的代码，一般并非是直接更改源码或资源文件。
5.2 iOS 签名机制作流程
有了上述知识作为铺垫，签名机制流程就很好理解了，如下图：
Mac 设备具有生成公钥和私钥的能力，平时操作钥匙串工具
钥匙串访问-->证书助理-->从证书颁发机构请求证书主要目的就是为了生成 Mac 公私钥，之后再将公钥上传到苹果后台，用于制作证书。Apple 本身可以认为是权威机构，Apple 后台可以生成私钥，iOS 设备中有公钥。
- 1、当运行
CMD + R的时候，此时会进行代码签名，即拿 Mac 本地的私钥对应用签名生成 ipa 安装包，ipa 安装包中主要包含应用、签名、资源文件等。 - 2、将 Mac 本地生成的公钥上传到 Apple 后台，Apple 后台用自己的私钥生成证书文件，证书中包含 Mac 公钥以及签名。
- 3、选择相应的证书、devices、app id、entitlements(权限)，然后苹果后台用自己的私钥将这些内容签名，并生成描述文件。
- 4、iOS 设备中包含苹果的公钥，使用公钥验证签名文件，如果验证通过则可以获取证书。于此同时，还会比对相应的devices、app id、entitlements(权限)是否一致。
- 5、使用iOS 设备中的苹果公钥验证证书签名，如果签名验证成功则会获取到 Mac 公钥。
- 6、使用 Mac 公钥验证 ipa 安装包签名，如果验证成功则直接安转应用。
5.3 线上 App 签名机制
如果 APP 是从 AppStore 下载安装的，会发现里面是没有 mobileprovision 文件。线上 app 的验证流程简单很多，应用上传到 Apple 后台，Apple 会用自己的私钥进行签名，下载应用的设备中包含 Apple 公钥，应用下载完成，直接可以用设备中的 Apple 公钥进行验证。流程如下：
