ios签名原理详解

Posted

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了ios签名原理详解相关的知识,希望对你有一定的参考价值。

参考技术A ios企业签名是非常常用的内测应用分发渠道,但我们在使用ios签名之前,还需要了解其中的签名原理,只有这样我们才能知道企业签名为什么会掉签?如何根据自己的实际情况选择更稳定的签名?

三种iOS签名的原理详解:

1、 企业ios签名

ios签名中的企业签名是使用企业开发者账号生成的企业发布证书来进行签名的。企业开发者账号是一种比较特殊的账号,它不能在App Store中发布应用,最大的作用就是进行签名。而在签名过程中真正起到作用的企业发布证书是可以被复制的,所以很多签名服务商就可能会使用同一本发布证书对众多不同的应用进行签名,这也就是企业签名频繁掉签的主要原因。

2、 超级签名

ios签名中的超级签名是使用个人开发者账号,通过添加苹果设备的udid来实现真机测试,这种ios签名方式是有一个很明显的限制的,了解过苹果开发者账号的人应该知道,一个个人开发者账号最多只能添加100个udid,这个数量上的限制决定了这种ios签名方式比企业ios签名更加稳定。

3、 tf签名

tf签名是目前三种ios签名方式中最稳定、也是最安全的一种。实际上,它是指将应用上架到testflight,而testflight是苹果官方的内测分发渠道,需要苹果审核,受到苹果官方加持,稳定性和安全性自然都有很大保障,所以很多ios开发者更倾向于使用这种ios签名方式来进行内测。

通过对以上三种ios签名的原理介绍,我们可以了解到,企业ios签名之所以频繁掉签,就是因为其原理中的发布证书具有可复制性,ios签名应用越多,风险就越大,ios签名就越不稳定。而超级签名在这三种ios签名中属于比较稳定的一种,但是现在市场非常不稳定,而且市面上的超级签名源头很难判断,目前不是很推荐使用。而tf签名是三种ios签名中最稳定的一种方式,很多人选择这种ios签名方式就是看中了它受到苹果官方的认可。 ios上架为什么要选择tf上架?

当我们在选择ios签名方式的时候,要结合自己的实际情况,不同类型的签名,其稳定性和价格都是不一样的,结合自己的应用特点和内测需求选择合适自己的ios签名。

AndroidV1,V2,V3签名原理详解

签名校验流程

基础知识
1.数字签名
2.数字证书
3.对称加密和非对称加密

背景介绍:
一般开发者会指定使用自己创建的证书,如果没有指定,则会默认使用系统的证书,该默认的证书存储在C:\\Users\\admin.android\\debug.keystore,不同的电脑可能安装不同路径。一个签名证书文件中,是包含一对公私钥,用私钥对apk进行签名,在安装到android手机时,系统会使用证书中对应签名私钥的公钥来验证,查看apk是否被更改过,如果没有则可以安装在手机上。任何的app store都不允许使用默认的debug.keystore打包的apk发布上去,因为debug.keystore的密码是默认的,不安全。
一,没有签名的APK无法安装
Android的APK要进行签名才能够安装到手机上,这是因为在安装的时候系统会进行检测,平时我们直接点AS里面那个绿色的运行按钮也能够直接安装到手机上,这是因为其实它也进行了签名,只不过AS自动帮我们做了这个操作有个默认的签名

在.android目录中有个debug.keystore默认的签名)。

二,校验流程
9.0以上的系统会判断apk是否使用到V3版本的签名,如果有,那么按照V3版本签名校验方式进行校验校验成功直接安装,校验失败拒绝安装;如果apk不是使用V3签名,判断是不是使用V2,如果没有使用V2那么再判断是不是使用V1的签名。

三,进行V3签名
Android不支持V3版本的签名,所以在AS里面看不到V3。但是在SDK中有个签名工具apksigner.jar。只有9.0以上这个签名工具才能签V3版本的签名。

(如果想要签V3版本的签名,那么只能自己去使用这个签名工具在命令行中进行签名)

接下来详细介绍的就是不同的签名版本之间的区别。

不同的签名版本之间的区别

V1签名保护机制

保护APK中已有文件

基于JAR的签名。在打包后的apk中会多三个文件:

一.MANIFEST.MF

APK当中的所有文件都会列出来用Name表示,除此之外每个文件都有SHA-256签名摘要记录

