iOS安全之数字证书和安全机制

iOS安全之数字证书和安全机制

非对称加密和摘要

非对称加密就是指加密密钥和解密密钥是不同的，而且加密密钥和解密密钥是成对出现。非对称加密又叫公钥加密，也就是说成对的密钥，其中一个是对外公开的，所有人都可以获得，称为公钥，而与之相对应的称为私钥，只有这对密钥的生成者才能拥有。公私钥具有以下重要特性：

• 对于一个私钥，有且只有一个与之对应的公钥。生成者负责生成私钥和公钥，并保存私钥，公开公钥。
• 公钥是公开的，但不可能通过公钥反推出私钥，或者说极难反推，所以只要秘钥足够长度，要通过穷举而得到私钥，几乎是不可能的。
• 通过私钥加密的密文只能通过公钥解密，公钥加密的密文只有通过私钥解密。
  由于上述特性，非对称加密具有以下的典型用法：
• 对信息保密，防止中间人攻击：将明文通过接收人的公钥加密，传输给接收人，因为只有接收人拥有对应的私钥，别人不可能拥有或者不可能通过公钥推算出私钥，所以传输过程中无法被中间人截获。只有拥有私钥的接收人才能阅读。此用法通常用于交换对称密钥。
• 身份验证和防止篡改：权限狗用自己的私钥加密一段授权明文，并将授权明文和加密后的密文，以及公钥一并发送出来，接收方只需要通过公钥将密文解密后与授权明文对比是否一致，就可以判断明文在中途是否被篡改过。此方法用于数字签名。
  著名的RSA算法就是非对称加密算法，RSA以三个发明人的首字母命名。
  非对称加密算法如此强大可靠，却有一个弊端，就是加解密比较耗时。因此，在实际使用中，往往与对称加密和摘要算法结合使用。
  对称加密是将明文（原始数据）和加密密钥（mi yao）一起经过特殊加密算法处理后，使其变成复杂的加密密文发送出去。收信方收到密文后，若想解读原文，则需要使用加密用过的密钥及相同算法的逆算法对密文进行解密，才能使其恢复成可读明文。在对称加密算法中，使用的密钥只有一个，发收信双方都使用这个密钥对数据进行加密和解密，这就要求解密方事先必须知道加密密钥。计算机专网系统中广泛使用的对称加密算法有DES和IDEA等。
  摘要算法可以将任意长度的文本，通过一个算法，得到一个固定长度的文本。这里文本不一定只是文本，可以是字节数据。所以摘要算法试图将世间万物，变成一个固定长度的东西。摘要算法具有以下重要特性：
• 只要源文本不同，计算得到的结果，必然不同。
• 无法从结果反推出源。
  典型的摘要算法，比如大名鼎鼎的MD5和SHA。摘要算法主要用于比对信息源是否一致，因为只要源发生变化，得到的摘要必然不同；而且通常结果要比源短很多，所以称为“摘要”。

数字签名

数字签名一般用于数据接收方（一般指客户端）验证数据发送发方（一般只指代服务器）发送的数据是否合法（是否经过第三方篡改）。举个例子，A有一段文本要发给B，A为了防止文本在中途被恶意篡改。A找来C，C将文本内容通过摘要算法，得到摘要，再用自己（C的）私钥对摘要加密得到密文，A将原文、密文一并发给B。接收方B收到数据以后用C的公钥（提前固化在系统中了）对密文进行解密，将文本用同样的算法得到摘要，两个摘要进行对比，如果相等那么一切正常，否则视为接收数据视为无效。如图：

证书申请

开发iOS程序必然进行的工作就是成为开发者，并申请相关的证书。在申请之前需要：

1. 支付$99或$299成为苹果开发者，并每年续费，$99针对个人和小企业，$299针对大企业。
2. 安装苹果开发者根证书，此证书实际上是我们从苹果MC中申请的所有证书的“根证书”，安装这个证书意味着我们的开发工具对此CA的信任，从而可以用此CA签发的其他证书进行签名和打包。一般而言，如果安装了Xcode，那么这个证书是自动安装在Key Chain中了。

CertificateSigningRequest.certSigningRequest

我们需要生成一个CertificateSigningRequest.certSigningRequest文件来提交到MC中，从而获取某种证书。这个文件包含两部分内容：

1. 申请者信息，此信息是用申请者的私钥加密的。
2. 申请者公钥，此信息是申请者使用的私钥对应的公钥。
3. 摘要算法和公钥加密算法。

从MC中申请到的证书

证书中最为重要的是我的公钥，这个公钥与我本机的私钥是对应的。当我们双击安装完证书后，KeyChain会自动将这对密钥关联起来。后续在程序上真机的过程中，会使用这个私钥，对代码进行签名，而公钥会附带在mobileprovision文件中，打包进app。所以，就算你有证书，但是如果没有对应的私钥是没有用的。

团队开发

