iOS App签名的原理

前言

相信很多同学对于iOS的真机调试,App的打包发布等过程中的各种证书、Provisioning ProfileCertificateSigningRequestp12的概念是模糊的,导致在实际操作过程中也很容易出错。好在Xcode8.0出现了Automatically manage signing,让我们在这步操作中减少了难度。虽然说我们在Xcode8.0之后可以选择让Xcode自动管理了,但是我们还是应该知道App签名的原理。本文尝试从原理出发,一步步推出为什么会有这么多概念,希望能有助于理解iOS App签名的原理和流程。

签名目的

先来看看苹果采用签名机制的目的。在iOS出来之前,在主流操作系统(Mac/Windows/Linux)上开发和运行软件是不需要签名的,软件随便从哪里下载都能运行,导致平台对第三方软件难以控制,盗版流行。苹果就希望在iOS平台对第三方App有绝对的控制权,一定要保证每一个安装到iOS上的App都必须经过苹果官方认证的。那么问题来了,怎么保证呢?就是通过签名这种机制。

非对称加密

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

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

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

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

若对数字d是怎样计算出来的感兴趣,可以详读这两篇文章:RSA 算法原理(一)(二)

数字签名

现在知道了有非对称加密算法这东西,那么数字签名是怎么回事呢? 数字签名的作用是我对某一份数据打了个标记,表示我认可了这份数据(签了个名),然后我发送给其他人,其他人可以知道这份数据是经过我认证的,数据没有被篡改过。 有了上述非对称加密,就可以实现这个需求:

  1. 首先用一种算法,算出原始数据的摘要,需要满足: a. 若原始数据有任何变化,计算出来的摘要值也要有变化。 b. 摘要要够短,这里常用的算法是MD5
  2. 生成一份非对称加密的公钥和私钥,私钥自己拿着,公钥发布出去。
  3. 对一份数据,算出摘要之后,用私钥加密这个摘要,得到一份加密后的数据,称为原始数据的签名。把它跟原始数据一起发送给用户。
  4. 用户收到数据和签名后,用公钥解密得到摘要,同时用户用同样的算法计算原始数据的摘要,比对这里计算出来的摘要和公钥解密签名得到的摘要是否相等,若相等则表示这份数据中途没有被篡改过,因为如果有篡改,摘要会变化。

之所以要有第一步计算摘要,是因为非对称加密的原理限制可加密的内容不能太大(不能大于上述n的位数,也就是一般不能大于1024位/2048位),于是若要对任意大的数据签名,就需要改成对它的特征值签名,效果是一样的。

好了,有了非对称加密和数字签名的基础之后,怎么样可以保证一份数据是经过某个地方认证的,来看看怎么样通过数字签名的机制来保证每一个安装到iOS的App都是经过苹果认证允许的。

最简单的签名

要实现这个需求很简单,最直接的方式,苹果官方生成一对公私钥,在iOS里内置一个公钥,私钥由苹果后台保存,我们传App上AppStore时,苹果后台用私钥对App数据进行签名,iOS系统下载这个App后,用公钥验证这个签名,若签名正确,这个App肯定由苹果后台认证的,并且没有被修改过,也就达到了苹果的需求:保证安装的每一个App都是经过苹果认证允许的。

如果我们iOS安装App只有从AppStore下载一种方式的话,这样就可以搞定了,没有任何复杂的东西,只有一个数字签名,非常简单的解决问题。 但是实际上,因为安装App除了从AppStore下载,我们还可以有三种方式安装一个App:

  1. 开发App时可以直接把开发中的应用安装进手机调试;
  2. In-House企业内部分发,可以直接安装企业证书签名后的App;
  3. AD-Hoc相当于企业分发的限制版,限制安装设备数量,较少用。

苹果要对用这三种方式安装的App进行控制,就有了新的需求,无法像上面这件简单了。

新的需求

我们先来看第一个,开发时安装App,它有两个需求:

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

为了实现这些需求,iOS签名的复杂度也就开始增加了。 苹果这里给出的方案是使用了双层签名,会比较绕,流程大概是这样的:

  1. 在你的Mac开发机器生成一对公私钥,这里称公钥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里iCloudpush、后台运行 等权限苹果都想控制,苹果把这些权限开关统称为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步下载回来的证书(存着本地公钥),在本地找到对应的私钥(第1步生成的),用本地私钥去签名App,并把Provisioning Profile文件命名为embedded.mobileprovision一起打包进去。这里对App的签名数据保存分为两部分,Mach-O可执行文件会把签名直接写入这个文件里,其他资源文件则会保存在_CodeSignature目录下。
  6. 第6、7步的打包和验证都是 Xcode 和 iOS 系统自动做的事。

这里再总结一下这些概念: 证书:内容是公钥或私钥,由其他机构对其签名组成的数据包。 Entitlements:包含了App权限开关列表。 CertificateSigningRequest:本地公钥。 .p12:本地私钥,可以导入到其他电脑。 Provisioning Profile:包含了 证书/Entitlements 等数据,并由苹果后台私钥签名的数据包。

