iOS 的 Code Signing 体系

2019-08-28  本文已影响0人  Stephen_Huang

iOS中的Code Signing体系非常复杂，对新手非常不友好，虽然目前网上已经存在大量文章对此进行比较透彻的分析，最核心的部分已经讲解得非常清楚，我阅读了这些文章后，确实从中学习到不少知识，但我始终还是对Code Signing体系中很多相关的地方有着疑惑，于是决定认真地探究一番。本文会引用一些比较好的文章中的内容和图片，加上一些我个人的理解进行分析，有些内容本文不再重复，有需要的请阅读本文最后的参考文章。

概念

公开密钥加密、数字签名、证书这些通用的基本概念这里不再多说，主要提一下iOS上特有的东西

.certSigningRequest

点击mac OS的钥匙串访问里的 证书助理 -> 从证书颁发机构请求证书，最后会创建出一个.certSigningRequest文件，其实这个过程就是创建了一对公私钥

证书

AppleWWDRCA

iOS 以及 mac OS（在安装 Xcode 时）将自动安装 AppleWWDRCA.cer 这个中间证书（Intermediate Certificates），它实际上就是 iOS（开发）证书的证书，即根证书（Apple Root Certificate）。

iOS App Development

iOS的开发证书，在开发阶段进行真机测试时需要用到的证书。可以在苹果开发网站上手动创建，需要上传.certSigningRequest文件；或者使用Xcode自动创建。

iOS Distribution

iOS的发布证书，可以用于进行 Ad Hoc 测试、打包上传到 App Store 或者打包成 Enterprisee（In-House） 类型供企业内部使用。可以在苹果开发网站上手动创建，需要上传.certSigningRequest文件；或者使用Xcode自动创建。

.p12

在mac OS的钥匙串访问里选择一张证书，右击该证书，选择导出"xxxxx"，然后设置密码，可以导出该证书对应的.p12文件。.p12文件包含个人信息、公钥和私钥，也就是证书 + 私钥。iOS类型的每种证书同时存在数量有限制，而证书是依靠mac OS上的.certSigningRequest文件创建的，所以正常情况下，每种类型的证书只能在有限的Mac电脑上使用，如果需要在更多不同的Mac电脑上进行App开发、测试、签名，可以导出对应.p12文件代替证书来使用。

[图片上传中...(image-7e7b7d-1566972023627-8)]

<figcaption style="display: block; text-align: center; font-size: 1rem; line-height: 1.6; color: rgb(144, 144, 144); margin-top: 2px;"></figcaption>

Provisioning Profile

Provisioning Profile的文件格式为.mobileprovision，里面包含着

在苹果开发网站上手动创建，或者使用Xcode自动创建。

.ipa

.ipa文件是iOS上的App安装文件，其实它只是一个压缩包，等同于.zip格式，用mac OS自带的归档实用工具可以直接对它解压，可以看到里面的内容

用于上传App Store的.ipa文件

[图片上传中...(image-2fa890-1566972023627-7)]

<figcaption style="display: block; text-align: center; font-size: 1rem; line-height: 1.6; color: rgb(144, 144, 144); margin-top: 2px;"></figcaption>

App Store下载的.ipa文件

[图片上传中...(image-8770c8-1566972023627-6)]

<figcaption style="display: block; text-align: center; font-size: 1rem; line-height: 1.6; color: rgb(144, 144, 144); margin-top: 2px;"></figcaption>

对比两种情况的.ipa文件，可以看出它里面最主要的是Payload文件夹，而Payload文件夹里面放的就是该App对应的.app文件

.app

右击.app文件，选择显示包内容，可以看到里面的内容

用于上传App Store的.app文件

[图片上传中...(image-cb9b76-1566972023627-5)]

<figcaption style="display: block; text-align: center; font-size: 1rem; line-height: 1.6; color: rgb(144, 144, 144); margin-top: 2px;"></figcaption>

从App Store下载的.app文件

[图片上传中...(image-617dbe-1566972023627-4)]

<figcaption style="display: block; text-align: center; font-size: 1rem; line-height: 1.6; color: rgb(144, 144, 144); margin-top: 2px;"></figcaption>

