为了确保 iOS 平台对 App 拥有绝对的控制权，不至出现盗版软件盛行的局面，Apple 采取了签名机制。
预备知识
1.非对称加密算法
讨论 iOS App 签名机制之前，必须先了解一下非对称加密机制。顾名思义，非对称加密是相对对称加密来说的，前者需要两个密钥，即私钥和与之匹配的公钥，用其中之一加密，必须用另一个解密；而后者只有一个密钥，如下图：
2.数字签名
说完了非对称加密，我们再来看看签名是什么东东吧。签名就表示认可，它的作用是对一份数据做一个标记，然后将这份数据发给接收方，接收方通过上边的标记就可以确认这份数据是否曾被篡改过的。基本的签名及验证签名过程如下：
首先，生成一对非对称加密使用的密钥 (公钥+私钥)，私钥留在服务端，公钥发布出去；
然后，使用 HASH 算法 (最常用如 MD5) 得到原始数据的一个摘要，然后用私钥加密这个摘要，加密后的数据即称为原始数据的签名，把它和原始数据一起发送给用户；
最后，用户接收到原始数据和签名后，使用服务端发布出来的公钥解密签名，得到一个摘要 A。同时，用户使用同样的 HASH 算法生成原始数据的摘要 B，然后比较摘要 A 和 摘要 B，如果相等，说明数据未被篡改，否则，数据就被改动过。
补充：HASH 算法的特点是：①不可逆，即不能通过结果得到原始数据；②运算结果的长度固定，且比较短。
iOS App 的签名机制
iOS App 目前有以下几种安装方式：
1.AppStore 下载的 App可以在手机上安装。
2.开发过程中，可以直接 App 安装进手机进行调试。
3.In-House 企业内部分发，可以直接安装企业证书签名后的 APP。
4.AD-Hoc 相当于企业分发的限制版，它限制了安装设备的数量。
下面以前 2 种情况为例，讨论一下 iOS App 的签名机制。
1.AppStore
这种方式的实现比较简单，由苹果官方生成一对密钥(public-key/private-key)，公钥 （public-key）内置到 iOS 设备里，私钥（private-key）由苹果服务器保存。
当我们往 AppStore 上传 App 时，苹果服务器会用私钥（private-key）对 App 数据进行签名，iOS 系统下载这个 App 后，用设备自带的公钥（public-key）验证这个签名，若签名正确，说明这个 App 肯定是由苹果认证的，并且没有被修改过，这样就保证了安装的每一个 App 都是经过苹果官方允许的。
补充：把 App 上传 AppStore 后，苹果还会对 App 进行加密。
2.开发阶段
当开发 App 的时候，需要频繁的安装 App 到手机上，如果每次都先将 App 包传给苹果服务器，得到授权后才可以安装，那对开发者来说简直是灾难，而事实上，苹果也确实没有这么做，而是可以直接安装在手机上。
不过，苹果依然要求对 App 的安装有控制权，即：
① 必须经过苹果允许才可以安装；
② 权利不能被滥用，非开发状态的 App 不允许安装。
为了实现这些苛刻的要求，iOS 签名的复杂度也就增加了，苹果给出的解决方案是使用双重签名，大概流程见下图：
在开发机器（如 iMac、MacBook Pro 及 Mac mini）上创建一个密钥对 (公钥 local / 私钥 local)。即 通过 keychain 里边的 “从证书颁发机构请求证书” 创建，私钥存在本机，公钥就是得到的 CertificateSigningRequest。
苹果自己有固定的一个密钥对 (公钥 Apple / 私钥 Apple)，跟上面 AppStore 例子一样，私钥在苹果服务端，公钥在每个 iOS 设备上。
把公钥 local 传到苹果服务端，用苹果服务端的私钥 Apple 去签名公钥 local，得到一份证书，其中包含了公钥 local 及其签名。
在苹果后台申请 AppID，配置好设备 ID 列表和 App 可使用的权限，然后将这些数据连同上一步获得的证书一起用私钥 A 签名，把数据和签名合成一个 Provisioning Profile 文件，即通常所说的 xxx.mobileprovision 文件，下载到本地的开发机器。
在开发时，编译完一个 App 后，用私钥 local 对这个 App 进行签名，同时把上一步得到的 xxx.mobileprovision 打包进 App 里，文件更名为 embedded.mobileprovision，然后把 App 安装到手机上。
在安装时，iOS 系统取得证书，通过 iOS 设备内置的公钥 Apple，去验证 embedded.mobileprovision 的数字签名是否正确。
如果上一步验证签名成功，就可以取出 embedded.mobileprovision 里面的数据，做各种验证，具体包括：用公钥 local 验证 App 签名，验证当前 iOS 设备的 ID 是否在 设备 IDs 上，AppID 与当前 App 的 ID 是否对应得上，权限是否跟 App 里 Entitlements 的描述一致。
In-House 企业内部分发和 AD-Hoc 原理相似，只是企业内部分发不限制安装的设备数量，另外需要用户在 iOS 系统设置里边手动点击信任这个企业才能通过验证。
以上就是我所了解的 iOS App 的签名机制，其实只是个大概，还有许多细节可以深挖，以后再加吧！