iOS 开发 code sign 代码签名深入剖析

前言

三个模块:

//代码签名授权
Code Signing Entitlements
//代码签名身份
Code Signing Identity
//描述文件/配置文件
Provisioning Profile

1.点击这里—-苹果官网code sign guide

2.代码签名 (code signing) 和配置文件 (provisioning),是做iOS开发绕不过的坎,报错的时候也是很不容易解决的,终究其原因,就是对苹果为iOS开发设置的一整套安全机制理解不到位导致的,平时大家都集中时间处理开发中遇到的需求问题,在这里投入的时间不够,到时出现错误时,不晓得从哪里下手

3.苹果的很多东西都是闭源的,代码签名就是一个难以理解的神秘黑盒,我们无法直接看到代码签名的运作过程，它们隐藏在 iOS 系统内部和 SDK 之中.想要理解code sign的运作,就不得不了解证书和秘钥了

证书( Certificates)和密匙(Keys)

作为一个 iOS 开发者，在你开发使用的机器上应该已经有一个证书，一个公钥，以及一个私钥。这些是代码签名机制的核心

打开–钥匙串—我的证书

可以看到所有你持有的私钥相对应的证书。
要用一个证书设置代码签名，必须拥有私钥，所以所有拥有私钥的证书都会被列在这里。
如果拥有一个证书的私钥，可以展开证书并将它的私钥显示出来：
如果要导出证书，例如为了备份（强烈建议进行），一定要记得展开证书那一条显示出私钥并将两行都选中。且导出后的证书就是.p12格式的文件,做推送时,就是这样的文件

证书/认证机构/有效期

一个证书是一个公钥加上许多附加信息，这些附加信息都是被某个认证机构（Certificate Authority 简称 CA）进行签名认证过的，认证这个证书中的信息是准确无误的。
对于 iOS 开发来说这个认证机构就是苹果的认证部门 Apple Worldwide Developer Relations CA。
认证的签名有固定的有效期，这就意味着当前系统时间需要被正确设置，因为证书是基于当前时间进行核对。这也是为什么将系统时间设定到过去会对 iOS 造成多方面破坏的原因之一。
对于iOS开发,有两种证书:开发证书(Develope)和发布证书(Distribution).iOS 系统会利用这个信息来判断你的应用是运行在开发模式下还是发布模式，并据此判断以切换应用运行规则

证书/签名/公钥/私钥

为了让拥有公钥的证书起作用，我们需要有私钥。
私钥是你在为组成应用的二进制文件进行签名时派上用场的。没有私钥，你就无法用证书和公钥对任何东西设置签名.
签名过程本身是由命令行工具 codesign 来完成的。
如果你在 Xcode 中编译一个应用，这个应用构建完成之后会自动调用 codesign 命令进行签名，codesign 也正是给你提供了许多格式友好并且有用错误信息的那一个工具。你可以在 Xcode 的 project settings 中设置代码签名信息。

注意:

Xcode 只允许在有限的选项中进行选择，这些选项都是既拥有公钥也拥有私钥的证书。
如果在选项中没有出现你想要的那一个，那么你需要检查的第一件事情就是你是否拥有这个证书的私钥。
在这里需要区分开用于开发测试还是用于发布，如果想要在机器上测试你的应用，你需要用用于开发测试的那一对密匙来进行签名，如果你是要发布应用，无论是给测试人员还是发布到 APP Store，你需要用用于发布的那一对密匙来进行签名。
Xcode 6之后的 project settings 中出现了设置配置文件(Provisioning Profile)的选项。如果你选择了某一个配置文件，你必须选择这个配置文件的证书中所包含的公钥所对应的那个密匙对，或者你可以选择让 Xcode 自动完成正确的设置

已签名应用–签名信息的查看和修改

原理理解:一个已签名的可执行文件的签名包含在 Mach-O 二进制文件格式中；对于例如脚本这样的非 Mach-O 可执行文件，就存放在该文件系统的的扩展属性中。这种做法使得在 OS X 和 iOS 上的任何可执行二进制文件都可以被设置签名：不论是动态库，命令行工具，还是 .app 后缀的程序包。这也意味着设置签名的过程实际上会改动可执行文件的文件内容，将签名数据写入二进制文件中。
如果你拥有一个证书和它的私钥，那么用 codesign 来设置签名非常简单，我们现在尝试用下面列出的这个证书来为 Example.app 设置签名：

$ codesign -s 'iPhone Developer: 151245000@qq.com (4KPK36MFV)' Example.app

如果你想为某一个 app 程序包重新设置签名，那么这个工具就很有用了。为了重新设置签名，你必须带上 -f 参数，有了这个参数，codesign 会用你选择的签名替换掉已经存在的那一个：

