证书和签名机制

证书和签名机制

数字签名：实际上是非对称加密+摘要算法（MD5或SHA1）。首先将文本通过摘要算法得到摘要，再用私钥对摘要进行加密得到密文，将源文本、密文、私钥对应的公钥一并发布

作用：为了中途篡改文本内容和保证文本的完整性，以及文本是指定的人发的

解密：用拿到的公钥对密文解密，得到摘要A，再拿源文本通过摘要算法后得到的摘要B，若A==B，则没有问题

注意：有可能拿到的不是A发出的公钥，可能是B、C、D伪造的公钥，所以此时用到了数字证书

数字证书：CA机构对A的公钥做认证，把公钥和有效期等信息一起加密，生成数字证书。

解密：用CA机构给的公钥解开数字证书就可以拿到A的公钥

之所以要申请证书，当然是为了被验证。英语6级证书的验证方一般是用人单位；web应用相关的SSL证书的验证方通常是浏览器；iOS各种证书的验证方是iOS设备。我们之所以必须从CA处申请证书，就是因为CA已经将整个验证过程规定好了。对于iOS，iOS系统已经将这个验证过程固化在系统中了，除非越狱，否则无法绕过。

1）证书申请：安装苹果根证书，让开发工具信任CA机构颁发的证书，从而可以用CA签发的其他证书签名和打包（一般安装xcode会自动安装此证书到keychain）

2）提交申请者信息到苹果会员中心里签发证书，包括：

1-申请者信息用私钥加密（私钥保存在申请者里）

2-申请者公钥

3-摘要算法和RSA加密

3）苹果拿申请者信息里的公钥和苹果账号信息封装在证书中，进行数字签名；安装完此证书后，keychain会自动关联我本地的私钥和此证书包含的公钥

4）后续真机过程里，会使用私钥对代码进行签名，打包进APP。

注意：公钥是会附带在.mobileprovision描述文件中，但不是随代码打包的，是因为我们所选的证书会对应到私钥，用于签名的还是私钥

5）将最初申请证书的机器的私钥导出成.p12文件，并让其他机器导入，同时其他机器也应该安装下载下来的证书，用于团队开发

6）mobileprovision文件包含：

AppId。每个app必须在MC中创建一个对应的AppId。

使用哪些证书。不同类型的证书就代表了不同的发布方式，还包括一些功能的能否使用（比如APN：上架后使用苹果推送服务）

功能授权列表

可安装的设备列表。对于AdHoc方式发布的app或者真机调试时，会有一个列表，这个列表里面是iOS设备的UDID，每台iOS设备出厂的UDID都不同，所以可以用来标识设备。

苹果的签名

注意：AdHoc证书类型：允许将测试版app发布给有限的设备安装，而无需通过appstore的审核。

ipa结构

iOS程序最终都会以.ipa文件导出，先来了解一下ipa文件的结构：

事实上，ipa文件只是一个zip包，可以改后缀名为zip解压

解压后，得到上图的Payload目录，下面是个子目录，其中的内容如下：

资源文件，例如图片、html、等等。

_CodeSignature/CodeResources。这是一个plist文件，可用文本查看，其中的内容就是是程序包中（不包括Frameworks）所有文件的签名。注意这里是所有文件。意味着你的程序一旦签名，就不能更改其中任何的东西，包括资源文件和可执行文件本身。iOS系统会检查这些签名。

可执行文件。此文件跟资源文件一样需要签名。

一个mobileprovision文件.打包的时候使用的，从MC上生成的。

Frameworks。程序引用的非系统自带的Frameworks，每个Frameworks其实就是一个app，其中的结构应该和app差不多，也包含签名信息CodeResources文件

重签名流程：

1、解压ipa

2、通过命令行强制重签.app目录，codesign程序会自动将其中的文件都签名，（Frameworks不会自动签）

/user/bin/codesign -fs"iPhone Developer: Liang Ding (2U967A2YJ6)" --no-strict Payload/xxx.app

3、对于每个Framework，也需要使用这个命令签名，并且替换描述文件.mobileprovision

4、使用zip命令重新打包成ipa包

iOS设备如何验证app是否合法：

解压ipa

取出embedded.mobileprovision，通过签名校验是否被篡改过

其中有几个证书的公钥，其中开发证书和发布证书用于校验签名

BundleId

授权列表

校验所有文件的签名，包括Frameworks

比对Info.plist里面的BundleId是否符合embedded.mobileprovision文件中的