一、iOS应用签名原理
1.1 代码签名
1.1.1 简单的代码签名
- 在iOS出来之前,以前的主流操作系统(Mac/Windows)软件随便从哪里下载都能运行,系统安全存在隐患,盗版软件,病毒入侵,静默安装等等.那么苹果希望解决这样的问题,要保证每一个安装到 iOS 上的 APP 都是经过苹果官方允许的,怎样保证呢?就是通过代码签名。
- 如果要实现验证.其实最简单的方式就是通过苹果官方生成非对称加密的一对公私钥.在iOS的系统中内置一个公钥,私钥由苹果后台保存,我们传APP到AppStore时,苹果后台用私钥对APP数据进行签名,iOS系统下载这个APP后,用公钥验证这个签名,若签名正确,这个APP肯定是由苹果后台认证的,并且没有被修改过,也就达到了苹果的需求:保证安装的每一个APP都是经过苹果官方允许的.
- 如果我们iOS设备安装APP只从App Store这一个入口这件事就简单解决了,没有任何复杂的东西,一个数字签名搞定.
- 但是实际上iOS安装APP还有其他渠道.比如对于我们开发者iOSER而言,我们是需要在开发APP时直接真机调试的.而且苹果还开放了企业内部分发的渠道,企业证书签名的APP也是需要顺利安装的. 苹果需要开放这些方式安装APP,这些需求就无法通过简单的代码签名来办到了。
1.1.2 苹果的需求
1.2 双层代码签名
1.2.1 双层代码签名
- iOS的双层代码签名流程这里简单梳理一下,这也不是最终的iOS签名原理.iOS的最终签名在这个基础上还要稍微加点东西.
- 首先这里有个两个角色,一个是iOS系统,还有一个就是我们的Mac系统,因为 iOS的App开发环境在Mac系统下.所以这个依赖关系成为了苹果双层签名的基础.
1.3 描述文件
- 描述文件(Provisioning Profile)一般包括三样东西: 证书、AppID、设备.当我们在真机运行或者打包一个项目的时候,证书用来证明我们程序的安全性和合法性.
- 苹果为了解决应用滥用的问题,所以又加了两个限制.
- 第一个限制在苹果后台注册过的设备才可以安装
- 第二个限制签名只能针对某一个具体的App
- 并且苹果还想控制App里面的iCloud/Push/后台运行/调试器附加这些权限,所以苹果把这些权限开关统一称为Entitlements(授权文件),并将这个文件放在了一个叫做Provisioning Profile(描述文件)文件中.
- 描述文件是在AppleDeveloper网站创建的(在Xcode中填上AppID它会代办创建),Xcode运行时会打包进入App内.所以我们使用CSR申请证书时,我们还要申请一个东西,就是描述文件.
- 在开发时,编译完一个App后,用本地的私钥M对这个App进行签名,同时把从苹果服务器得到的Provisioning Profile文件打包进App里,文件名为enbedded.mobileprovision, 把App安装到手机上,最后系统进行验证.
苹果签名原理