$ codesign -f -s 'iPhone Developer: 151245000@qq.com (4KPK36MFV)' Example.app

codesign 还可以为你提供有关一个可执行文件签名状态的信息，这些信息在出现不明错误时会提供巨大的帮助。举例来说，$ codesign -vv -d Example.app 会列出一些有关 Example.app 的签名信息

'Executable'=/Users/toto/Library/Developer/Xcode/DerivedData/Example-cfsbhbvmswdivqhekxfykvkpngkg/Build/Products/Debug-iphoneos/Example.app/Example
'Identifier'=ch.kollba.example
'Format'=bundle with Mach-O thin (arm64)
CodeDirectory v=20200 size=26663 flags=0x0(none) hashes=1324+5 location=embedded
Signature size=4336
'Authority'=iPhone Developer: 151245000@qq.com (4KPK36MFV)
'Authority'=Apple Worldwide Developer Relations Certification Authority
'Authority'=Apple Root CA
'Signed Time'=29.09.2014 22:29:07
'Info.plist entries'=33
'TeamIdentifier'=DZM8538E3E
Sealed Resources version=2 rules=4 files=120
Internal requirements count=1 size=184

以 Authority 开头的那三行。这三行告诉你到底是哪一个证书为这个 app 设置了签名。在这里当然是我的证书，iPhone Developer: 151245000@qq.com (4KPK36MFV)。我的这个证书则是被证书 Apple Worldwide Developer Relations Certification Authority 设置了签名的，依此类推这个证书则是被证书 Apple Root CA 设置了签名。
在 Format 中也包含了一些关于代码的信息：Example.app 并不单单是一个可执行文件，它是一个程序包，其中包含了一个 arm64 二进制文件。从 Executable 中的路径信息你可以看出，这是一个以测试为目的的打包，所以是一个 Mach-O thin 的二进制文件。
在一堆诊断信息中还包含了两个非常有趣的条目。 Identifier 是我在 Xcode 中设置的 bundle identifier。 TeamIdentifier 用于标识我的工作组（系统会用这个来判断应用是否是由同一个开发者发布）。此外用于发布应用的证书中也包含这种标识，这种标识在区分同一名称下的不同证书时非常有用。
下面我们来检查一下封印是否完好：

$ codesign --verify Example.app

授权机制 (Entitlements) 和配置文件 (Provisioning)

原理理解:

即使你可以让应用运行起来，在 iOS 上你的应用能做什么依然是受限制的。这些限制是沙盒管理的。

沙盒和代码签名机制是不同的。代码签名保证了这个应用里所包含的内容正如它所说的那样不多不少，而沙盒则是限制了应用访问系统的资源。

这两种技术是相互合作来发挥作用的，它们都能阻止你的应用运行，也都能在 Xcode 中引起奇怪的问题。但是在日常开发过程中，沙盒可能会更经常引起问题。沙盒机制在什么时候会引起问题呢，大多数情况下都是由于一个叫做授权的机制决定的。

授权机制

授权机制决定了哪些系统资源在什么情况下允许被一个应用使用。简单的说它就是一个沙盒的配置列表，上面列出了哪些行为被允许，哪些会被拒绝。

很可能你已经猜到授权机制也是按照 plist 文件格式来列出的。Xcode 会将这个文件作为 –entitlements 参数的内容传给 codesign ，这个文件内部格式如下：

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict><key>application-identifier</key><string>7TPNXN7G6K.ch.kollba.example</string><key>aps-environment</key><string>development</string><key>com.apple.developer.team-identifier</key><string>7TPNXN7G6K</string><key>com.apple.developer.ubiquity-container-identifiers</key><array><string>7TPNXN7G6K.ch.kollba.example</string></array><key>com.apple.developer.ubiquity-kvstore-identifier</key><string>7TPNXN7G6K.ch.kollba.example</string><key>com.apple.security.application-groups</key><array><string>group.ch.kollba.example</string></array><key>get-task-allow</key><true/>
</dict>
</plist>

在 Xcode 的 Capabilities 选项卡下选择一些选项之后，Xcode 就会生成这样一段 XML。 Xcode 会自动生成一个 .entitlements 文件，然后在需要的时候往里面添加条目。

当构建整个应用时，这个文件也会提交给 codesign 作为应用所需要拥有哪些授权的参考。这些授权信息必须都在开发者中心的 App ID 中启用，并且包含在配置文件中。在构建应用时需要使用的授权文件可以在 Xcode build setting 中的 code signing entitlements 中设置。

$ codesign -d --entitlements - Example.app

会列出一个和前面的很像的 XML 格式的属性列表。你可以将这个文件的内容添加进一个脚本，每次构建应用时用脚本检查是否包含了推送服务的授权信息，以此确保推送服务工作正常。在这里推送服务只是一个例子，你使用的服务越多，这样的时候都添加推送通知的授权，以保证可以注册推送通知。Xcode 6 之后，授权信息列表会以 Example.app.xcent 这样的名字的文件形式包含在应用包中。