签名摘要记录:校验码对我们的数据内容进行验证,防止别人会修改你的文件。如果文件改动那么对应的检验码就会不一致

二.CERT.SF
这里面存放的和上面MANIFEST.MF的内容一样,只不过多了一个文件就是MANIFEST.MF文件,并对它进行了和其他文件一样的操作:生成校验码。

目的:上面说过修改了文件后,如果只是和之前文件的校验码对比是可以检测到修改的。但是如果我把文件和校验码都进行修改,那么他就检测不出来,这样的安全性就太低了。所以我们把上面的MANIFEST.MF文件也给他进行一次校验。

但是如果你把SF文件和校验码也改了呢?接下来看最后一个文件CERT.RSA

三.CERT.RSA
在签名的时候会给一个证书,里面有公钥和私钥;
这个RSA文件使用私钥计算SF文件的数字签名+包含公钥的证书信息保存到RSA文件中。

第三层防护:理论上没有私钥是无法伪装数字签名的。

总结:
RSA文件保护SF文件,SF文件保护MF文件,MF文件保护apk中已有的所有文件

注意:V1签名保护的是APK中已有文件不被修改,但是新加的文件并不会受影响。

下面我们来分析一下,如果apk文件被篡改后会发生什么。

首先,如果你改变了apk包中的任何文件,那么在apk安装校验时,改变后的文件摘要信息与MANIFEST.MF的检验信息不同,于是验证失败,程序就不能成功安装。

其次,如果你对更改的过的文件相应的算出新的摘要值,然后更改MANIFEST.MF文件里面对应的属性值,那么必定与CERT.SF文件中算出的摘要值不一样,照样验证失败。

最后,如果你还不死心,继续计算MANIFEST.MF的摘要值,相应的更改CERT.SF里面的值,那么数字签名值必定与CERT.RSA文件中记录的不一样,还是失败。
那么能不能继续伪造数字签名呢?不可能,因为没有数字证书对应的私钥。

所以,如果要重新打包后的应用程序能再Android设备上安装,必须对其进行重签名。
从上面的分析可以得出,只要修改了Apk中的任何内容,就必须重新签名,不然会提示安装失败。

V2签名保护机制

保护的是整个APK的字节数据

原理:apk文件本身就是一个zip文件,按照ZIP文件格式插入APK Signing Block分块去记录签名信息


APK Signing Block格式:

size of block: APK分块总长度-8
id-value paris: id与value数据总长度
id:id数据
value:value数据
size of block:与第一个字段相同
magic:魔数(标记文件格式,目的为了快速识别文件格式)

举例:
假如APK签名分块数据总长度为108

size of block:100(108-8)
id-value paris:X(id和value总长度)
id:(4个字节)
value:签名信息(X-4)
size of block:100(108-8)
magic:ZIP文件的魔数

其中可以有多个id-value paris,id和value

那么前面说过V2签名保护的是整个ZIP文件的字节数据,那么具体是保护哪些呢:

可以看到保护的是1,3,4部分和刚才图里面的APK中V2签名存储的其中一个ID值对,但是"刚刚说了可以有多个id-value paris,id和value值对,所以我们可以添加这些东西而且不会影响签名机制"

V3签名保护机制

V3签名和V2签名类似,区别:
一,V3签名多了一个判断机制:“APK签名数据块大小必须是4096的倍数”
二,V3签名分块采用V2相同的签名分块格式,只不过改了V2签名分块中的那个ID
三,增添了有关受支持的SDK版本和prof-of-rotation结构的信息

怎样判断使用的是哪种签名

V1直接看APK的目录就可以分辨
另外两个涉及到了EOCD格式中有一个值代表Central Directory到Contents of Zip Entries的位移,
这里就用图去表示了。。

由此也可以得出:偏移量-APK签名分块长度=签名分块从第几个字节开始
偏移量:上面提到过在EOCD格式中存储着
APK签名分块长度:偏移量-16个字节(magic魔数)-8个字节(size of block)

参考链接:

https://www.2cto.com/kf/201512/455388.html

以上是关于ios签名原理详解的主要内容,如果未能解决你的问题,请参考以下文章

AndroidV1,V2,V3签名原理详解

apk签名原理

图文详解 epoll 原理Redis,Netty,Nginx实现高性能IO的核心原理epoll 详解

硬件体系优化及IO优化核心优化原理详解

IOS SDWebImage实现原理详解

iOS推送原理详解