浅析 iOS App 签名机制


苹果服务器会用私钥(private-key)对 App 数据进行签名,iOS 系统下载这个 App 后,用设备自带的公钥(public-key)验证这个签名,若签名正确,说明这个……上。 不过,苹果依然要求对 App 的安装有控制权,即: ① 必须经过苹果允许才可以安装; ② 权利不能被滥用,非开发状态的 App 不允许安装。 为了实现这些苛刻的要求,iOS 签名的复杂度也就增加……了,苹果给出的解决方案是使用双重签名,大概流程见下图: 在开发机器(如 iMac、MacBook Pro 及 Mac mini)上创建一个密钥对 (公钥 local / 私钥 local)。即 通过……,225,0,1,为了确保 iOS 平台对 App 拥有绝对的控制权,不至出现盗版软件盛行的局面,Apple 采取了签名机制。

预备知识

1.非对称加密算法

讨论 iOS App 签名机制之前,必须先了解一下非对称加密机制。顾名思义,非对称加密是相对对称加密来说的,前者需要两个密钥,即私钥和与之匹配的公钥,用其中之一加密,必须用另一个解密;而后者只有一个密钥,如下图:

2.数字签名

说完了非对称加密,我们再来看看签名是什么东东吧。签名就表示认可,它的作用是对一份数据做一个标记,然后将这份数据发给接收方,接收方通过上边的标记就可以确认这份数据是否曾被篡改过的。基本的签名及验证签名过程如下:

首先,生成一对非对称加密使用的密钥 (公钥+私钥),私钥留在服务端,公钥发布出去;

然后,使用 HASH 算法 (最常用如 MD5) 得到原始数据的一个摘要,然后用私钥加密这个摘要,加密后的数据即称为原始数据的签名,把它和原始数据一起发送给用户;

最后,用户接收到原始数据和签名后,使用服务端发布出来的公钥解密签名,得到一个摘要 A。同时,用户使用同样的 HASH 算法生成原始数据的摘要 B,然后比较摘要 A 和 摘要 B,如果相等,说明数据未被篡改,否则,数据就被改动过。

补充:HASH 算法的特点是:①不可逆,即不能通过结果得到原始数据;②运算结果的长度固定,且比较短。

iOS App 的签名机制

iOS App 目前有以下几种安装方式:

1.AppStore 下载的 App可以在手机上安装。

2.开发过程中,可以直接 App 安装进手机进行调试。

3.In-House 企业内部分发,可以直接安装企业证书签名后的 APP。

4.AD-Hoc 相当于企业分发的限制版,它限制了安装设备的数量。

下面以前 2 种情况为例,讨论一下 iOS App 的签名机制。

1.AppStore

这种方式的实现比较简单,由苹果官方生成一对密钥(public-key/private-key),公钥 (public-key)内置到 iOS 设备里,私钥(private-key)由苹果服务器保存。

当我们往 AppStore 上传 App 时,苹果服务器会用私钥(private-key)对 App 数据进行签名,iOS 系统下载这个 App 后,用设备自带的公钥(public-key)验证这个签名,若签名正确,说明这个 App 肯定是由苹果认证的,并且没有被修改过,这样就保证了安装的每一个 App 都是经过苹果官方允许的。

补充:把 App 上传 AppStore 后,苹果还会对 App 进行加密。

2.开发阶段

当开发 App 的时候,需要频繁的安装 App 到手机上,如果每次都先将 App 包传给苹果服务器,得到授权后才可以安装,那对开发者来说简直是灾难,而事实上,苹果也确实没有这么做,而是可以直接安装在手机上。

不过,苹果依然要求对 App 的安装有控制权,即:

① 必须经过苹果允许才可以安装;

② 权利不能被滥用,非开发状态的 App 不允许安装。

为了实现这些苛刻的要求,iOS 签名的复杂度也就增加了,苹果给出的解决方案是使用双重签名,大概流程见下图:

在开发机器(如 iMac、MacBook Pro 及 Mac mini)上创建一个密钥对 (公钥 local / 私钥 local)。即 通过 keychain 里边的 “从证书颁发机构请求证书” 创建,私钥存在本机,公钥就是得到的 CertificateSigningRequest。

苹果自己有固定的一个密钥对 (公钥 Apple / 私钥 Apple),跟上面 AppStore 例子一样,私钥在苹果服务端,公钥在每个 iOS 设备上。

把公钥 local 传到苹果服务端,用苹果服务端的私钥 Apple 去签名公钥 local,得到一份证书,其中包含了公钥 local 及其签名。

在苹果后台申请 AppID,配置好设备 ID 列表和 App 可使用的权限,然后将这些数据连同上一步获得的证书一起用私钥 A 签名,把数据和签名合成一个 Provisioning Profile 文件,即通常所说的 xxx.mobileprovision 文件,下载到本地的开发机器。

在开发时,编译完一个 App 后,用私钥 local 对这个 App 进行签名,同时把上一步得到的 xxx.mobileprovision 打包进 App 里,文件更名为 embedded.mobileprovision,然后把 App 安装到手机上。

在安装时,iOS 系统取得证书,通过 iOS 设备内置的公钥 Apple,去验证 embedded.mobileprovision 的数字签名是否正确。

如果上一步验证签名成功,就可以取出 embedded.mobileprovision 里面的数据,做各种验证,具体包括:用公钥 local 验证 App 签名,验证当前 iOS 设备的 ID 是否在 设备 IDs 上,AppID 与当前 App 的 ID 是否对应得上,权限是否跟 App 里 Entitlements 的描述一致。

In-House 企业内部分发和 AD-Hoc 原理相似,只是企业内部分发不限制安装的设备数量,另外需要用户在 iOS 系统设置里边手动点击信任这个企业才能通过验证。

以上就是我所了解的 iOS App 的签名机制,其实只是个大概,还有许多细节可以深挖,以后再加吧!

 

企业签名QQ:281442504

分享到