可以看出.app文件主要包含三部分：

Code Signing

正常情况下（非越狱），所有App想要安装到iOS设备上，只有以下几种方法

无论是哪一种方法，都需要先把iOS项目编译成.app文件，然后进行签名。按照惯例，需要分析一下Code Signing

非App Store

对于非App Store获得的.ipa文件，需要严格复杂的签名和验证流程

[图片上传中...(image-eb8b6a-1566972023627-3)]

<figcaption style="display: block; text-align: center; font-size: 1rem; line-height: 1.6; color: rgb(144, 144, 144); margin-top: 2px;"></figcaption>

  1. 创建.certSigningRequest文件，这时候会生成一对公私钥，这里称为公钥L（L：Local），私钥L。.certSigningRequest文件保存着公钥L

  2. iOS 以及 mac OS上的AppleWWDRCA.cer 证书保存的就是苹果的公钥A（A：Apple），而对应的私钥A则在苹果的后台

  3. 在苹果开发者网站上创建证书的时候，上传.certSigningRequest文件其实就是把公钥L传到苹果后台，用苹果后台里的私钥A去签名公钥L，得到对应的证书，把证书下载回来双击安装，会跟对应的私钥L绑定一起保存在keychain中

  4. 除了证书，还需要对应的Provisioning Profile。在苹果开发者网站上：

    1. 设置App的Bundle ID
    2. 设置可安装该App的设备UDID
    3. 设置该App的权限
    4. 设置可以使用的证书
    5. 最后会使用私钥A把以上这些数据进行签名，组成一个Provisioning Profile，格式为.mobileprovision，下载回来双击安装，会保存在~/Library/MobileDevice/Provisioning Profiles中，文件名为它的UUID

  5. 当需要把一个App安装在iOS设备上时，都会先把iOS项目编译打包成.app文件，而打包成可安装在iOS设备上的.app文件的前提是，设置该App的Provisioning Profile，最后使用合法的证书对源代码编译后的各种文件进行签名，步骤如下：

    1. 用mac OS里的公钥A验证Provisioning Profile，获取里面的信息
    2. 用Provisioning Profile里面的信息验证App的Bundle ID是否对应，App的权限是否对应
    3. 用公钥A验证Provisioning Profile里面的证书，再判断是否有其中一张证书在这台Mac电脑里
    4. 如果上面的验证都通过了，则会从mac OS的keychain 中取出符合条件且最新创建的证书，拿到对应的私钥L
      1. 如果有.framework文件、.dylib文件、插件、watch目录下的extension，对它们分别进行签名
      2. 把Provisioning Profile改名为embedded.mobileprovision放在.app文件里面
      3. 使用私钥L对整个.app文件进行签名，得到签名信息CodeResources也放会在.app文件里面
    5. 如果需要生成.ipa文件，则会把.app文件放在Payload文件夹里，把Payload文件夹和一些其他信息文件（非必要），一起压缩形成一个.ipa文件

  6. 把.ipa文件或者.app文件安装在iOS设备上时

    1. 先使用iOS设备上的公钥A对.app文件里面的embedded.mobileprovision文件进行验证，获取里面的证书
    2. 再使用公钥A对embedded.mobileprovision文件里面存在的证书进行验证，取出一张对应的证书，得到公钥L
    3. 使用公钥L对.app里面所有签名信息进行验证，如果验证通过，证明该.app文件是完整合法，没有被篡改的
    4. 获取embedded.mobileprovision文件里面的可安装该App的设备UDID列表，判断该iOS设备是否可以安装
    5. 如果前面的验证都通过，则App会安装在iOS设备上

App Store

当需要在App Store发布App时，则先需要把.ipa文件上传到App Store。苹果会用一种非常简单的方式进行重新签名，这是因为在把.ipa文件上传到App Store之前，会先进行类似于上面步骤的一系列验证，只有通过验证才会上传成功，所以这已经进行过一次复杂的验证，代表苹果已经认同了这个.ipa文件，而用户又是从App Store下载的，所以也保证了.ipa文件来源是权威的，最后只需要在用户设备上进行简单的验证就可以

