微言 | wyanassert
个人工作总结

博客内容主要是 iOS 技术分享, 以及随笔.

iOS App 签名

发表于 分类于
本文字数： 4.5k 阅读时长 ≈ 4 分钟

我们从 AppStore 下载的 App 一般都是被加密过的, 这是因为 iOS2.0时引入了强制代码签名(Mandatory Code Signing)技术, 只有被苹果设备认可的证书签名的代码能够被执行.
但是跟签名相关的概念十分繁杂, 各种证书，Provisioning Profile，entitlements，CertificateSigningRequest，p12，AppID，概念一堆，也很容易出错, 这里稍微梳理一下相关概念

签名

非对称加密算法

通常我们说的签名就是数字签名，它是基于非对称加密算法实现的。对称加密是通过同一份密钥加密和解密数据，而非对称加密则有两份密钥，分别是公钥和私钥，用公钥加密的数据，要用私钥才能解密，用私钥加密的数据，要用公钥才能解密。

简单说一下常用的非对称加密算法 RSA 的数学原理，理解简单的数学原理，就可以理解非对称加密是怎么做到的，为什么会是安全的：

  1. 选两个质数 p 和 q，相乘得出一个大整数n，例如 p = 61，q = 53，n = pq = 3233
  2. 选 1-n 间的随便一个质数e，例如 e = 17
  3. 经过一系列数学公式，算出一个数字 d，满足：
    • 通过 n 和 e 这两个数据一组数据进行数学运算后，可以通过 n 和 d 去反解运算，反过来也可以。
    • 如果只知道 n 和 e，要推导出 d，需要知道 p 和 q，也就是要需要把 n 因数分解。

上述的 (n,e) 这两个数据在一起就是公钥，(n,d) 这两个数据就是私钥，满足用私钥加密，公钥解密，或反过来公钥加密，私钥解密，也满足在只暴露公钥 (只知道 n 和 e)的情况下，要推导出私钥 (n,d)，需要把大整数 n 因数分解。目前因数分解只能靠暴力穷举，而 n 数字越大，越难以用穷举计算出因数 p 和 q，也就越安全，当 n 大到二进制 1024 位或 2048 位时，以目前技术要破解几乎不可能，所以非常安全。

若对数字 d 是怎样计算出来的感兴趣，可以详读这两篇文章：RSA算法原理（一） RSA算法原理（二）

数字签名

数字签名的作用是我对某一份数据打个标记，表示我认可了这份数据（签了个名），然后我发送给其他人，其他人可以知道这份数据是经过我认证的，数据没有被篡改过。
有了上述非对称加密算法，就可以实现这个需求：

  1. 首先用MD5 等算法, 算出原始数据的摘要。
  2. 生成一份非对称加密的公钥和私钥，私钥我自己拿着(不能发送出去), 公钥可以被发送出去.
  3. 数据算出摘要后，用私钥加密摘要，得到一份加密后的数据，称为原始数据的签名。把它跟原始数据一起发送给用户。
  4. 用户收到数据和签名后，用公钥解密得到摘要, 对比自行计算的摘要, 相同则表示数据没有被篡改

复杂的证书

有了数字签名后, 实际已经可以保证 App 从 AppStore 下载后不被篡改

  1. App 上传给苹果的服务器,
  2. 苹果用私钥加密, 然后下发
  3. 手机下载数据后用公钥解密, 校验无误就可以运行

但是不是所有的 app 都是从苹果的服务器(AppStore)下载的, 比如自己开发 app 时候是从开发机打包传到手机的, 蒲公英等内测分发是从第三方服务器下载的, 这些 case 不可能都把包发给苹果的服务器.

所以苹果需要一个机制:

  1. 安装包不需要传到苹果服务器，可以直接安装到手机上。如果你编译一个 APP 到手机前要先传到苹果服务器签名，这显然是不能接受的。
  2. 苹果必须对这里的安装有控制权，包括
    • 经过苹果允许才可以这样安装。
    • 不能被滥用导致非开发app也能被安装。

