Apple安全性

Apple应用打包上传AppStore以及早些时候的真机调试都需要在Apple开发者平台上进行很多操作，比如：上传certSigningRequest文件，生成cer证书，配置Identifiers、Devices，生成mobileprovision文件，安装cer证书，导出p12文件等等。你可曾考虑过Apple为什么要求开发者做这些繁琐的操作，这些文件有什么用，它们又包含了什么信息呢？接下来我会用图文形式由浅入深地介绍一下所有相关知识。通过了解该知识，初级iOS开发者可以充分理解Apple证书配置过程中发生的所有事情，从而不必纠结于证书的各个配置流程；对于高级开发者，可以更加深入理解Apple应用安装包的安全机制，有兴趣研究逆向工程、尝试为越狱手机定制应用插件等的开发者可以借此快速理解重签名机制。

要想了解这部分知识，需要先了解一些密码学的基本概念。有相关基础的同学可以直接跳到“iOS的签名机制”这一部分。

对称密码

使用对称密码对信息进行加密、解密的方式是对称加密，这是初级的加密、解密方式。之所以称为“对称”，是因为这种方式的加密、解密过程使用的密钥是同一个，目前对应的算法有DES、3DES、AES等。其大概过程如下图所示：

消息接收方要想解密出已经加密的信息，必须要先获取密钥，这就涉及到了密钥的传输问题。如果密钥在传输过程中被别人窃取，那么对信息的加密操作也就失去了作用。如何保证密钥传输的安全呢？人们曾尝试过很多种方式，比如事先将密钥分享给接收方、使用Diffie-Hellman密钥交换算法、使用公钥密码等。接下来我们重点介绍公钥密码这种方式，这也是目前主流的解决办法。

公钥密码

公钥密码也叫非对称密码，使用公钥密码对信息进行加密、解密的方式是非对称加密。它与对称加密最大的不同之处在于加密、解密的过程使用的密钥不是同一个。公钥密码的密钥分为公钥和私钥，公钥一般是公开的，私钥则由生成方自己保管。

公钥和私钥是一一对应的，不能单独生成，并且由公钥加密的密文必须使用与该公钥对应的私钥才能解密，而由私钥加密的密文，必须使用与该私钥对应的公钥才能解密。其大概过程如下图所示：

公钥密码是怎样解决密钥传输问题的呢，先看下图流程：

在A、B双方消息传递过程中，B只把用于加密的公钥传递给了A，而用于解密的私钥并没有发生传递，也就不会发生解密密钥在传递过程中被窃取的问题。

那么，这种加密、解密方式又存在什么问题呢？如果传递的信息量很大，使用这种加解密方式要比使用对称密钥加解密方式耗时得多。下面我们进一步解决这个问题。

混合密码系统

混合密码系统是将对称密码和公钥密码的优势结合起来的一种加解密方式。对称密码用于对消息的加密，解决公钥密码加解密速度慢的问题；公钥密码用于对需要传递的对称密码加密，解决对称密码在传输过程中不安全的问题。如下图所示：

需要传递的信息使用由A生成的对称密码加密，然后A生成的对称密码会被B的公钥加密，一方面保证了对称密码的安全，另一方面使用对称密码对消息加密，提高了加解密速度。

这种方式还会有什么问题呢？在混合密码系统中，主要依赖的是消息接收方的公钥。如果遇到“中间人攻击“，混合密码系统将会彻底失效，而数字签名和数字证书可以用于解决这个问题。下图展示了中间人攻击的大致过程：

数字签名

在了解数字签名之前，需要先了解一下单向散列函数。单向散列函数可以根据任意长度的消息内容快速计算出一段固定长度的散列值。该散列值主要有这几个特点：散列值的长度和消息的长度无关；消息内容不同，计算出来的散列值也不同；具有单向性，即不能根据散列值推算出消息原内容。我们可以把散列值简单理解为是对消息的摘要。目前像MD5、SHA-1、SHA-2、SHA-3等都属于单项散列函数。

那么数字签名是什么呢？下面是百度百科中的一段解释。

我们可以跟现实生活中的签名作对比，现实生活中的签名主要有两个特点：（1）签名人是唯一的（2）签名后，被签名的文件就会被认可为真实有效。数字签名同样有这两个特点，消息接收方的“私钥”相当于“签名人”；消息接收方使用“公钥”验证成功相当于证明了“消息真实有效”。

数字签名的过程是这样的：

（1）消息发送方生成用于数字签名的公钥、私钥对，并将公钥传递给消息接收方；

（2）消息发送方使用单向散列函数对消息内容进行提要获取“散列值”；

（3）消息发送方使用自己的私钥对“散列值”进行加密，将加密后的密文以及消息内容一起发送给消息接收方；

（4）消息接收方收到加密后的密文以及消息内容后，使用单向散列函数对消息内容进行同样的操作获取“散列值”；

（5）消息接收方使用消息发送方的公钥，解密出经私钥加密的散列值；

