前言
常用的加密方式
目前主流的加密方式有对称密钥加密和非对称密钥加密。
对称密钥加密
维基百科中对对称密钥加密的定义如下：
非对称密钥加密
MD5加密
MD5全称MD5消息摘要算法（MD5 Message-Digest Algorithm）。严格来说，MD5并不是一种加密方式，MD5只是一个哈希算法，对同一个明文生成的密文（哈希值）是统一的。MD5相较于普通加密来说还有一个优点：MD5生成的密文长度很短（16位或者32位字符）。
数字签名
- 首先算出原始数据的摘要。这里的算法要保证：如果原始数据有任何变化，则摘要也会发生变化；对同一份原始数据，使用相同的算法，计算出的摘要是相同的。这一步使用的算法通常是MD5消息摘要算法。
- 生成一对公钥和私钥，使用非对称加密方式，用私钥对上一步生成的摘要进行加密，加密的结果就是数字签名。
- 在返回数据时，将原始数据和数字签名一起返回给请求数据方。
请求数据方在接收到数据之后，如何确认数据正确以及数据是合法的呢？请求数据方含有公钥，会对数字签名进行验证，过程如下： - 首先用含有的公钥对数字签名进行解密，如果能够解密成功，说明返回的数据是经过数据发送方认证的（否则数据发送方不会对该数据加密）。
- 对原始的数据使用MD5算法，生成原始数据的摘要。
- 对比第一步和第二步生成的摘要，如果生成的摘要相等，说明原始数据没有被篡改过。
由此，通过数字签名可以达到确保数据没有被篡改过以及数据是合法的目的。
通过AppStore下载的app签名机制
如果app仅仅只能从AppStore下载安装，那无疑是非常简单的。实际上，除了从AppStore下载安装，开发者还可以通过Xcode打包来安装，打好的包还可以安装在100台设备上，那么这些是如何控制的呢？
通过Xcode将app安装到手机上
在申请成为苹果开发者之后，可以通过Xcode将开发的app安装到手机上，实际上，即使是开发时的app，也需要通过苹果的验证。对于开发时app的安装，苹果使用的是双层验证。先看一些其他的知识。
CertificateSigningRequest文件
生成的CertificateSigningRequest文件里面保存的是公钥，私钥保存在本地Mac 中。
p12文件
双层签名机制
双层签名的流程如下：
- 在本地Mac 生成一对公钥、私钥
- 苹果生成一对公钥、私钥。其中私钥在苹果后台管理，每台iOS设备中都有公钥。
- 将本地Mac生成的公钥（CertificateSigningRequest）上传至开发者后台，在这个过程中，苹果会使用私钥对该公钥进行签名，最后生成一个证书文件。该证书文件中包含公钥L的原始数据，以及签名信息。开发者需要将该证书下载到本地的Mac。
- 在开发阶段，将app安装到手机上时，使用本地Mac的私钥（p12文件）对app进行签名，最终打包到手机上的有 App原数据，使用本地私钥对app加密后的签名文件，以及上一步下载的证书文件。
- iOS 设备使用公钥A验证证书中的签名，如果验证通过，说明该公钥是经过苹果认证的（也就是证实了开发者身份）。
- 之后使用证书中的公钥L 验证App 签名，如果验证通过，说明该app 的安装是合法的。
这样，通过两次验证，间接验证了app的安装是经过苹果允许的。
通过上述的双层验证，只是保证了某app的安装是经过苹果允许的，实际上苹果还有更多的限制： - 只有属于开发者开发的app 才被允许安装
- 开发者开发的app不能被随便安装，最多只能安装到100台设备上。
为了达到上述两个目的，上面流程中在使用私钥A对本地公钥加密时，还有一些其他的信息，如AppID，设备列表等。加上额外信息的流程如下：
实际的开发环境中，在将本地的公钥传到开发者中心后，在开发者中心配置设备列表、AppID、以及各种权限控制，之后苹果使用自己的私钥对这些数据进行签名，生成Provisioning Profile文件。开发时，需要将Provisionging Profile文件下载到本地，通过Xcode打包时，会将Provisioning Profile 文件也一起打包进app中。
结语
本文通过引入常见的加密方式，到数字签名，由浅入深介绍了iOS app签名的机制。本文参考了微信阅读的一篇博客加上自己的理解，包括所使用的插图均来自该博客。如果有理解不对的地方，欢迎大家留言交流。
参考文章
https://wereadteam.github.io/2017/03/13/Signature/
发布者：全栈程序员-站长，转载请注明出处：https://javaforall.net/221100.html原文链接：https://javaforall.net
