iOS应用签名原理

一、代码签名

代码签名是对可执行文件或脚本进行数字签名,用来确认软件在签名后未被修改或损坏的措施。和 数字签名原理一样,只不过签名的数据是代码而已。

简单的代码签名
  • 在iOS出来之前,以前的主流操作系统(Mac/Windows)软件随便从哪里下载都能运行,系统安全存在隐患,盗版软件,病毒入侵,静默安装等等.那么苹果希望解决这样的问题,要保证每一个安装到 iOS 上的 APP 都是经过苹果官方允许的,怎样保证呢? 就是通过代码签名。
  • 如果要实现验证.其实最简单的方式就是通过苹果官方生成非对称加密的一对公私钥.在iOS的系统中内置一个公钥,私钥由苹果后台保存,我们传APP到AppStore时,苹果后台用私钥对APP数据进行签名,iOS系统下载这个APP后,用公钥验证这个签名, 若签名正确,这个APP肯定是由苹果后台认证的,并且没有被修改过,也就达到了苹果的需求:保证安装的每一个APP都是经过苹果官方允许的.
  • 如果我们iOS设备安装APP只从App Store这一个入口这件事就简单解决了,没有任何复杂的东西,一个数字签名搞定.
  • 但是实际上iOS安装APP还有其他渠道.比如对于我们iOS开发者而言,我们是需要在开发APP时直接真机调试的.而且苹果还开放了企业内部分发的渠道,企业证书签名的APP也是需要顺利安装的.
  • 苹果需要开放这些方式安装APP,这些需求就无法通过简单的代码签名来办到了。
苹果的需求

那么我们来分析一下,它有些什么需求:
• 安装包不需要上传到App Store,可以直接安装到手机上.
• 苹果为了保证系统的安全性,又必须对安装的APP有绝对的控制权
• 经过苹果允许才可以安装
• 不能被滥用导致非开发APP也能被安装
为了实现这些需求,iOS签名的复杂度也就开始增加了,苹果这里给出的方案是双层签名.

二、双层代码签名

为了实现苹果验证应用的一些需求,iOS签名的复杂度也就开始增加了,苹果给出的方案是双层签名.

双层代码签名

iOS的双层代码签名流程这里简单梳理一下,这也不是最终的iOS签名原理.iOS的最终签名在这个基础上还要稍微加点东西.
首先这里有两个角色.一个是iOS系统 还有一个就是我们的Mac系统.因为iOS的APP开发环境在Mac系统下.所以这个依赖关系成为了苹果双层签名的基础.

  1. 在Mac系统中生成非对称加密算法的一对公钥\私钥(你的Xcode帮你代办了).这里称为公钥M 私钥M . M = Mac
  2. 苹果自己有固定的一对公私钥,跟之前App Store原理一样,私钥在苹果后台,公钥在每个iOS系统中.这里称为公钥A , 私钥A. A=Apple
  3. 把公钥M以及一些你开发者的信息,传到苹果后台(这个就是CSR文件),用苹果后台里的私钥A去签名公钥M。得到一份数据包含了公钥M 以及其签名,把这份数据称为证书。
  4. 在开发时,编译完一个APP后,用本地的私钥M(今后你导出的P12)对这个APP进行签名,同时把第三步得到的证书一起打包进 APP 里,安装到手机上。
  5. 在安装时,iOS系统取得证书,通过系统内置的公钥A,去验证证书的数字签名是否正确。
  6. 验证证书后确保了公钥M是苹果认证过的,再用公钥M去验证APP的签名,这里就间接验证了这个APP安装 行为是否经过苹果官方允许。(这里只验证安装行为,不验证APP 是否被改动,因为开发阶段 APP 内容总是 不断变化的,苹果不需要管。)

有了上面的过程,已经可以保证开发者的认证,和程序的安全性了。 但是,你要知道iOS的程序,主要渠道是要 通过APP Store才能分发到用户设备的,如果只有上述的过程,那岂不是只要申请了一个证书,就可以安装到所有 iOS设备了?

双层代码签名.png

三、描述文件

描述文件(Provisioning profile)一般包括三样东 西:证书、App ID、设备。当我们在真机运行或 者打包一个项目的时候,证书用来证明我们程序的安全性和合法性。

描述文件

苹果为了解决应用滥用的问题,所以苹果又加了两个限制.
第一限制在苹果后台注册过的设备才可以安装.
第二限制签名只能针对某一个具体的APP.
并且苹果还想控制App里面的iCloud/PUSH/后台运行/调试器附加这些权限,所以苹果把这些权限开关统一称为Entitlements(授权文件).并将这个文件放在了一个叫做Provisioning Profile(描述文件)文件中.
描述文件是在AppleDevelop网站创建的(在Xcode中填上AppleID它会代办创建),Xcode运行时会打包进入APP内.所以我们使用CSR申请证书时,我们还要申请一个东西!! 就是描述文件!
在开发时,编译完一个 APP 后,用本地的私钥M对这个APP进行签名,同时把从苹果服务器得到的 Provisioning Profile 文件打包进APP里,文件名为embedded.mobileprovision,把 APP 安装到手机上.最后系统进行验证。

描述文件.png

1、Mac电脑描述文件备份 存放位置
~/资源库/MobileDevice/Provisioning Profiles/

2、App描述文件存放位置

没有内容就编译一下

3、查看描述文件

  • 将描述文件拖入到任何一个Xcode项目中,然后点击一下,就可以查看了,查看完了,最后删除即可。
  • entitlements:权限
  • certificates:证书
  • provisioned devices:预分配的设备
  • SHA-1就是证书中hash值
最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 202,723评论 5 476
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 85,080评论 2 379
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 149,604评论 0 335
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,440评论 1 273
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,431评论 5 364
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,499评论 1 281
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 37,893评论 3 395
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,541评论 0 256
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,751评论 1 296
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,547评论 2 319
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,619评论 1 329
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,320评论 4 318
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 38,890评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,896评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,137评论 1 259
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 42,796评论 2 349
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,335评论 2 342

推荐阅读更多精彩内容