iOS应用签名原理和流程，怎么用脚本实现重签名？ _iOS

在苹果的日常开发中，真机测试与打包等很多流程都会牵扯到各种证书，CertificateSigningRequest，p12等。但是很多相应的开发者并不理解IOS App应用签名的原理和流程。今天着重讲解一下此内容。
思考
在苹果的iOS系统出来之前，以前的主流程mac OS/Window软件存在着安全隐患，盗版软件，病毒入侵等，苹果希望能解决类似的问题，保证每一个安装在苹果手机上的app都是经过苹果官方允许的，怎么保证呢？
一、iOS 应用签名原理
1 代码签名
要想回答上面“思考”的答案，首先我们讲解一个概念。代码签名：是对可执行脚本或者文件进行数字签名，用来保证软件在签名后未被损害或者修改的措施。
2 简单的代码签名
最简单的验证方式是通过苹果官方生成非对称加密的一对公私钥。私钥保存在Appstore的服务器，而公钥保存在iOS系统中，苹果后台用私钥来对App数据进行签名，iOS系统下载此APP后，用公钥来验证签名。若验证成功，说明该App未被更改，可以安装到手机中，反之，则不行。
上面的验证可以解决大部分App入驻手机中的场景，但是对于我们开发苹果应用的开发者而言，我们也可以直接通过真机测试进入到用户的手机，而且苹果也有企业用户渠道，所以如果想要全方面的安全的安装苹果App，就无法通过简单的代码签名做到，那么苹果又是通过怎样的方案呢？
3 双层签名
下面流程图

文章插图

解释如下：

首先Mac电脑通过CSR文件申请证书（通过公钥M）
苹果服务器返回公钥M以及公钥M算出的哈希值（也就是签名）
App包里包括可执行文件MachO，然后对MachO通过私钥M签名（App签名）并将证书放到App中
然后将App放入到iphone中。首先将App中的证书拿出来解析，谁能解析App的证书，因为App的证书是由苹果服务器拿着私钥A中进行加密的，也只有公钥A能解密出来，也就是iphone中保存的公钥A，通过验证查看App是否被修改；然后再去验证App的签名，怎么验证App的签名呢，（App签名是通过Mac 电脑的私钥M进行加密的，也只有证书中的公钥M进行解密）就这样经过了两层验证！

通过上面的讲解，是不是发现特别的安全了？其实不然，因为大部分的应用都是通过AppStore进行安装，如果通过上面的过程可以安装所有的苹果设备，那么还需要要Appstore干嘛，这时候苹果防止滥用App，就做了两条限制：

经过苹果服务器中注册过的设备
签名只能具体到某一个App进行签名（推送，授权等）

经过上面的讲解，也引出了另一个概念-描述文件。
4 描述文件
描述文件又称为Provisioning profile，一般包括了三样东西：

证书
AppId
设备

当我们打包或者是真机运行的时候，通过证书来验证程序的安全性和合法性。
并且在App的使用中，苹果还想控制App里面的推送/iCloud及后台运行等这些的权限，苹果将这些权限开关统称为授权文件-Entitlements，并将文件放在了描述文件中。
在开发中，编译一个App后，会用本地的私钥M对App进行签名，同时从苹果服务器得到的描述文件打包进App里为embeded.mobileprovision，把App安装在手机中，最后系统进行来验证。
上面的图也会变为如下：流程就是将描述文件加入，解决上面的问题？

文章插图

5 拓展
首先我们做一个demo讲解App包内容。

文章插图

首先看工程文件1-products文件，点击打开Demo.app，显示包内容，紧接着出现2-内容
查看有_Codesignature，是资源文件签名；embedded.mobileprovision是上面说的描述文件；另外我们看下可执行代码，也就是MachO文件，放在了001--Demo中，也就是黑色的一个，通过MachOView中可以查看MachO文件。打开之后，代码签名放在MachO中如下：