（6）消息接收方将两个散列值进行对比，如果相同，就证明消息是真实有效的。

这个过程看起来很像非对称加密的过程。其实在非对称加密和数字签名的两个过程中，公钥密码的使用方式是相反的：在非对称加密过程中，密钥对是由消息接收方生成的，并把公钥传递给消息发送方，消息发送方使用公钥进行加密操作，消息接收方使用自己的私钥进行验证操作；在数字签名过程中，密钥对是由消息发送方生成的，并把公钥传递给消息接收方，消息发送方使用自己的私钥进行加密操作，消息接收方使用公钥进行验证操作。

数字证书和认证机构

认证机构(CA)是指数字证书的颁发机构。认证机构生成自己的公钥、私钥，然后使用自己的私钥对需要认证的“他人的公钥”进行签名，然后把签名后生成的信息与“他人的公钥”合并，生成证书文件。认证机构将生成的证书文件回传给“公钥所属人”，并将对应的公钥放到自己的网站上供需求方使用。具体过程如下图所示：

CA机构通过对消息接收方B的公钥进行签名，将签名信息和B的公钥以及其他一些信息一起生成一个证书文件，并把证书回传给B；B再把证书发送给消息的发送方A；A拿到B的数字签名文件及对应的CA机构的公钥，对证书内B的公钥进行签名验证，验证通过后，就说明证书中B的公钥真实有效，接下来就可以使用B的公钥进行信息传输了。

iOS的签名机制

介绍完前边的基础知识，终于可以进入正题了。用户在往iPhone上安装应用包时，苹果会对应用包进行验证，以保证应用包的来源安全。这个过程依赖的是iOS的签名机制，而签名机制最终是通过对称密码、公钥密码、数字签名、数字证书等这些技术实现的。

先考虑比较简单的情况。Apple后台会生成公钥、私钥对，然后苹果移动设备会获取到Apple后台的公钥。

开发者使用Xcode将App包上传至苹果后台后，Apple后台在生成安装包的过程中，使用自己的私钥对App包进行签名（注意回顾文章第四部分中讲解的“数字签名”的过程）。用户从AppStore获取该安装包并安装的过程中，iPhone使用iPhone中预存的Apple后台公钥对安装包中的内容进行签名验证，验证通过后就能顺利安装。大概流程如下图所示：

在真机调试过程中，也涉及到给iPhone安装应用包，这个过程会比较复杂，但实质也是签名与验证签名的过程：

（1）首先需要明确相关密钥的分布情况。该情况下一共有两对公钥、私钥，分别为MAC生成的公钥、私钥和Apple后台生成的公钥、私钥：

（2）我们在Apple后台配置证书的时候，需要先在MAC电脑的钥匙串里申请证书（CertificateSigningRequest.certSigningRequest文件），该证书就是MAC的公钥：

在Apple后台上传该证书，创建好Certificates后会生成一个cer文件供开发者下载，该cer文件就是利用Apple后台的私钥对Mac的公钥进行签名后生成的证书文件；最后根据在Apple后台设置好的Identifiers和Devices生成mobileprovision文件，该文件也是利用Apple后台的私钥对相关信息进行签名处理生成的文件。该过程如下图所示：

（3）使用Xcode打包过程中，Xcode会使用MAC私钥对编译生成的app包进行签名。目的是后期在将ipa包安装到设备上并使用MAC公钥验证签名时，确保app包内的可执行文件和资源等未被修改过，如图所示：

（4）前边两步生成的两个文件会组合成ipa安装包，如下图所示：

（5）最后就是将ipa包安装到iPhone上时的验证操作了。如上图所示的右半侧部分，一共有三个验证操作：

第一个验证：iPhone上已经获取了Apple后台的公钥，iPhone先使用Apple的公钥对mobileprovision文件的签名进行验证，获取到设备id、bundle id和权限相关信息，并与对应的信息进行对比是否一致；

第二个验证：使用Apple的公钥对MAC公钥的签名进行验证获取MAC公钥；

第三个验证：使用MAC公钥验证app包的签名，确保app包内的可执行文件和资源等未被修改过

等所有验证都通过后才能将真机调试的测试包安装到iPhone上。其中任何一步验证不通过，都会表明该安装包可能来源于非正规渠道。

以上都是针对于非越狱的iPhone而言的，而对于越狱的iPhone，安装包的验证过程就不再完全受Apple的控制，这也就是越狱的iPhone能安装非AppStore应用包的原因。

这篇文章内容有点长，为了能让你更容易理解iOS 的签名机制，文章用了超过一半的篇幅讲解了密码学相关的基础知识，这部分基础也能帮你理解https加密通讯的原理、抓包工具的原理等。我一直认为只有自己充分理解所学的知识而不是只停留在会用的层面上，才能更灵活地将所有知识自由地组合运用，才能在已有技术的基础上推陈出新，才能举一反三地理解所有相似的技术。希望我以上的总结能对你在求知的路上抛砖引玉、有所帮助。