写在前面
近期都在做自动化测试相关的工作，已经蛮久没有正正经经开发iOS了。其实自动化测试相关的还是有蛮多知识或者内容可以拎出来深入分享下的，看我啥时候不懒了再说吧...
为了测全公司所有部门的包，需要在测试前先把他们的包装在自动化测试机上。问题是不同部门的开发者账号可能不是同一个，即使是同一个，不同的包对应的描述文件必定不相同，而我们平台最近又在疯狂加新机，所以就有了这样的问题：
购买新机后，他们要能在新的机器上跑，就必须往账号的设备列表里加设备，然后更新描述文件，然后重新打包，新包才能装在新机上。每个包都得来一遍这个过程，每来一个新机又得重复一遍。这样的效率太低，且会让开发烦躁，而解决问题最好的办法就是重签名。
这篇文章不会介绍如何重签名，因为这样的教程网上已经不计其数了。本文会在介绍iOS签名的基础上，用比较好懂的话来解释加密、数字签名、数字证书原理，再将原理应用到实例中，做更好的理解。
原理
对称加密算法
加密解密是使用同一把钥匙。
比如小明和小红沟通时，使用同一把钥匙A进行加解密。
小明将你好啊用钥匙A加密后生成&^%$，发送给小红，小红用钥匙A进行解密，生成你好啊。
常用的对称加密的算法：
- DES（Data Encryption Standard）：数据加密标准，速度较快，适用于加密大量数据的场合。
- 3DES（Triple DES）：是基于DES，对一块数据用三个不同的密钥进行三次加密，强度更高。
- AES（Advanced Encryption Standard）：高级加密标准，是下一代的加密算法标准，速度快，安全级别高；
非对称加密算法
有一对钥匙，称为公钥和私钥。用其中一把钥匙进行加密，就只要另一把钥匙才能解密，反之也是一样的。公钥是公开出去的，私钥是自己藏着的。
比如小明和小红沟通时，小红生成一对钥匙B，公钥给小明，私钥自己藏着。
小明将你好啊用公钥B加密后生成$%^&，在发送给小红，小红用自己的私钥B解析，生成你好啊。
常用的非对称加密的算法：
- RSA：由 RSA 公司发明，是一个支持变长密钥的公共密钥算法，需要加密的文件块的长度也是可变的；
- DSA（Digital Signature Algorithm）：数字签名算法，是一种标准的 DSS（数字签名标准）；
- ECC（Elliptic Curves Cryptography）：椭圆曲线密码编码学。
摘要算法
摘要算法在加密过程中不需要密钥，且加密后的内容无法解密逆向。它能把任意长度的数据加密成长度固定的字符串。
比如你好啊用摘要算法加密后，变成!@#$。但是再也做不到通过!@#$恢复成你好啊。
著名的摘要算法：
- MD5算法
- SHA-1算法
数字签名
用摘要算法对一段数据进行加密，再使用非对称加密的算法中的私钥对摘要算法加密后的内容二次加密，就能生成数字签名。
嗯，听起来比较绕。还是举个例子。
比如你好啊用摘要算法加密后，变成乱码1。再用私钥进行加密，生成乱码2。最后的乱码2就是签名。
根据上面摘要算法的说明，摘要算法加密后的内容无法解密逆向。因此签名乱码2最多只能通过公钥解密成乱码1，而无法恢复你好啊。
那这玩意有啥用呢？其实这个签名是用来验证原数据是否被篡改的。
一般，数据发送方会把你好啊和这个签名乱码2一起发出去。接受方在收到后，按照前面写的顺序，先将乱码2通过公钥解密成乱码1，然后再用摘要算法加密原数据你好啊，也生成乱码1。两个比对后，就能知道数据没有被篡改了。
总之：
数据 + 摘要算法 = 摘要
摘要 + 私钥 = 数字签名
（数字签名就是用来验证数据是否被篡改的）
数字证书
小明给小红发送你好啊和乱码2，理论上说，小红就能安全无误的收到数据了。但是光有数字签名就安全了吗？其实不是的。
有一个黑客小黑，他先把小红电脑里的小明的公钥给改成自己的 ，就能做到神不知鬼不觉的假装自己是小明了。
小黑发送你坏啊，用摘要算法加密生成乱码3，再用自己的私钥加密生成乱码4。然后将你坏啊和乱码4一同发给小红。小红收到后，由于公钥已经被替换，还是能将解密后的乱码3对应上，从而误会小明。
这里，有一个问题就暴露出来了，如何能证明小红手里的公钥是小明生成的呢？数字证书的作用就显现出来了。
简单的说，数字证书类似一个身份证，颁发数字证书的是中间人CA机构，类似公安局。那么为啥数字证书就能证明这个里面的公钥是小明的呢？
首先，来看看数字证书是咋实现的。
小明将自己的公钥发送给CA，CA会将公钥、签发者ID、Subject、有效期等数据塞进一个文件F里面，内容都是明文。然后使用摘要算法进行计算，生成的结果为H。再用CA的私钥加密，生成 签名S。最后将F和S放一起，就是数字证书Z了。
这里的步骤和上文的签名步骤类似。
然后再来看看为啥能证明这证书里的公钥就是小明的呢？
当小明将要发送的数据和这个数字证书Z一同发给小红，小红可以从证书里面拿到一个明文F和签名S，由于这个证书是权威机构发布的，因此小红的电脑里存在CA的公钥，再使用CA公钥即可将签名S解码，拿到H'。再将明文F做摘要算法加密拿到H，只需要比较H和H'是否一致即可。如果一致就确认拿到可靠的小明的公钥了。
这里的步骤又和上文的签名步骤类似。
总之：
公钥 + 其他数据 = 完整数据
完整数据 + 摘要算法 = 签名
完整数据 + 签名 = 数字证书
（数字证书就是用来验证数据来源是否可靠的）
小结
最后小明和小红的通信就会变成这样：
小明先从CA那边拿到了认证过的数字证书Z。再将你好啊通过摘要算法生成乱码1，再通过私钥加密获得签名乱码2。最后把你好啊 + 乱码2 + 数字证书Z 一同发给小红。
小红先通过数字证书Z获得小明公钥，确认公钥正常后，将签名乱码2解码，可以获得乱码1，再用摘要算法将你好啊也加密获得乱码1'，比对即可知道数据是否被篡改。
经过这么一个流程下来，小红就能确定你好啊一定是小明发的。
这时候小黑还能干坏事吗？
小黑拿到了小明发给小红的数据，里面有你好啊 + 乱码2 + 数字证书Z。
小黑想先从 数字证书Z下手，他通过电脑里的CA公钥，拿到了小明的公钥，将自己的公钥塞进去，然后发现他不能再生成签名了，因为他没有CA的私钥。因此他做不到替换小明公钥。即使强行生成一个证书，小红的浏览器也能一眼认出这个证书是不受认证的。
那么能不能改下内容呢？他用你坏啊通过摘要算法生成乱码1，由于没有小明私钥，只能用自己的私钥生成签名乱码2。再将你坏啊 + 乱码2（假的） + 数字证书Z给小红。
小红先通过数字证书Z获得小明公钥，确认公钥正常后，去解码签名乱码2（假的），生成乱码1（假的），再用摘要算法将你坏啊生成乱码1（假的）'，比对后不一致，同样失败。
因此可以确定，小黑无法再篡改小明的数据了。
但是这边还是有问题的，小明的数据是明文传输的。接下来看看HTTPS是如何解决这些问题的。
应用
HTTPS
建立连接以及通讯过程：
- 客户端向服务器发送通信请求
- 服务器向客户端发送CA授权的证书
- 客户端收到证书后，验证证书有效性。如果有效，会生成一个随机字符给服务器，让服务器加密
- 服务器用私钥加密完返回客户端
- 客户端解密服务器返回的数据，如果和当初发过去的一致，说明对方确实是私钥持有者。然后客户端生成对称秘钥，用服务器公钥进行加密，随后发送服务器。
这段流程结束后，服务器和客户端就能用客户端定制的秘钥进行数据传输。
可以看到，第2、3步其实就是对数字证书的应用。
iOS签名
接下来会解释iOS签名的原理已经app安装时的原理，如果你对iOS开发证书、描述文件申请流程不是很了解的话，建议先去了解后再来看。
申请iOS开发者证书的流程
- 我们在钥匙串中可以申请到本台电脑的证书。其实证书里包含着我们电脑的公钥。这一步和小明将自己的公钥发给CA是一致的。
- 在开发者官网申请开发者证书时，我们将电脑的证书上传上去，苹果用私钥进行签名，然后获得开发者证书。其实，开发者证书和CA给小明的数字证书是一样的。
- 由于iOS开发真机调试过程中，涉及到测试的app、环境权限和可测试的设备，因此苹果将这些配置包括开发者证书放一起，用私钥签名，然后将原数据和签名放一起作为描述文件。
- 我们将开发者证书和描述文件下载下来，双击安装到描述文件夹中。Xcode编译前，需要选中正确的开发者账号和描述文件。
- 打包时，Xcode会使用本地私钥签名app，同时会将描述文件和开发者证书打包进app包中。（这一步的具体流程不是很确定，大致是，先用摘要算法对app里面的文件进行加密，会生成一个摘要文件，然后再用私钥进行签名，签名后的文件会放在app的可执行文件中（不确定！！！））
- 手机安装包时，会用手机内部的苹果公钥解密证书，拿到电脑的公钥，同时也会验证一遍描述文件。这一步和小红拿到小明的证书很像。
- 解密得到电脑公钥后，验证证书和描述文件。如果都符合条件，验证app签名，而后正常安装。
最后
以上就是数字签名、证书原理及应用。如果哪里有问题请指出谢谢。
嗨，写一篇文章可真是太累了，且看且珍惜 _(:з」∠) _
参考：
