双向签名:
手机和苹果服务器还有开发人员的MAC电脑，他们一共维护着2对公私钥，利用这两对公私钥分别完成双向签名与验证，从而已到达苹果服务器对苹果手机里的appstore的控制权，辨别此app是否是经过授权的。
Mac电脑作为开发者的电脑，自己有一组公私钥M，然后苹果服务器自己有一个私钥A，然后手机端保存了一份苹果服务器的公钥A。公钥加密的文件只有对应的私钥才能解开，反之私钥加密的文件只有对应的公钥才能解开。
第一步:从苹果服务器获取开发者证书过程
1.Mac先发送自己的公钥M向服务器，请求证书。
这里的公钥M CSR文件从哪来呢？他其实就是我们要生成证书之前从“钥匙串访问>证书助理”获取的那个文件：
这个文件很熟悉吧，这就是MAC端的公钥M，当然口说无凭，我们可以打开看一下。
openssl asn1parse -i -in CertificateSigningRequest.certSigningRequest
注意这个红圈的位置，他指定了采用sha256 RSA加密方式。 这就是你与苹果服务器之间的加密方式。
2.苹果下发证书
苹果拿到公钥M之后，会采用自己的私钥A对你的公钥M和CSR文件里面的hash值进行加密然后发送给你，这个就是你申请到的开发者证书。
为什么请求证书的MAC电脑可以直接打包编译，而给另一台MAC就必须要给他P12文件才能编译app？ 其实就是因为你给别人P12文件里面包含了私钥M，而直接给证书是不包含私钥M的。就是图上的那个小钥匙。
第二步:Mac电脑拿到证书后生成App
生成应用的时候，Mac用自己的私钥M对我们的App进行了一次签名，然后将真正的可执行文件Macho+App的签名+苹果下发的证书共同打包生成了我们的app包，这个就是安装在手机的上的文件。
当然口说无凭，我们可以对app包打开看一下
这里三个划红线的地方分别就是我们的APP签名信息、Macho可以行文件、证书。
第三步:验证App是否有效
1.获取公钥M
我们的iphone利用自己的公钥A，解开苹果服务器私钥A签名的证书，获取到里面的公钥M。
2.利用公钥M验证签名
利用得到的公钥M继续解开Mac电脑私钥M的App签名，从而验证APP是否有效。
这就是苹果的APP的双向签名原理。
有了上面那个流程后，看似安全了，可是他真的完美了吗？其实还是有一个缺陷的，开发者完全可以拿到证书后直接给手机安装上，这样做不是就绕开Appstore了吗，那怎么才能让开发者在调试的时候可以直接安装在手机上，而发布的时候必须在Appstore上呢？答案只有一个：描述文件.
描述文件
还记得咱们在申请证书之后想要成功的真机调试，还有一个重要步骤吧，就是分别配置开发模式、发布模式的描述文件吧"AAA.mobileprovision".你必须要在描述文件内部指定你的设备号，才能调试你对应的app吧。
描述文件是什么？其实就是一组权限控制的文件，它里面记录了可以被运行的设备、你的应用的appid、等其他权限类控制。口说无凭，我这里打开一个开发者模式的描述文件看一看。
security cms -Di test.mobileprovision
我们挑重要的看，它里面就直接记录了指定运行的手机设备号、这个证书日期、还有你开发者的相关信息，当然，你不要尝试着你手动更改他就能够绕过监控，看到那个<key>UIDI<key>了吗？这个描述文件也自带一组唯一编码的，也是会经过效验的，你想要更改信息，只能从苹果服务器去申请,他会随着你xocode打包的时候一起放入App。
签名信息
1.签名到底是什么？
举一个小小的例子。你消费了100元，并将此消息发送到服务器执行对应操作。这个时候完全有可能出现一个第三方截获这个信息，将100元改为1000元再发给服务器啊。这时候,服务器只要将这个1000元进行一下hash,然后和你发过来的hash比较一下就知道了,因为你发过来的是对100元的hash。
hash是什么？消息摘要，签名是什么？就是对你的app的消息摘要！
2.签名信息
还是口说无凭，下面我来看一看。
解压你的app后这个文件夹里面就是你的签名，里面记录的是对你的资源类文件的签名：比如图片、音视频等。
找到你的macho文件，浏览一下，红圈的位置就是你二进制文件的消息签名。有了这两组签名，就保证了资源和二进制文件的一致性。 这就是我们常说的签名。