苹果这里给出的方案是使用了双层签名，会比较绕，流程大概是这样的：

  1. 在开发机器生成一对公私钥，这里称为公钥L，私钥L。(L:Local)
  2. 苹果自己有固定的一对公私钥，跟上面 AppStore 例子一样，私钥在苹果后台，公钥下发给了每个 iOS 设备上。这里称为公钥A，私钥A。(A:Apple)
  3. 把公钥 L 传到苹果后台，用苹果后台里的私钥 A 去签名公钥 L。得到一份数据包含了公钥 L 以及其签名，把这份数据称为证书。
  4. 在开发时，编译完一个 APP 后，用本地的私钥 L 对这个 APP 进行签名，同时把第三步得到的证书一起打包进 APP 里，安装到手机上。
  5. 在安装时，iOS 系统取得证书，通过系统内置的公钥 A，去验证证书的数字签名是否正确。
  6. 验证证书后确保了公钥 L 是苹果认证过的，再用公钥 L 去验证 APP 的签名，这里就间接验证了这个 APP 安装行为是否经过苹果官方允许。（这里只验证安装行为，不验证APP 是否被改动，因为开发阶段 APP 内容总是不断变化的，苹果不需要管。）

上述流程只解决了上面第一个需求，也就是需要经过苹果允许才可以安装，还未解决第二个避免被滥用的问题。怎么解决呢？苹果再加了两个限制，一是限制在苹果后台注册过的设备才可以安装，二是限制签名只能针对某一个具体的 APP。

在上述第三步，苹果用私钥 A 签名我们本地公钥 L 时，实际上除了签名公钥 L，还可以加上无限多数据，这些数据都可以保证是经过苹果官方认证的，不会有被篡改的可能。
可以想到把 允许安装的设备 ID 列表 和 App对应的 AppID 等数据，都在第三步这里跟公钥L一起组成证书，再用苹果私钥 A 对这个证书签名。在最后第 5 步验证时就可以拿到设备 ID 列表，判断当前设备是否符合要求。根据数字签名的原理，只要数字签名通过验证，第 5 步这里的设备 IDs / AppID / 公钥 L 就都是经过苹果认证的，无法被修改，苹果就可以限制可安装的设备和 APP，避免滥用。

最终流程

到这里这个证书已经变得很复杂了，有很多额外信息，实际上除了 设备 ID / AppID，还有其他信息也需要在这里用苹果签名，像这个 APP 里 iCloud / push / 后台运行 等权限苹果都想控制，苹果把这些权限开关统一称为 Entitlements，它也需要通过签名去授权。

实际上一个“证书”本来就有规定的格式规范，上面我们把各种额外信息塞入证书里是不合适的，于是苹果另外搞了个东西，叫 Provisioning Profile，一个 Provisioning Profile 里就包含了证书以及上述提到的所有额外信息，以及所有信息的签名。

所以整个流程稍微变一下，就变成这样了：

因为步骤有小变动，这里我们不辞啰嗦重新再列一遍整个流程：

  1. 在你的 Mac 开发机器生成一对公私钥，这里称为公钥L，私钥L。L:Local
  2. 苹果自己有固定的一对公私钥，跟上面 AppStore 例子一样，私钥在苹果后台，公钥在每个 iOS 设备上。这里称为公钥A，私钥A。A:Apple
  3. 把公钥 L 传到苹果后台，用苹果后台里的私钥 A 去签名公钥 L。得到一份数据包含了公钥 L 以及其签名，把这份数据称为证书。
  4. 在苹果后台申请 AppID，配置好设备 ID 列表和 APP 可使用的权限，再加上第③步的证书，组成的数据用私钥 A 签名，把数据和签名一起组成一个 Provisioning Profile 文件，下载到本地 Mac 开发机。
  5. 在开发时，编译完一个 APP 后，用本地的私钥 L 对这个 APP 进行签名，同时把第④步得到的 Provisioning Profile 文件打包进 APP 里，文件名为 embedded.mobileprovision，把 APP 安装到手机上。
  6. 在安装时，iOS 系统取得证书，通过系统内置的公钥 A，去验证 embedded.mobileprovision 的数字签名是否正确，里面的证书签名也会再验一遍。
  7. 确保了 embedded.mobileprovision 里的数据都是苹果授权以后，就可以取出里面的数据，做各种验证，包括用公钥 L 验证APP签名，验证设备 ID 是否在 ID 列表上，AppID 是否对应得上，权限开关是否跟 APP 里的 Entitlements 对应等。
    开发者证书从签名到认证最终苹果采用的流程大致是这样，还有一些细节像证书有效期/证书类型等就不细说了。