配置文件

在整个代码签名和沙盒机制中有一个组成部分将签名，授权和沙盒联系了起来，那就是配置文件 (provisioning profiles)。

每一个 iOS 开发者可能都花费过相当的时间研究如何设置配置文件，这个环节也正是会经常出问题的地方。

一个配置文件中存放了系统用于判断你的应用是否允许运行的信息，这就意味着如果你的配置文件有问题，修复起来会相当烦人。

一个配置文件是一组信息的集合，这组信息决定了某一个应用是否能够在某一个特定的设备上运行。配置文件可以用于让应用在你的开发设备上可以被运行和调试，也可以用于内部测试 (ad-hoc) 或者企业级应用的发布。Xcode 会将你在 project setting 中选择的配置文件打包进应用。

我们下面来仔细研究一下配置文件。如果你要在自己的机器上找到配置文件，在这个目录下 ~/Library/MobileDevice/Provisioning Profiles。Xcode 将从开发者中心下载的全部配置文件都放在了这里。

配置文件并不是一个 plist 文件，它是一个根据密码讯息语法 (Cryptographic Message Syntax) 加密的文件

采用 CMS 格式进行加密使得配置文件可以被设置签名，所以在苹果给你这个文件之后文件就不能被改变了。配置文件的签名和应用的签名不是一回事，它是由苹果直接在开发者中心 (developer portal) 中设置好了的。

某些版本的 OpenSSL 可以读取这种格式，但是 OS X 自带那个版本并不行。幸运的是命令行工具 security 也可以解码这个 CMS 格式，那么我们就用 security 来看看一个 .mobileprovision 文件内部是什么样子：

$ security cms -D -i example.mobileprovision

这个命令会输出签名信息中的内容，接下来你会得到一个 XML 格式的 plist 文件内容输出。

这个列表中的内容是 iOS 用于判断你的应用是否能运行在某个设备上真正需要的配置信息，每一个配置文件都有它自己的 UUID 。Xcode 会用这个 UUID 来作为标识，记录你在 build settings 中选择了哪一个配置文件。

首先来看 DeveloperCertificates 这项，这一项是一个列表，包含了可以为使用这个配置文件的应用签名的所有证书。如果你用了一个不在这个列表中的证书进行签名，无论这个证书是否有效，这个应用都无法运行。所有的证书都是基于 Base64 编码符合 PEM (Privacy Enhanced Mail, RFC 1848) 格式的。要查看一个证书的详细内容，将编码过的文件内容复制粘贴到一个文件中去，像下面这样：

-----BEGIN CERTIFICATE-----
MIIFnjCCBIagAwIBAgIIE/IgVItTuH4wDQYJKoZIhvcNAQEFBQAwgZYxCzA…
-----END CERTIFICATE-----

可能会注意到在 Entitlements 一项中包含了你的应用的所有授权信息，这些授权信息是你在开发者中心下载配置文件时在 App ID 中设置的，理想的情况下，这个文件应该和 Xcode 为应用设置签名时使用的那一个同步，但这种同步并不能得到保证。这个文件的不一致是比较难发现的问题之一。

举例来说，如果你在 Xcode 中添加了 iCloud 键值对存储授权 (com.apple.developer.ubiquity-kvstore-identifier)，但是没有更新，重新设置并下载新的配置文件，旧的配置文件规定你的应用并没有这一项授权。那么如果你的应用使用了这个功能，iOS 就会拒绝你的应用运行。这也是当你在开发者中心编辑了应用的授权，对应的配置文件会被标记为无效的原因。

如果你打开的是一个用于开发测试的证书，你会看到一项 ProvisionedDevices，在这一项里包含了所有可以用于测试的设备列表。因为配置文件需要被苹果签名，所以每次你添加了新的设备进去就要重新下载新的配置文件。

总结

代码签名和配置文件这一套大概是一个 iOS 开发者必须处理的仅次于编码的最复杂的问题之一。
虽然了解每一个部分是怎么运作的很有帮助，但是要控制好所有这些设置和工具其实是一件很消耗时间的事情，特别是在一个开发团队中，到处发送证书和配置文件显然很不方便。虽然苹果在最近几次发布的 Xcode 中都尝试改善，但是我不是很确定每一项改动都起到了好的作用。处理代码签名是每个开发者必过的大坑。
虽然处理代码签名对于开发者来说非常繁琐，但不可否认正是它使得 iOS 对于用户来说是一个非常安全的操作系统。所以为代码签名和配置文件进行的这些麻烦设置并不是徒劳无功。

原文: Inside Code Signing