iOS签名的目的
在 iOS 出来之前，在主流操作系统(Mac/Windows/Linux)上开发和运行软件是不需要签名的，软件随便从哪里下载都能运行，导致平台对第三方软件难以控制，盗版流行。苹果希望解决这样的问题，在 iOS 平台对第三方 APP 有绝对的控制权，一定要保证每一个安装到 iOS 上的 APP 都是经过苹果官方允许的。
一、苹果开发者账号分类
个人账号和公司账号差别不大，主要区别在于开发者数量。还有个问题在于，如果是个人账号发布的应用，App Store开发者的位置显示的是开发者个人的名字，而公司账号则可以显示公司的名字，现在App Store上的应用一般都是公司账号。
企业账号比较特殊，发布的安装包可以安装到任何设备上，但是不能发布到App Store。一般一些企业内部的应用都使用这种账号，想开发什么就开发什么，不用担心苹果审核机制的问题。
企业账号和99$的两种账号还有个区别在于，正是由于企业账号是不向App Store发布的，所以更新应用是直接更新的。避免了苹果审核的等待，只不过苹果现在审核时间也缩短了不少。
企业账号还有一个用途，就是一些XX助手之类的应用下载下来的，一般都是企业账号打的包。这些XX助手的平台把原生ipa包进行反编译，以达到某些目的，然后通过企业账号重新打包。
教育账号是苹果推出的一种特殊的账号，这种账号主要面向大学生，用来让在校大学生进行Apple相关开发的。这种账号还是不要想了，苹果对这块的审批还是很严的。
二、加密相关知识
通常我们说的签名就是数字签名，它是基于非对称加密算法实现的。对称加密是通过同一份密钥加密和解密数据，而非对称加密则有两份密钥，分别是公钥和私钥，用公钥加密的数据，要用私钥才能解密，用私钥加密的数据，要用公钥才能解密。
非对称加密即加密密钥与解密密钥不同，且成对出现 对外公开的称为公钥，这对密钥生成者才拥有的称为私钥。通过私钥加密的密文只能通过公钥解密，反之亦然 。例如，RSA算法，非对称加密加解密比较耗时，实际使用中，往往与对称加密和摘要算法结合使用。
经典用法:
1、防止中间攻击：接收方将公钥公布-》发送方通过该公钥将明文加密-》传输给接收方-》接收方使用私钥解密，通常用于交换对称密钥（由于非接收方无私钥，无法截获）
2、身份验证和防止篡改：私钥加密授权明文-》将明文+加密后的密文+公钥一并发送给接收方-》接收方用公钥解密密文，再与明文对比是否一致，以此判断是否被篡改，用于数字签名
摘要算法：
将任意长度文本通过一个算法得到一个固定长度的文本。 源文本不同，计算结果必然不同 ，无法从结果反推源，例如，MD5和SHA算法。
数字签名：
非对称加密与摘要算法的结合，结合摘要算法是因为非对称加密的原理限制可加密的内容不能太大。
三、数字签名
数字签名的作用是我对某一份数据打个标记，表示我认可了这份数据（签了个名），然后我发送给其他人，其他人可以知道这份数据是经过我认证的，数据没有被篡改过。
情景：有一段授权文本，需要发布，要防止中途篡改内容，保证完整性与合法性
发送方：
1. 授权文本-》摘要算法-》得到摘要
2. 私钥加密摘要得到密文
3. 将源授权文本+密文+公钥一并发布
验证方：
1. 用公钥解密密文得到摘要a
2. 将源授权文本-》摘要算法-》得到摘要b
3. 对比摘要a与摘要b是否一致
四、签名机制与验证
当App 提交审核通过后，Apple会对App重签名，所以从App Store下载的app都是苹果的官方签名。
1、简单签名
苹果官方生成一对公私钥，在 iOS 里内置一个公钥，私钥由苹果后台保存，我们传 App 上 AppStore 时，苹果后台用私钥对 APP 数据进行签名，iOS 系统下载这个 APP 后，用公钥验证这个签名，若签名正确，这个 APP 肯定是由苹果后台认证的，并且没有被修改过，也就达到了苹果的需求：保证安装的每一个 APP 都是经过苹果官方允许的。
流程如下：
1.Apple 官方有自己固定的一对公钥和私钥，私钥A存在Apple后台，公钥A存在iOS设备
2.app审核通过后，Apple后台用私钥A对其进行重签名
3.app下载到iOS设备后，iOS设备内置的公钥A会对app的签名进行验证，如果验证通过，则可运行，否则不能
2、双层签名
对与开发调试安装app时，有两个需求：
1. 安装包无需上传到Apple服务器；
2. 必须经过Apple允许，且不能被滥用导致非开发app也能被安装。
流程如下：
1.在Mac上生成一对公私钥，分别为公钥L，私钥L
2.Apple 官方有自己固定的一对公钥和私钥，私钥A存在Apple后台，公钥A内置在iOS设备
3.把公钥L 上传Apple后台，Apple后台用私钥A对公钥L进行签名，将得到的签名+公钥L打包起来，称为证书
4.开发时，编译完一个app后，用本地私钥L对app进行签名，然后把3中的证书、app和app签名一起打包安装到手机上。
5.iOS设备内置的公钥A对证书中签名进行验证
如果5中验证通过，再用证书中的公钥L对app签名进行验证，从而间接保证app安装是官方允许的。
3、双层签名+限制
上述流程只解决了需要Apple允许才能安装，但还未解决避免被滥用的问题。
在此，苹果加了两个限制，1.限制设备，2.限制签名只针对某一具体app。
流程基本如上，只是添加了设备IDs和AppID：
第三步：把公钥L 上传Apple后台，Apple后台用私钥A对(公钥L+设备IDs+AppID)进行签名，将得到的签名+公钥L打包起来，成为证书
第五步：iOS设备内置的公钥A对证书中签名进行验证，同时将设备IDs判断当前设备是否符合要求，AppID验证App是否一致
4、最终流程
上述证书有很多额外信息，实际上出了 设备IDs/AppID，还是其他信息，比如iCloud／Push／后台运行等权限，这些权限开关统称为 Entitlements，它也需要通过签名去授权，这些额外信息都塞在证书里是不合适的，所以就有一个叫 Provisioning Profile 的东西。
Provisioning Profile = 证书 + 上述额外信息 + 所有信息的签名
最终流程如下：
1.在Mac上生成一对公私钥，分别为公钥L，私钥L
2.Apple 官方有自己固定的一对公钥和私钥，私钥A存在Apple后台，公钥A内置在iOS设备
3.把公钥L 上传Apple后台，Apple后台用私钥A对公钥L进行签名，将得到的签名+公钥L打包起来，称为证书
4.在苹果后台申请AppID，配置好设备IDs, Entitlements,这些额外信息+3中的证书组成的数据用私钥A签名，最后证书+额外信息+签名组成 Provisioning Profile 文件，下载到Mac本地
5.开发时，编译完一个app后，用本地私钥L对app进行签名，然后把4中的Provisioning Profile文件打包进App里，文件名为embedded.mobileprovision，安装到手机上。
6.安装时，iOS设备内置的公钥A对embedded.mobileprovision的数字签名进行验证，同时对里面的证书的签名也会验证
7.如果6中验证通过，确保了embedded.mobileprovision的数据是苹果授权后，再取出里面数据做各种验证，包括公钥L对app签名进行验证，验证设备ID，AppID，权限开关
五、概念与操作
上述步骤与平常具体操作与概念如下：
1、KeyChain 里的“从证书颁发机构请求证书”，本地生成一对公私钥，保存的CertificateSigningRequest(CSR)即公钥L，私钥L保存在电脑本地
2、苹果处理
3、在Member Center把CertificateSigningRequest上传到苹果后台生成证书，下载到本地（因为私钥是本地Mac持有，所以团队开发时，可在KeyChain导出私钥，存为.p12文件，其他Mac即可导入这个私钥）
4、在Member Center配置AppID／设备UUID／Entitlements, 生成对应的 Provisioning Profile 文件，并下载到本地
5、打包编译时，Xcode会根据3中的证书，用对应该证书的本地私钥L对app进行签名，并把4中的 Provisioning Profile 文件命名为 embedded.mobileprovision 一起打包进去。这里对App的签名数据分两部分，Mach-O 可执行文件把签名直接写进这个文件，其他资源文件则保存在_CodeSignature目录下
6、6到7的打包验证是Xcode和iOS的事。
其他发布方式（In-House和Ad-Hoc）流程与开发包签名验证流程差不多，In-House不限制安装的设备数。
参考链接：
https://www.jianshu.com/p/f3f102b9db96
https://blog.csdn.net/zn_echonn/article/details/80248786
