iOS签名机制与证书介绍
ios 签名机制与证书
声明
纯粹就是总结,很多地方跟参考资料一样,就是自己手动打一遍,自己亲自画个图增加理解和加强记忆力,而不只是复制粘贴
ios 打包流程也不在此叙述,相信很多人已经对照过各种图文并茂的文章一一操作过
数字签名
加密">非对称加密
即加密密钥与解密密钥不同,且成对出现
对外公开的称为公钥,这对密钥生成者才拥有的称为私钥
通过私钥加密的密文只能通过公钥解密,反之亦然
例如,rsa算法,非对称加密加解密比较耗时,实际使用中,往往与对称加密和摘要算法结合使用
经典用法
防止中间攻击:接收方将公钥公布-》发送方通过该公钥将明文加密-》传输给接收方-》接收方使用私钥解密,通常用于交换对称密钥(由于非接收方无私钥,无法截获)
身份验证和防止篡改:私钥加密授权明文-》将明文+加密后的密文+公钥一并发送给接收方-》接收方用公钥解密密文,再与明文对比是否一致,以此判断是否被篡改,用于数字签名
摘要算法
将任意长度文本通过一个算法得到一个固定长度的文本。
源文本不同,计算结果必然不同
无法从结果反推源
例如,md5和sha算法
数字签名
非对称加密与摘要算法的结合
结合摘要算法是因为非对称加密的原理限制可加密的内容不能太大
数字签名验证过程
情景:有一段授权文本,需要发布,要防止中途篡改内容,保证完整性与合法性
发送方:
1. 授权文本-》摘要算法-》得到摘要
2. 私钥加密摘要得到密文
3. 将源授权文本+密文+公钥一并发布
验证方:
1. 用公钥解密密文得到摘要a
2. 将源授权文本-》摘要算法-》得到摘要b
3. 对比摘要a与摘要b是否一致
签名机制与验证
最简单的签名(app store 下载的签名机制)
当app 提交审核通过后,apple会对app重签名,所以从app store下载的app都是苹果的官方签名
流程如下:
apple 官方有自己固定的一对公钥和私钥,私钥a存在apple后台,公钥a存在ios设备
app审核通过后,apple后台用私钥a对其进行重签名
app下载到ios设备后,ios设备内置的公钥a会对app的签名进行验证 如果验证通过,则可运行,否则不能
当然除了这个方式,还有一下三种方式安装一个app:
1. 开发时,直接通过usb将应用安装到手机进行调试;
2. in-house 企业内部分发,可直接安装企业证书签名的app;
3. ad-hoc 相当于企业分发的限制版,限制安装设备数量。
双层签名
对与开发调试安装app时,有两个需求:
1. 安装包无需上传到apple服务器;
2. 必须经过apple允许,且不能被滥用导致非开发app也能被安装
流程如下:
在mac上生成一对公私钥,分别为公钥l,私钥l
apple 官方有自己固定的一对公钥和私钥,私钥a存在apple后台,公钥a内置在ios设备
把公钥l 上传apple后台,apple后台用私钥a对公钥l进行签名,将得到的签名+公钥l打包起来,称为证书 开发时,编译完一个app后,用本地私钥l对app进行签名,然后把3中的证书、app和app签名一起打包安装到手机上。 ios设备内置的公钥a对证书中签名进行验证 如果5中验证通过,再用证书中的公钥l对app签名进行验证,从而间接保证app安装是官方允许的
双层签名+限制
上述流程只解决了需要apple允许才能安装,但还未解决避免被滥用的问题。
在此,苹果加了两个限制,1.限制设备,2.限制签名只针对某一具体app。
流程基本如上,只是添加了设备ids和appid:
第三步:把公钥l 上传apple后台,apple后台用私钥a对(公钥l+设备ids+appid)进行签名,将得到的签名+公钥l打包起来,成为证书
第五步:ios设备内置的公钥a对证书中签名进行验证,同时将设备ids判断当前设备是否符合要求,appid验证app是否一致
开发者证书签名到认证最终流程
上述证书有很多额外信息,实际上出了 设备ids/appid,还是其他信息,比如icloud/push/后台运行等权限,这些权限开关统称为 entitlements,它也需要通过签名去授权,这些额外信息都塞在证书里是不合适的,所以就有一个叫 provisioning profile 的东西。
provisioning profile = 证书 + 上述额外信息 + 所有信息的签名
最终流程如下:
在mac上生成一对公私钥,分别为公钥l,私钥l
apple 官方有自己固定的一对公钥和私钥,私钥a存在apple后台,公钥a内置在ios设备
把公钥l 上传apple后台,apple后台用私钥a对公钥l进行签名,将得到的签名+公钥l打包起来,称为证书 在苹果后台申请appid,配置好设备ids, entitlements,这些额外信息+3中的证书组成的数据用私钥a签名,最后证书+额外信息+签名组成 provisioning profile 文件,下载到mac本地 开发时,编译完一个app后,用本地私钥l对app进行签名,然后把4中的provisioning profile文件打包进app里,文件名为embedded.mobileprovision,安装到手机上。 安装时,ios设备内置的公钥a对embedded.mobileprovision的数字签名进行验证,同时对里面的证书的签名也会验证 如果6中验证通过,确保了embedded.mobileprovision的数据是苹果授权后,再取出里面数据做各种验证,包括公钥l对app签名进行验证,验证设备id,appid,权限开关
概念与操作
上述步骤与平常具体操作与概念如下:
keychain 里的“从证书颁发机构请求证书”,本地生成一对公私钥,保存的certificatesigningrequest(csr)即公钥l,私钥l保存在电脑本地
苹果处理
在member center把certificatesigningrequest上传到苹果后台生成证书,下载到本地(因为私钥是本地mac持有,所以团队开发时,可在keychain导出私钥,存为.p12文件,其他mac即可导入这个私钥) 在member center配置appid/设备uuid/entitlements, 生成对应的 provisioning profile 文件,并下载到本地
打包编译时,xcode会根据3中的证书,用对应该证书的本地私钥l对app进行签名,并把4中的 provisioning profile 文件命名为 embedded.mobileprovision 一起打包进去。这里对app的签名数据分两部分,mach-o 可执行文件把签名直接写进这个文件,其他资源文件则保存在_codesignature目录下
6到7的打包验证是xcode和ios的事
其他发布方式(in-house和ad-hoc)流程与开发包签名验证流程差不多,in-house不限制安装的设备数
上一篇: 群里有个妹纸天天只发一个表情