ios签名原理的简单理解

        在开发ios应用程序的过程中，如果需要真机调试或者发布应用，则必须给代码签名，一般要经过以下步骤：

            1、创建开发者账号；

            2、生成证书(Certificate)；

            3、添加App ID；

            4、添加要安装程序的设备UUID；

            5、根据已生成的证书、App ID以及设备创建配置文件(Provisioning Profile)；

        证书：

            概括的讲，一个证书是一个公钥加上许多附加信息，这些附加信息都是被某个认证机构（Certificate Authority 简称 CA） 进行签名认证过的，认证这个证书中的信息是准确无误的。对于 iOS 开发来说这个认证机构就是苹果的认证部门 Apple           Worldwide Developer Relations CA。申请证书时，首先由钥匙串访问程序(KeyChain)生成一个名为CertificateSigningRequest.certSigningRequest的请求文件，上传服务器后由苹果认证部门认证后生成调试(ios_development.cer)或者发布(ios_distribution.cer)认证文件，这个文件里面包含苹果根据请求文件生成的证书和私钥。签名时，codesign根据私钥对代码进行签名，安装到设备运行时，系统通过证书中的公约对代码进行解密（这是典型的非对称加密的做法）。

        App ID:

           App ID包括App ID Description和App ID Suffix。其后半部分一般来说跟应用的Bundle identifier一样，也可以使用通配符 (*) 来匹配多个应用；前半部分是一串随机的字符，整体看起来像这个格式：74ECR56AF9.com.company.app。

       UUID：

           uuid是设备的唯一标识，需要通过它来确保签名过的代码能在指定的设备上运行。

       授权机制：

             授权机制决定了哪些系统资源在什么情况下允许被一个应用使用。简单的说它就是一个沙盒的配置列表，上面列出了哪些行为被允许，哪些会被拒绝。在 iOS 上你的应用能做什么是受限制的，这些限制是沙盒管理的。沙盒和代码签名机制是不同的，代码签名保证了这个应用里所包含的内容正如它所说的那样不多不少，而沙盒则是限制了应用访问系统的资源。在 Xcode 的 Capabilities 选项卡下选择一些选项之后，Xcode 就会生成这样一段 XML。 Xcode 会自动生成一个 .entitlements文件，然后在需要的时候往里面添加条目。当构建整个应用时，这个文件也会提交给 codesign 作为应用所需要拥有哪些授权的参考。这些授权信息必须都在开发者中心的 App ID 中启用，并且包含在配置文件中。

       配置文件(Provisioning Profile):

            一个配置文件是一组信息的集合，这组信息决定了某一个应用是否能够在某一个特定的设备上运行。配置文件将签名，授权和沙盒联系了起来。配置文件中包含的在App ID注册的授权信息应该跟Xcode中配置的授权信息保持一致。举例来说，如果你在 Xcode 中添加了 iCloud 键值对存储授权 (com.apple.developer.ubiquity-kvstore-identifier)，但是没有更新，重新设置并下载新的配置文件，旧的配置文件规定你的应用并没有这一项授权。那么如果你的应用使用了这个功能，iOS 就会拒绝你的应用运行。这也是当你在开发者中心编辑了应用的授权，对应的配置文件会被标记为无效的原因。

参考链接：

    http://www.raywenderlich.com/2915/ios-code-signing-under-the-hood

    http://objccn.io/issue-17-2/