苹果证书流程和我们的操作

上面的步骤对应到我们平常具体的操作和概念是这样的：

  1. 第 1 步对应的是 keychain 里的 “从证书颁发机构请求证书”，这里就本地生成了一堆公私钥，保存的 CertificateSigningRequest 就是公钥，私钥保存在本地电脑里。
  2. 第 2 步苹果处理，不用管。
  3. 第 3 步对应把 CertificateSigningRequest 传到苹果后台生成证书，并下载到本地。这时本地有两个证书，一个是第 1 步生成的，一个是这里下载回来的，keychain 会把这两个证书关联起来，因为他们公私钥是对应的，在XCode选择下载回来的证书时，实际上会找到 keychain 里对应的私钥去签名。这里私钥只有生成它的这台 Mac 有，如果别的 Mac 也要编译签名这个 App 怎么办？答案是把私钥导出给其他 Mac 用，在 keychain 里导出私钥，就会存成 .p12 文件，其他 Mac 打开后就导入了这个私钥。
  4. 第 4 步都是在苹果网站上操作，配置 AppID / 权限 / 设备等，最后下载 Provisioning Profile 文件。
  5. 第 5 步 XCode 会通过第 3 步下载回来的证书（存着公钥），在本地找到对应的私钥（第一步生成的），用本地私钥去签名 App，并把 Provisioning Profile 文件命名为 embedded.mobileprovision 一起打包进去。这里对 App 的签名数据保存分两部分，Mach-O 可执行文件会把签名直接写入这个文件里，其他资源文件则会保存在 _CodeSignature 目录下。
    第 6 - 7 步的打包和验证都是 Xcode 和 iOS 系统自动做的事。

这里再总结一下这些概念：

  1. 证书：内容是公钥或私钥，由其他机构对其签名组成的数据包。
  2. Entitlements：包含了 App 权限开关列表。
  3. CertificateSigningRequest：本地公钥。
  4. p12：本地私钥，可以导入到其他电脑。
  5. Provisioning Profile：包含了 证书 / Entitlements 等数据，并由苹果后台私钥签名的数据包。

https 非对称加密流程

https 中非对称加密具体流程是怎么样的

  1. 客户端发起 HTTPS 请求：客户端向服务器发送一个 HTTPS 请求。这个请求中包含了客户端支持的加密算法和哈希算法。

  2. 服务器回应公钥证书：服务器收到请求后，返回一个带有公钥证书的 HTTPS 响应。这个证书包含了服务器的公钥和一些元数据，如颁发机构、域名等。

  3. 客户端验证证书：客户端使用预置的 CA（Certificate Authority）公钥来验证服务器的证书。CA 公钥是预安装在客户端的，用于验证服务器的身份。

  4. 生成随机秘钥：如果证书验证通过，客户端会生成一个随机的对称加密秘钥。

  5. 使用公钥加密秘钥：客户端使用服务器的公钥对刚刚生成的秘钥进行加密，然后将加密后的秘钥发送给服务器。

  6. 服务器使用私钥解密秘钥：服务器收到加密的秘钥后，使用自己的私钥进行解密，得到了客户端生成的秘钥。

  7. 双方使用秘钥进行通信：现在，客户端和服务器都知道了同一份秘钥，以后的通信就可以使用这个秘钥进行加密和解密。

参考文档

iOS App 签名的原理
图解iOS签名背后的原理
深度长文：细说iOS代码签名
【WWDC22 10077】验证码的替代者—私有访问凭证
MachO 代码签名剖析
iOS重签名探索
不越狱使用 Xcode 调试第三方应用

-------------本文结束感谢您的阅读-------------
相关文章

欢迎关注我的其它发布渠道