打包到真机上的app需要我们的私钥进行签名，所以我们在团队开发中需要公开私钥。将最初申请证书的机器的私钥导出成.p12文件，并让其他机器导入，同时其他机器也应该安装下载下来的证书。
由于iOS证书有多种类型，用于不同的用处，所以我们可能后续还会去MC上申请别的证书。所以强烈建议CertificateSigningRequest.certSigningRequest需要保留，因为如果再次生成CertificateSigningRequest.certSigningRequest文件，可能就是对应另一个私钥了！还需要在共享一次私钥，会比较麻烦。

iOS证书类型

常用的有：

• iOS App Development。开发、真机调试用。
• Apple Push Notification service SSL (Sandbox)。开发阶段使用苹果的推送服务。
• App Store and Ad Hoc。上架和AdHoc方式发布时用。
• Apple Push Notification service SSL (Production)。上架后使用苹果推送服务。
• In-House。企业版发布，需$299才能拥有，还需邓氏编码。

iOS授权和描述文件

可以使用如下命令查看描述文件。

security cms -D -i embedded.mobileprovision
mobileprovision文件包含：

1. AppId。每个app必须在MC中创建一个对应的AppId。
2. 使用哪些证书。不同类型的证书就代表了不同的发布方式，还包括一些功能的能否使用（比如APN）。
3. 功能授权列表。
4. 可安装的设备列表。对于AdHoc方式发布的app或者真机调试时，会有一个列表，这个列表里面是iOS设备的UDID，每台iOS设备出厂的UDID都不同，所以可以用来标识设备。
5. 苹果的签名。
   注意，这里的签名是苹果签的，跟我们的私钥没有关系。也就是说mobileprovision文件是苹果签名的，我们除了从MC中获取，别无他法。也不能再获取后随意篡改（比如添加别的设备）。

AdHoc发布和真机调试

AdHoc允许将测试版app发布给有限的设备安装，而无需通过appstore的审核。这里的关键是如何控制哪些设备可以装。答案就是mobileprovision文件，记得你在生成mobileprovision文件的时候需要选设备的UDID吧，所以这些设备需要事先添加到MC的Devices里面。对于开发时候的真机调试，原理差不多。都是通过mobileprovision的条目4来做到的。而苹果对于调试和测试用机的数量限制为100台！

iOS代码签名

ipa的组成

iOS程序最终都会以.ipa(事实上，ipa文件只是一个zip包)文件导出，先来了解一下ipa文件的结构：

将appname.ipa的后缀名改成appname.zip然后解压，得到上图的Payload目录，下面是个子目录，其中的内容如下。

1. 资源文件，例如图片、html、等等。
   2. _CodeSignature/CodeResources。这是一个plist文件，可用文本查看，其中的内容就是是程序包中（不包括Frameworks）所有文件的签名。注意这里是所有文件。意味着你的程序一旦签名，就不能更改其中任何的东西，包括资源文件和可执行文件本身。iOS系统会检查这些签名。
   3. 可执行文件。此文件跟资源文件一样需要签名。
   4. 一个mobileprovision文件.打包的时候使用的，从MC上生成的。
   5. Frameworks。程序引用的非系统自带的Frameworks，每个Frameworks其实就是一个app，其中的结构应该和app差不多，也包含签名信息CodeResources文件。

相关的程序和命令

一般我们会用Xcode自带的archive功能来打包ipa和签名，实际上xcode只不过是调用了一些外部程序完成了工作，如果我们有朝一日需要自己实现自动化的签名流程，就需要了解究竟相关的程序和命令有哪些。
用下面命令，列出系统中可用于签名的有效证书：

security find-identity -v -p codesigning
使用如下命令对xxx.app目录签名，codesign程序会自动将其中的文件都签名，（Frameworks不会自动签）：
codesign -fs “Your Cer” --no-strict Payload/xxx.app
对于每个Framework，也需要使用这个命令签名，上面说了Framework的结构跟app其实差不多，所以签名命令类似。这个命令会自动找到证书相关的私钥。-f表示对于已经签名的app强制重签。
最后用下面命令校验签名是否合法：
codesign -v xxx.app
使用zip命令重新打包成ipa包
zip -qry destination source

对app重新签名的流程

如果要设计一个自动化的重签程序，大致需要这么个流程：

1. 解压ipa。
   2. 如果mobileprovision需要替换，替换。
   3. 如果存在Frameworks子目录，则对.app文件夹下的所有Frameworks进行签名，在Frameworks文件夹下的.dylib或.framework。
   4. 对xxx.app签名。
   5. 重新打包。

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

1. 解压ipa。
2. 取出embedded.mobileprovision，通过签名校验是否被篡改过。
   1. 其中有几个证书的公钥，其中开发证书和发布证书用于校验签名。
   2. BundleId。
   3. 授权列表。
3. 校验所有文件的签名，包括Frameworks。
4. 比对Info.plist里面的BundleId是否符合embedded.mobileprovision文件中的。