[图片上传中...(image-8c5dc8-1566972023627-2)]

<figcaption style="display: block; text-align: center; font-size: 1rem; line-height: 1.6; color: rgb(144, 144, 144); margin-top: 2px;"></figcaption>

  1. 苹果用私钥A对.app文件里面需要签名的文件进行重新签名
  2. 用户下载App Store上面的.ipa文件进行安装时，用iOS设备上的公钥A对.app文件里所有签名信息进行验证，如果验证通过，则会安装在iOS设备上

更多相关

以上就是Code Signing最核心的内容，但在iOS开发中其实还有很多相关的概念，很多需要注意的地方，接下来会讲解一下我个人的观察和分析

苹果开发者帐号体系

Apple Developer：直接在Apple Developer登录，同意Apple Developer协议后的账号，免费，只可以使用Xcode进行真机调试，Xcode 7之后苹果推出的功能

Apple Developer Program：分个人和组织类型，费用都是每年 99 美元，可以使用Xcode进行真机调试，打包Ad-Hoc测试，在App Store发布App

Apple Developer Enterprise Program：企业账号，费用是每年 299 美元，可以使用Xcode进行真机调试，打包Ad-Hoc测试，打包In-House App，但不能在App Store发布App

不同安装方式对应的证书类型

在iOS的项目中，只要不是运行在模拟器上，都会涉及到开发者帐号、证书、Provisioning Profile这些概念。

免费账号的限制：

Automatic signing

在Xcode 7之前，只有加入到Apple Developer Program（即付费）才能进行真机调试，Xcode 7之后苹果推出了Automatic signing功能，只要在Xcode上登陆Apple ID，就会自动管理证书和Provisioning Profile，同时没有加入Apple Developer Program的账号也能进行真机调试。

[图片上传中...(image-47ff33-1566972023626-1)]

<figcaption style="display: block; text-align: center; font-size: 1rem; line-height: 1.6; color: rgb(144, 144, 144); margin-top: 2px;"></figcaption>

在使用Xcode的Automatic signing功能的时候，无论是什么类型的账号，无论是直接Run进行真机调试，还是Archive，Code Signing Identity只能选用iOS Developer，只会使用iOS App Development类型的证书签名

如果不使用Automatic signing功能，则可以选择使用的是iOS App Development或者iOS Distribution证书进行签名

勾选Xcode中的AutoMatically manager signing，选择对应的Team后，无论是加入Apple Developer Program的账号（即付费账号）还是Apple Developer的账号（即免费账号）：

在使用Xcode的Automatic signing功能的前提下，进行Archive，然后Distribute App的时候，选择非Development的选项，再选择AutoMatically manager signing

Xcode对Provisioning Profile的验证

Xcode怎么把App和证书、Provisioning Profile绑定在一起呢？什么时候需要一张新的证书，什么时候需要一个新的Provisioning Profile？

Bundle ID是App的唯一标识，App和证书、Provisioning Profile绑定在一起，其实就是Bundle ID和证书、Provisioning Profile绑定在一起，两种情况：

Automatic signing

Bundle ID与开发者账号绑定。使用Automatic signing时，选择开发者账号（Team）后，Xcode会根据开发者账号去本地检索是否存在该账号对应的Provisioning Profile，再验证是否存在与该Bundle ID匹配的Provisioning Profile，再根据Provisioning Profile去本地检索是否存在对应的证书，都验证通过，则会设置成功。如果不存在Provisioning Profile，则会判断该Bundle ID是否已经被其他账号注册，如果已经被其他账号注册，则整个流程失败，需要选择对应的账号。如果该Bundle ID没有被其他账号注册或者账号已经对应上，则按照文章前面所说的步骤，最后生成Provisioning Profile。

没有使用Automatic signing

需要手动选择Provisioning Profile，当选择了其中一个Provisioning Profile时，则会分别验证Bundle ID是否对应、Provisioning Profile是否过期、是否存在对应的证书、App的权限是否对应、证书的类型和Code Signing Identity设置是否对应，如果都通过验证，则会设置成功。

