iOS APP签名原理
目的
iOS之前，在主流操作系统上开发和运行软件是不需要签名的，软件软件随便从哪里下载都能运行，导致平台对第三方软件难以控制，盗版流行、苹果希望解决这样的问题，在iOS平台上对第三方APP有绝对的控制权，一定要保证每一个安装到iOS上的APP都是经过苹果官方允许的。 通过签名机制.
非对称加密
通常我们说的签名就是数字签名，他是基于非对称加密算法实现的。对称加密是通过同一份秘钥加密和解密数据，而非对称加密则有两份秘钥，分别是公钥和私钥，用公钥加密的数据需要私钥才能解密，用私钥加密的数据需要公钥才能解密。
非对称加密算法RSA数学原理
1.
2.
3.
数字签名
数字签名的作用是某一份数据打个标记，表示我认可这份数据（签了个名），然后发送给其他人，其他人可以知道这份数据是经过我认证的，数据没有被篡改过

1. 首先用一种算法，算出原始数据的摘要。需要满足
1.若原始数据有任何变化，计算出来的摘要值都会变化；
2.摘要要够短。这里最常用的算法是MD5
2. 生成一份非对称加密的公钥和私钥，私钥自己拿着，公钥公布出去
3. 对一份数据，算出摘要后，用私钥加密这个摘要，得到一份加密后的数据，称为原始数据的签名。把它跟原始数据一起发送给用户。
4. 用户收到数据和签名后，用公钥解密得到摘要。同时用户用同样的算法计算原始数据的摘要，对比这里算出来的摘要和用公钥解密签名得到的摘要是否相等，若相等表示这份数据中途没有被篡改过，因为如果篡改过，摘要会变化。
之所以要有第一步计算摘要，是因为非对称加密的原理限制可加密内容不能太大，于是若要对任意大的数据签名，就需要改成对它的特征值签名，效果是一样的。
最简单的签名
苹果官方生成一对公私钥，在iOS里内置一个公钥，私钥由苹果后台保存，我们传APP上App Store时，苹果后台用私钥对APP数据进行签名，iOS系统下载这个APP后，用公钥验证这个签名，若签名正确，这个APP肯定是由苹果后台认证的，并且没有被修改过，保证安装的每一个APP都是经过苹果官方允许的。

除App Store下载，还有三种方式安装一个APP：
• 开发APP时可以直接把开发中的应用安装进手机进行调试
• In-House企业内部分发，可以直接安装企业证书签名后的APP
• AD-Hoc相当于企业分发的限制版，限制安装设备数量
开发时安装APP
1.安装包不需要传到苹果服务器，可以直接安装到手机。如果你编译一个APP到手机前要先传到苹果服务器签名，这显然不能接受的。
2.苹果必须对这里的安装有控制权，包括：•经过苹果允许才可以安装；•不能被滥用导致非开发APP也能被安装。
双层签名

1. 在你的Mac开发机器生成一对公私钥，这里称为公钥L，私钥L。
2. 苹果自己有固定的一对公私钥，跟上面App Store例子一样，私钥在苹果后台，公钥在每个iOS设备上。这里称为公钥A，私钥A。
3. 把公钥L传到苹果后台，用苹果后台里的私钥A去签名公钥L。得到一份数据包含了公钥L及其签名，把这份数据称为证书。
4. 在开发时，编译完一个APP后，用本地的私钥L对这个APP进行签名，同时把第三步得到的证书一起打包进APP里，安装到手机上。
5. 在安装时，iOS系统取得证书，通过系统内置的公钥A，去验证证书的数字签名是否正确。
6. 验证证书后确保了公钥L是苹果认证的，再用公钥L去验证APP的签名，这里就间接验证了这个APP安装行为是否经过苹果官方允许。
避免被滥用
- 限制在苹果后台注册过的设备才可以安装，
- 限制签名只能针对某一个具体的APP

最终流程
Provisioning Profile包含了证书以及上述提到的额外信息，以及所有信息的签名

- 在Mac开发机器生成一对公私钥。
- 苹果自己又固定的一对公私钥，私钥在苹果后台，公钥在每个iOS设备。
- 把公钥L传到苹果后台，用私钥A去签名公钥L，得到一份数据包含了公钥L以及其签名，这分数据称为证书。
- 在苹果申请AppID，配置好设备Id列表和APP可使用的权限，再加上第3步的证书，组成的数据用私钥A签名，把数据和签名一起组成一个pp文件。
- 在开发时，编译完一个APP后，用本地的私钥L对这个APP进行签名，同时把第4步得到的pp文件打包进APP里，文件名为embedded.mobileprovision，把APP安装到手机上。
- 在安装时，iOS系统取得证书，通过系统内置的公钥A，去验证embedded.mobileprovision的数字签名是否正确，里面的证书签名也会再验一遍。
- 确保了embedded.mobileprovision里的数据是苹果授权后，就可以去除里面的数据，做各种验证，包括公钥L验证APP签名，验证设置ID是否在ID列表上，AppID是否对应得上，权限开得是否跟APP里的Entitleements对应等。
