首先，在移动开发中，iOS系统中的app和andorid系统中的app的一个主要区别是在安卓系统中，app的安装很方便，可以从多个app应用商店下载。 (小米APP应用商店、华为APP应用商店)，也可以直接下载安装apk包。 在iOS系统上，APP安装限制很严，未经开发的APP只能从APP store下载。 无论是开发者还是拥有开发者帐户，都不能自行安装开发的APP。 最多有100台设备的限制，需要知道设备的UDID…… ……苹果的目的是确保所有APP都经过验证，并经过苹果的官方审查和许可。 苹果是如何做到这一点的呢？ 这是与本文介绍的内容相关的iOS app签名机制。
在介绍iOS app的签名机制之前，先介绍一下加密的相关知识。
一般的加密方式目前主流的加密方式有对称密钥加密和非对称密钥加密。
对称密钥加密在维基百科中，对称密钥加密的定义如下：
对称密钥加密(Symmetric-key algorithm )，也称为对称加密、私钥加密和共享密钥加密，是密码学中的一种加密算法。 此类算法使用相同的密钥进行加密和解密，或者使用两个可以方便地相互估计的密钥
简单来说，加密方和解密方使用了同一密钥。
典型的对称密钥加密包括AES和DES。
非对称密钥密码非对称密钥密码也称为公钥密码。
非对称密钥加密需要公钥和私钥两个密钥。 私钥用于加密，公钥用于解密。 私钥由加密方保管，公开密钥公开。
其实，私钥和共享密钥在数学上有一定的关系。 但是，仅靠共享密钥无法推定秘密密钥，这也是能够公开共享密钥的理由。
根据共享密钥估计私钥与素数分解有关。 目前，素数的分解没有特别快的算法，通常采用暴力枚举的方法进行分解。 如果素数非常大，例如2的1024次幂水平，则非对称加密是安全的，因为暴力分解素数是不现实的。
非对称加密的安全性还依赖于加密方私钥的管理，一旦私钥被暴露，就不能进行加密。
常见的非对称加密有RSA、DSA。
MD5加密MD5全名MD5消息摘要算法(MD5消息摘要)。 严格来说，MD5不是加密方式。 MD5是一种散列算法，为同一明文生成的密文(散列值)是统一的。 MD5与一般的加密相比，还具有MD5生成的密文的长度短(16比特或32比特字符)的优点。
数字签名在理解常见的加密方案后，介绍数字签名。 数字签名实际上与生活中的签名效果一致。 考虑到工作中的报销，申报单只有在领导签字后提交给财务，财务才能拿出对应的钱。 这里领导人的签名实际上保证了两件事：
1 .这笔钱支出合理，应该报销
2 .这笔钱的数量是正确的
也就是说，数据是正确的，领导承认。
在现实生活中当然没问题，但在网络上呢？ 例如，客户端请求服务器数据，如何确保数据的中途没有被篡改？ 不能像现实中那样用钢笔签名。 于是数字签名完成了。
数字签名与签名在现实生活中的作用是一致的。 这意味着：
1 .保证数据没有被篡改
2 .确保数据通过我的认证
数字签名如何保证以上两点？ 的不对称加密使用MD5线性加密。
数字签名的过程如下。
1 .首先计算出原始数据的摘要。 这里的算法必须保证如果原始数据有任何变化，摘要也会发生变化； 对相同的原始数据，使用相同的算法，计算出的摘要是相同的。 此步骤中使用的算法通常是MD5消息摘要算法。
2 .生成公钥和私钥对，使用非对称加密方式，用私钥加密在前一步骤中生成的摘要，加密结果为数字签名。
3 .返回数据时，将原始数据和数字签名一起返回给请求方。
请求数据的一方在收到数据后，如何确认数据正确和数据正确？ 请求方包含公钥，数字签名通过以下步骤进行验证。
1 .首先，如果用所包括的公开密钥对数字签名进行解密，并成功解密，则返回的数据将被数据发送者认证(否则，数据发送者不加密数据)。
2 .对原始数据使用MD5算法以产生原始数据的摘要。
3 .比较步骤1和步骤2生成的摘要，如果生成的摘要相等，则原始数据没有被篡改。
由此，可以保证数据没有被数字签名篡改，并且数据是正当的。
通过AppStore下载的app签名机制知道数字签名后，让我们来看看苹果是如何通过AppStore确保app合法性的。
据了解，iPhone只有一家制造商，iOS系统只有一个开发者。 那就是苹果公司。 因此苹果公司可以在所有的iOS系统上做统一的事情。 实际上，苹果公司生成了一对私钥和公钥，每个iOS系统都内置有公钥，私钥保存在苹果的后台。 开发者将APP上传到苹果服务器后，苹果公司使用私钥在APP上进行了数字签名。 用户从AppStore下载的app既包含app包，也包含数字签名。 在本地下载后，iOS系统使用公钥验证签名，可以确认APP已经过苹果公司的认证，软件包没有被篡改。 整个过程如下。
如果app只能从AppStore下载和安装，那无疑非常简单。 其实，除了
了从AppStore下载安装，开发者还可以通过Xcode打包来安装，打好的包还可以安装在100台设备上，那么这些是如何控制的呢？ 通过Xcode将app安装到手机上在申请成为苹果开发者之后，可以通过Xcode将开发的app安装到手机上，实际上，即使是开发时的app，也需要通过苹果的验证。对于开发时app的安装，苹果使用的是双层验证。先看一些其他的知识。
CertificateSigningRequest文件申请成为苹果开发者之后，需要在开发者后台上传 CertificateSigningRequest文件，那么CertificateSigningRequest 到底是什么呢？
CertificateSigningRequest 实际上是本地Mac 生成的公钥文件。
Mac可以通过钥匙串访问中的从证书颁发机构请求证书生成一对公钥、私钥。如下图：
生成的CertificateSigningRequest文件里面保存的是公钥，私钥保存在本地Mac 中。
在工作中，通常是多个同事共同开发一个app，每个人都可以安装app到真机上。多个人共同开发一个app时，就需要公用一份p12文件。那么p12文件又是什么呢？
p12其实就是保存在本地Mac的私钥。本地Mac的私钥可以导出，导出后的文件即为p12文件。如下图:
双层签名的流程如下：
1. 在本地Mac 生成一对公钥、私钥
2. 苹果生成一对公钥、私钥。其中私钥在苹果后台管理，每台iOS设备中都有公钥。
3. 将本地Mac生成的公钥（CertificateSigningRequest）上传至开发者后台，在这个过程中，苹果会使用私钥对该公钥进行签名，最后生成一个证书文件。该证书文件中包含公钥L的原始数据，以及签名信息。开发者需要将该证书下载到本地的Mac。
4. 在开发阶段，将app安装到手机上时，使用本地Mac的私钥（p12文件）对app进行签名，最终打包到手机上的有 App原数据，使用本地私钥对app加密后的签名文件，以及上一步下载的证书文件。
5. iOS 设备使用公钥A验证证书中的签名，如果验证通过，说明该公钥是经过苹果认证的（也就是证实了开发者身份）。
6. 之后使用证书中的公钥L 验证App 签名，如果验证通过，说明该app 的安装是合法的。
这样，通过两次验证，间接验证了app的安装是经过苹果允许的。
通过上述的双层验证，只是保证了某app的安装是经过苹果允许的，实际上苹果还有更多的限制：
1. 只有属于开发者开发的app 才被允许安装
2. 开发者开发的app不能被随便安装，最多只能安装到100台设备上。
为了达到上述两个目的，上面流程中在使用私钥A对本地公钥加密时，还有一些其他的信息，如AppID，设备列表等。加上额外信息的流程如下：
主要变化在第3步。使用私钥加密生成数字签名时，不仅仅是本地的公钥，还包括在开发者后台设置的AppID和设备列表。
第5步验证时，如果签名验证通过，说明本地的公钥是经过苹果认证的，且设备列表和AppID 没有被篡改过。
第6步验证时，除了验证App签名，还要验证该设备是否在设备列表中，AppID是否正确等信息。
通过这些附加的信息，就限制了安装数量，避免被滥用。
这也是为何当在开发者后台添加新的设备UDID 时，需要更新证书的原因。因为重新添加了UDID，苹果会重新用私钥加密，重新生成一个新的证书。
到这一步，我们基本上理解了iOS app的签名机制。通过上面的介绍，可以看到第三步生成的证书是非常复杂的，包含了非常多的信息。实际上，除了上述的内容，还有一些推送等权限也需要控制，这些数据也需要签名验证。如果再加上这些信息，证书会变的非常复杂，而且证书也是有一些固定格式的，太多的内容也不符合证书的格式。为了解决这个问题，苹果又搞了个Provisioning Profile文件（也就是俗称的pp文件）。Provisioning Profile文件中除了包含证书，还包含设备列表、AppID、各种权限控制等。
对于各种权限的控制，苹果也统一的处理了一下，叫做Entitlements 文件。
最终的流程也就变成了下面这样：
实际的开发环境中，在将本地的公钥传到开发者中心后，在开发者中心配置设备列表、AppID、以及各种权限控制，之后苹果使用自己的私钥对这些数据进行签名，生成Provisioning Profile文件。开发时，需要将Provisionging Profile文件下载到本地，通过Xcode打包时，会将Provisioning Profile 文件也一起打包进app中。
本文通过引入常见的加密方式，到数字签名，由浅入深介绍了iOS app签名的机制。本文参考了微信阅读的一篇博客加上自己的理解，包括所使用的插图均来自该博客。如果有理解不对的地方，欢迎大家留言交流。
参考文章https://wereadteam.github.io/2017/03/13/Signature/