iOS的签名机制很杂乱,各种证书,Provision Profile,entitlements,CertificateSigningRequest,p12,AppID,这篇文章我从概念动身,一步一步推出为什么会有这么对概念,希望能有助于理解iOS的App签名的原理,以及UDID签名跟超级签名究竟那个安稳。更安稳的udid签名跟超级签名就在【云签】在iOS出来之前,在干流操作体系(Mac,Windows,Linux)上开发和运转软件是不需求签名的,软件随意从哪里下载都能运转,导致平台对第三方软件很难操控,盗版盛行。苹果希望处理这样的问题,希望iOS平台对第三方App有肯定操控权,一定要确保每一个装置到iOS上的App都是经过苹果官方答应的,怎样确保呢?便是经过签名机制。
要实现这个需求很简单,最直接的方法,苹果官方生成一对公私钥,私钥由苹果后台保管,公钥内置到iOS设备里,在咱们将App上传到App Store上时,苹果后台运用私钥对App进行签名,iOS设备下载这个使用后,用公钥验证这个签名,若签名正确,则阐明这个App是经过苹果后台认证的,而且没有被修改过,这样也就达到了苹果的目的:确保iOS设备装置的每一个APP都是经过苹果官方答应的。
如果咱们的iOS设备装置App只经过App Store这一种方法的话,那么问题到这儿就现已处理了,可是实际上除了从App Store上下载使用,还能够以一下三种方法装置一个APP:
1.作为开发者,开发App时直接进行真机调试。
2.In-House 企业内部分发,能够直接装置企业证书签名后的App。
3.AD-Hoc 适当所以企业分发的约束版,约束装置设备数量。
苹果要对这三种方法装置的APP进行孔子,就无法像上面这样简单了。
咱们先来看第一个,开发时装置APP,它有两个需求:
1.装置包不需求传到苹果服务器,能够直接装置到手机上。
2.苹果有必要对这个装置过程有操控权,包括:
a.经过苹果答应才能够这样装置
b.不能被乱用导致非开发App也能被装置。
为了满足这个需求,iOS签名的杂乱度也就开始增加了。
苹果给出的计划是运用双层签名,有一点绕,流程大概是下图这样:
1.在咱们开发运用的Mac上生成一对公钥和私钥,称为公钥,私钥L。L:Local。
2.苹果有固定的一对公钥和私钥,私钥在自己后台保存,公钥内置到了iOS设备里,称为公钥,私钥A。A:Apple。
3.把公钥L上传到苹果后台,用苹果后台的私钥A去签名公钥L。得到了一份数据包括公钥L及其签名,这份数据称为证书。
4.在开发时,编译完一个APP后,用第一步生成的私钥L去签名这个App,一同把第三步得到的证书一同打包进App里,装置到手机上。
5.在装置时,iOS体系取得证书,经过体系内置的公钥A,去验证证书的数字签名是否正确。
6.验证证书后确保了公钥L是苹果认证的,再用公钥L去验证App的签名,这样就间接验证了这个App装置行为是否经过苹果答应。
上述流程只处理了上面的第一个需求,也便是需求经过苹果的答应才能够装置,还未处理第二个避免被乱用的问题。怎样处理呢?苹果加了两个约束,一个是约束在苹果后天注册过的设备才能够装置,二是约束签名只能针对某个具体的App。
在上述的第三步中,苹果用私钥A去签名咱们本地公钥L时,实际上除了签名公钥L,还能够加上许多数据,这些数据都能够确保是经过苹果官方认证的,不会有被篡改的可能,那么咱们就能够把AppID和设备ID增加进去:
把答应装置的设备ID和APP对应的AppID等数据,都在第三步这儿和公钥L一同,被私钥A签名,一同组成证书。在第五步验证时就能够拿到设备ID列表,判断当时设备是否符合要求。
到这儿这个证书现已变得很杂乱了,有许多额定的信息,udid签名跟超级签名究竟哪个更安稳实际上【云签】便是不错的挑选。实际上除了设备ID,AppID,还有其他信息也需求用苹果签名,像App里边的iCloud,后天运转等苹果都想操控,苹果把这些权限开关统称为entitlements,它也需求经过签名去授权。
可是一个证书本来就有标准的格式,咱们把这些杂七杂八的额定信息赛入证书是不合适的,因而苹果另外搞了一个东西叫Provisioning Profile,一个Provisioning Profile里边就包括了证书以及上述提到的一切额定信息,以及一切信息的签名。
1.在你的Mac上生成一对公钥和私钥,称为公钥L和私钥L。
2.苹果自己有一对固定的公钥和私钥,私钥在苹果后台,公钥内置在iOS设备中,别离称为私钥A和公钥A。
3.把公钥L传到苹果后天,用苹果后天的私钥A去签名公钥L,得到一份数据包括公钥L和签名,这份数据称为证书。
4.在苹果后台恳求好AppID,装备好设备ID列表,App权限开关,再加上第三步的证书,组成的数据用苹果后天的私钥A签名,把数据和签名一同组成一个Provisioning Profile文件,下载到本地Mac。
5.在开发时,编译完一个App后,用本地的私钥L对这个App进行签名,一同把第四步生成的Provisionning Profile一同打包进App里,文件名为embeded.mobileprovision,把App装置到手机。
6.在装置时,就能够运用iOS设备里内置的公钥A来验证Provisioning Profile的数字签名是否正确。
7.如果数字签名没有问题,那么就能确保设备ID,AppID,entitlements,和App都是经过苹果认证的,能够装置到iOS设备上。
1.第一步对应的是从keychain里“从这证书颁发组织恳求证书”,这样就在本地生成了一对公私钥,保存的额CertificateSigningRequest便是公钥,公钥保存在本地电脑里。
2.第二步苹果处理,不必管。
3.第三步把CertificateSigningRequest上传到苹果后天,生成证书,并下载到本地。
4.第四步是在苹果网站操作的,装备AppID,设备ID,权限等,生成Provisioning Profile文件,并下载Provisioning Profile文件到本地。
5.xcode经过第三步下载下来的证书,去找对应的本地私钥,用本地私钥去签名App,并把Provisioning
Profile文件一同打包进去,装置进iOS设备。
总结一些概念:
1.证书:内容是公钥或许私钥,由其它组织对其签名组成的数据包。
2.entitlements:包括了App权限开关列表,AppID,设备ID等。
3.CertificateSigningRequest:本地公钥。
4.p12:本地私钥。
5.Provisioning Profile:包括证书,entitlements等数据,并由苹果后台私钥签名的数据包。
依照上面的流程,那么对于开发人员来说,应该是咱们每次新建一个项目也便是有一个新的AppID时,都应该去恳求一对本地公私钥,上传公钥到苹果后台,然后下载证书,可是实际上咱们并没有这么做,如同很少需求去keychain恳求本地公私钥,这是为什么呢?
这儿的原因便是iOS Team Provisioning Profile。
iOS Team Provisioning Profile是第一次运用xcode增加设备时,xcode自动生成的,它包括了xcode生成的一个Wildcard AppID(匹配一切使用程序,账户里边的一切device,一切Development Certificates),因而team中的一切成员都能够运用这个iOS Team Provisioning Profile在team的一切设备上调试一切的使用程序,而且当有新设别增加进来时,xcode会更新这个文件。
如此一来,只要咱们有一对本地公私钥,而且经过这个本地的公钥上传给苹果获取了证书,那么今后咱们运转任何App,在任何iOS设备上运转,都能够运用这个本地私钥和证书,而没有必要每次去创立新的公私钥和获取证书。
经过这个iOS Team Provisioning Profile的结构咱们就能理解,iOS Team Provisioning Profile中保存着许多分证书,许多AppID,许多设备ID,entitlements。当咱们需求在一个指定的iOS设备上运转一个指定的App时,iOS Team Provisioning Profile就会得到这个AppID和这个设备ID以及它对应entitlements,组成这个特定的Provisioning Profile,打包进APP里边。这样就不需求咱们每次去恳求证书,生成Provisioning Profile文件了,非常方便。