苹果双向验证

背景知识介绍

​ base64 编码方案，是一种基于64个可打印字符来表示二进制数据的方法

​ HASH （散列函数）

​ MD5算法

​ SHA1/512

​ HMAC ：使用KEY进行明文加密，然后进行2次 hash。key从服务器获取，对应一个账号一个key，

​ 随机生成保存服务器。

​ 特点：算法公开

​ 对相同的数据加密，得到的结果是一样的

​ 对不同的数据加密，得到的结果是定长的。如：md5 32个字节

​ 不可逆

​ 信息摘要，信息指纹。使用来做数据识别

​ MD5举例 www.cmd5.com，反向查询,解决方案 密码加盐（默认在用户密码后面添加一串

​ 乱七八糟的字符串）

​ 加盐会有泄露风险，salt泄露了 还是可以通过大数据反向查询出来，HMAC动态盐加密方案

​ 对称加密算法 DES 、3DES、 AES（高级密码标准）、RC-5、IDEA:加密解密都是同一个秘钥

​ 非对称加密算法 RSA、 ECC (公钥加密 私钥解密，私钥加密 公钥解密)

数字证书&数字签名

证书，通过证书颁发机构私钥对需要认证的公钥和一些相关信息加密形成证书文件“数字证书”

p12文件，带有私钥的证书 = 证书 + 私钥 ，所以可以通过导出并且安装到别的设备上

数字签名 = 内容Hash值 + RSA加密

经典图解 数字证书和数字签名

苹果双向验证原理图解

参考iOS App 签名原理

1.验证App是否经过苹果认证，见图

2.如何控制App安装问题，见图

其他形式的发布签名验证

另外两种方式 In-House 企业签名和 AD-Hoc 流程也是差不多的，只是企业签名不限制安装的设备数，另外需要用户在 iOS 系统设置上手动点击信任这个企业才能通过验证。

而 AppStore 的签名验证方式有些不一样，苹果在后台直接用私钥签名 App 就可以了，实际上苹果确实是这样做的，如果去下载一个 AppStore 的安装包，会发现它里面是没有embedded.mobileprovision文件的，也就是它安装和启动的流程是不依赖这个文件，验证流程也就跟上述几种类型不一样了。

据猜测，因为上传到 AppStore 的包苹果会重新对内容加密，原来的本地私钥签名就没有用了，需要重新签名，从 AppStore 下载的包苹果也并不打算控制它的有效期，不需要内置一个embedded.mobileprovision去做校验，直接在苹果用后台的私钥重新签名，iOS 安装时用本地公钥验证 App 签名就可以了。

解决的问题

1.为什么换台设备，直接从开发者中心下载证书，不能实现真机打包调试，必须要通过导出p12文件到新设备上。

答：签名是通过 p12中的私钥去签的，开发者中心只能下载证书，证书中只有公钥，没有私钥。

2.苹果如何保证app是可信任的。

答：验证App是否经过苹果认证，通过2次解决认证问题

3.如何控制App的安装。

答：苹果发明了 provision profile文件格式，其中的entitlements,uuid，设备ID，appid等去控制一个app是否能被安装及调试等。

4.知道原理之后，回头看看重签名。

实质上 就是需要替换provision profile文件，以及安装时候需要校验的信息，比如bundleID，重新签名即可。