其他发布方式

前面以开发包为例子说了签名和验证的流程,另外两种方式In-House企业签名和AD-Hoc流程也是差不多的,只是企业签名不限制安装的设备数,另外需要用户在iOS系统设置上手动点击信任这个企业才能通过验证。 而AppStore的签名验证方式有些不一样,前面我们说到最简单的签名方式,苹果在后台直接用私钥签名App就可以了,实际上苹果确实是这样做的,如果去下载一个AppStore的安装包,会发现它里面是没有embedded.mobileprovision文件的,也就是它安装和启动的流程是不依赖这个文件,验证流程也就跟上述几种类型不一样了。

据猜测,因为上传到AppStore的包苹果会重新对内容加密,原来的本地私钥签名就没有用了,需要重新签名,从AppStore下载的包苹果也并不打算控制它的有效期,不需要内置一个embedded.mobileprovision去做校验,直接在苹果用后台的私钥重新签名,iOS安装时用本地公钥验证App签名就可以了。

那为什么发布AppStore的包还是要跟开发版一样搞各种证书和Provisioning Profile?猜测因为苹果想做统一管理,Provisioning Profile里包含一些权限控制,AppID 的检验等,苹果不想在上传AppStore 包时重新用另一种协议做一遍这些验证,就不如统一把这部分放在 Provisioning Profile里,上传AppStore时只要用同样的流程验证这个 Provisioning Profile是否合法就可以了。

所以 App 上传到AppStore后,就跟你的 证书 / Provisioning Profile 都没有关系了,无论他们是否过期或被废除,都不会影响AppStore 上的安装包。

到这里 iOS 签名机制的原理和主流程大致说完了,希望能对理解苹果签名和排查日常签名问题有所帮助。

致谢

最后,感谢各位能改耐心看完,也希望能够对大家带来帮助。同时也感谢原作者的文章。本篇文章主要是为了做笔记。

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏安全领域

在微控制器和物联网上使用JavaScript:SSL / TLS

在今天的这篇文章中,我们回到Particle Photon上来解决他的一个最大的缺点:缺少TLS支持,接下来我们将详细介绍如何添加这一功能。

82314
来自专栏即时通讯技术

一分钟理解 HTTPS 到底解决了什么问题1、引言2、HTTPS相关文章3、对HTTPS性能的理解4、传统HTTP的安全性问题5、HTTPS 背后的密码学附录:更多安全方面的文章

本文原作者“虞大胆的叽叽喳喳”,原文链接:jianshu.com/p/8861da5734ba,感谢原作者。

1182
来自专栏农夫安全

用了13年的wpa2协议出漏洞,新型KRACH攻击手法.

介绍 研究人员发现WPA2的严重弱点,WPA2是保护所有现代受保护的Wi-Fi网络的协议。内的受害者的范围内的攻击者可以利用使用这些弱点.具体来说,攻击者可以使...

3595
来自专栏即时通讯技术

一文读懂Https的安全性原理、数字证书、单项认证、双项认证等

本文引用了作者Smily(博客:blog.csdn.net/qq_20521573)的文章内容,感谢无私分享。

4312
来自专栏企鹅号快讯

年度盘点:2017 SSL证书行业大事件

2017年Chrome和火狐浏览器逐步升级对HTTP页面的“不安全”警告,并计划在2018年再次扩大警告范围,Safari也加入了警告HTTP页面“不安全”的行...

2177
来自专栏陈泽滨的专栏

关于 iOS 证书,你必须了解的知识

从事iOS开发几年,越来越发现,对iOS应用开发到发布过程中必不可少的一环,证书签名相关部分,却只是一知半解。本文从iOS证书体系的基本构成模块 入手,一步步解...

2.4K1
来自专栏IMWeb前端团队

开发工具颜色搭配 —— 折腾 mac 系统

上手 mac 之前,我调查了好久,mac 比起 windows 到底有什么优势?我想说的是,调查并没有什么软用,只有上手一台体验才有意义。 这会是一个系列,作为...

2579
来自专栏腾讯Bugly的专栏

iOS App 签名的原理

本文来自 微信读书 团队博客:http://wereadteam.github.io/ 导语 iOS 签名机制挺复杂,各种证书,Provisioning Pro...

6096
来自专栏WeTest质量开放平台团队的专栏

苹果强制使用HTTPS传输后APP开发者必须知道的事

作者asher,加入腾讯多年,主要负责腾讯CDN和云业务的HTTPS开发和运营工作。

1612
来自专栏Wordpress专用主机|主题模板|必备插件

WORDPRESS网站如何申请SSL证书并实现全站HTTPS

最近在一些Wordpress兴趣群里,发现很多WP爱好者的博客并没有申请SSL证书实现全站HTTPS化。显然,作为一名站长/博主,这是不应该的。所以本人就分享下...

5173

扫码关注云+社区

领取腾讯云代金券