结论

当你使用一台新的Mac电脑，进行开发、调试、发布某个开发者账号注册的App时，就需要一张新的证书（或者.p12文件）；当你使用新的证书或者新的App，就需要一张新的Provisioning Profile。一张证书对应一台Mac电脑，和一个开发者账号里面所有App，而一个Provisioning Profile则是只能对应一个App。

检验Provisioning Profile是签名的第一步，那如果Provisioning Profile通过检验，而Provisioning Profile里面又存在证书，为什么还需要单独安装证书呢？

答案是：Provisioning Profile里面证书的作用是验证本地是否有符合条件证书，并且在安装App的时候使用其中一张证书里面的公钥L来验证App的完整性和合法性。因为Provisioning Profile里面是有多张证书的，所以无法确定用哪张证书对应的私钥L用来签名，所以这些证书只能用于判断Mac电脑里有没有符合条件的证书，如果Mac电脑里有多张符合条件的证书，则默认用其中最新的证书里面的私钥L进行签名，这样就可以限制了只有获得符合条件的证书的Mac电脑，才能进行签名。

Mac电脑中证书的作用：1. 证明这台电脑是合法的；2. 找到对应的私钥L来对.app文件进行签名

Provisioning Profile中证书的作用：1. 判断这台电脑是否可以进行签名，也就是判断这个台电脑的合法性；2. 安装App时检验.app文件

Xcode的Build Configuration和Code Signing Identity

Xcode有Run、Archive、Test等几种项目构建方式，每一种可以指定不同的Build Configuration（默认有Debug和Release），而在Code Signing Identity又需要指定每种Build Configuration对应的配置，分别为iOS Developer和iOS Distribution，其实就是在设置Provisioning Profile的类型是开发的还是发布的

[图片上传中...(image-b58def-1566972023626-0)]

<figcaption style="display: block; text-align: center; font-size: 1rem; line-height: 1.6; color: rgb(144, 144, 144); margin-top: 2px;"></figcaption>

在使用Xcode的Automatic signing功能的时候，Code Signing Identity只能选择iOS Developer，否则会报错

Xcode的Run、Archive和Distribute App

Run和Archive的时候已经对App完成签名。如果设置的Provisioning Profile不是用于发布到App Store的，这时候把里面的.app文件打包成.ipa文件，可以利用Xcode或者其他工具直接安装到指定的iOS设备上。而点击Archives界面中Distribute App后，会再给你一次机会，选择其他证书和Provisioning Profile进行重签名，用于将App发布到不同的渠道

iOS设备上打开App时的验证

把App安装到iOS设备时，需要经过本文前面所说的验证，而打开App的时候，也需要验证：

重签名

在完全了解iOS中的Code Signing体系后，除了可以让你在日常开发中遇到证书、签名等问题的时候解决起来得心应手，还有一个重要的应用就是重签名。网上也有一大堆关于重签名的文章，大多数都只是说了怎么操作，但是很少会解释为什么要这样操作。接下来我会结合本文前面的内容详细分析重签名的原理。

原理

步骤

// 在.app文件中，把Info.plist的Bundle ID改为 com.xxx.xxx
/usr/libexec/PlistBuddy -c 'Set :CFBundleIdentifier com.xxx.xxx' "Info.plist"
复制代码

// 从embedded.mobileprovision文件中提取出entitlements.plist权限文件
security cms -D -i embedded.mobileprovision > temp.plist
/usr/libexec/PlistBuddy -x -c 'Print :Entitlements' temp.plist > entitlements.plist
复制代码

// 查看可用的证书
security find-identity -v -p codesigning

// 对.app内部的.framework文件、.dylib文件、PlugIns目录里的.appex文件、Watch目录里的.app文件分别进行签名
codesign -fs   证书ID   xxx.dylib

// 对.app文件进行签名
codesign -fs   证书ID  --entitlements entitlements.plist xxx.app
复制代码

codesign -d -vv xxx.app
复制代码

zip -r xxx.ipa Payload/
复制代码

注意

上一篇下一篇

猜你喜欢

热点阅读