iOS加解密原理 && 签名机制

#              iOS加解密原理 && 签名机制

## 一. 学习路线

1. ####了解加解密

   a . 对称加密 DES 3DES AES

   b . 非对称加密 RSA

   c . 混合加密

2. #### 单项散列函数MD4、MD5、SHA1-3

3. ####数字签名

4. ####证书

5. ####签名机制

6. #### 补充加解密相关--https

## 二.  start to learn

###    2.1.1 对称加密 ---->加密和解密使用同一个密钥. 

  目前主要使用的有三种对称加密方式 DES ,  3DES ,AES

####              - 1.  【DES】

####                - 2.  【3DES】   

      -  **3DES**是将DES重复 3 次所得到的一种密码算法，也叫做 3 重 DES，目前还被一些银行等机构使用，但处理速度不    高，安全性逐渐暴露出问题

####                - 3. 【AES】----- (**Advanced** Encryption Standard）

   -    AES 的密钥长度有 128、192、256bit 三种，目前 AES ，已经逐步取代 DES、3DES，成为首选的对称密码算法   

  **缺点**：不能很好地解决密钥配送问题，

  **优点**：加解密速度快

###      2.1.2 非对称加密 （公钥密码算法） ---->加密和解密使用不同的密钥 

###        

-  解密的密钥 由消息接收者自己保管，不公开， 因此称为**私钥**。

-  加密的密钥  一般是公开的，因此称为**公钥**。 

-  公钥 与 私钥 **一一对应**，公钥 加密的密文 必须使用相对应的私钥 才能揭秘。

-  公钥 和 私钥 都能用来 加密&解密

-  公钥一般放在客户端(剧透下,**每个iPhone手机中都有一个Apple公钥**)

-  目前使用最广泛的 非对称加密算法 是RSA （由三位开发姓氏首字母组成）

-  缺点：加密解密**速度比较慢**，

-  优点：能很好的**解决密钥配送问题**

###    2.1.3 对称加密中 如何传输密钥？

**对称加密**体系中，密钥不能直接传输，否则可能被截取，截获者也能破解密文。有以下几种密钥传输方式：

-  1、事先共享密钥：即通过非通讯手段，私下直接给出密钥。

-  2、密钥分配中心：所有密钥有分配中心管理，分配中心通过特殊安全手段下发。

-  3、借助非对称密码体系：由消息的**接收者**，**生成**一对公钥、私钥，将**公钥**对外**公开**发给消息的**发送者**，消息的发送者使用公钥加密消息，**接收者**使用**私钥解密**。整个过程只有消息接收者具有私钥，其他任何人没有私钥不具备解密能力. 即 混合加密的过程。

###    2.1.4 混合加密 ---->使用 非对称加密算法 加密 对称加密算法中所使用的密钥

###         

-SSL/TLS都采用了混合密码系统

##    2.2 单项散列函数<=>**消息摘要**函数 Message Digest Function(哈希函数 ) ---->输出散列值，也被称为消息摘要

单项散列函数的**特点**：

-根据**任意长度**的消息，计算出**固定长度**的散列值，**可以把大量信息压缩为一个固定长度的散列值,可以验证消息是否被篡改;**

-计算速度快

-消息不同，散列值不同。（哪怕 消息只有1比特的区别，也会产生完全不同的散列值）

-具备单向性，即不可逆行。（有消息可以计算出散列值，但是由散列值 不能 到推出消息内容）

几种**常见的散列函数**： 

-MD4  ,  MD5  :  MD就是Message Digest的缩写，产生128bit 的散列值，目前已经不安全  (中国人破解哦) 

-SHA-1：产生160bit的散列值，目前已经不安全。(中国人破解哦)

-SHA-2：SHA-256、SHA-384、SHA-512，对应的计算出的散列值长度分别是 256bit、384bit、512bit。

单向散列函数的**应用场景**

-**监测文件是否被篡改**，文件被篡改后的散列值和篡改前的散列值如果不同，则说明文件被篡改过。

-用户密码加密，一般不会将用户密码明文传给服务器保存到服务器对应的数据库中，通常做法是获取密码散列值传给后端，这样服务端也不知道用户密码是什么，所以一般用户忘记密码后就无法找回，只能通过重置密码解决。如果一个平台可以找回密码，说明该平台是不安全的。另外，为了防止用户密码相同或过于简单，增加安全性可以采取先加盐再获取散列值的策略。

##    2.3 数字签名 ----> 用于鉴定消息是否被篡改，不是为了保证机密性

-**用私钥 加密消息的散列值，生成的密文**

-数字签名，其实就是将 非对称加密 反过来使用。

-在**非对称密码体系**中，任何人都可以使用公钥进行加密，只有消息接收者才拥有私钥解密消息；

-  在**数字签名**中，只有消息发送者才能拥有私钥，并借助私钥**签名--即加密**，任何人都可以使用公钥**验证签名--即解密**。

正确使用数字签名的前提是：用于验证签名的公钥必须 属于 真正的消息发送者

若是遇到中间人攻击：公钥 将是伪造的，数字签名将失效

-中间人攻击 也是**Charles(花瓶)**抓包的原理

-所以在验证签名之前，首先要验证**公钥**的合法性

-如何**验证公钥的合法性** ------>**证书**

###    2.4 证书  ---  用CA的私钥， 对其他人的公钥生成数字签名

-**证书**由三部分组成  = 个人信息 + 此人的公钥 + 认证机构（certificate Authority , CA）。对**“个人信息 + 公钥”的散列值**施加**数字签名** ，

-**CA**是指能够认定“公钥确实属于此人”并**能够生成数字签名**的个人或者组织。

-证书的作用就是**检验公钥的合法性**，这样消息发送者与消息接收者之间不直接发送公钥,而是通过CA机构验证,可以避免中间人的攻击

- 证书的使用流程

​      从上图中可以看出消息接收者需要生成**密钥对**，并将自己的**公钥给权威认证机构**，**权威机构**会用自己私钥对消息接收      者的公钥施加**数字签名**，制作成证书并保存在权威机构的仓库中。于此同时，消息发送者可以通过正规渠道获取拿到**权威机构公钥(一般是提前内置的**，如 每台iPhone 设备中都内置 apple 的公钥)，并能下载证书，此时可以用权威机构的公钥验证证书的合法性。

##    2.5 签名机制 

-iOS签名机制主要是保证安装到用户手机上的APP都是经过Apple 官方允许的，如果篡改了 App 本身的源码或资源文件，签名值将无法对应上，便无法安装。实际开发过程中不管是真机调试，还是发布APP，开发者都需要经过一系列复杂的步骤，这些步骤都是为了防止随意安装 App。

-**Mac 设备具有生成公钥和私钥的能力**，平时操作钥匙串工具`钥匙串访问-->证书助理-->从证书颁发机构请求证书`主要目的就是为了生成 Mac 公私钥，之后再将**公钥上传到苹果后台**，用于制作证书。

-Apple 本身可以认为是权威机构，**Apple 后台**可以生成私钥，**iOS 设备中有公钥**。

- 签名机制流程

  -1、当运行`CMD + R`的时候，此时会进行代码签名，即拿 **Mac 本地的私钥**对应用签名生成 ipa 安装包（Xcode的codesign操作），ipa 安装包中主要包含应用、签名、资源文件等。

  -2、将 Mac 本地生成的公钥上传到 Apple 后台，Apple 后台用自己的私钥生成证书文件，证书中包含 Mac 公钥以及签名。

  -3、选择相应的证书、devices、app id、entitlements(应用中所包含的权限)，然后苹果后台用自己的私钥将这些内容签名，并生成描述文件。说明：entitlements 权限是在创建 app id 时添加的。

  -4、iOS 设备中包含苹果的公钥，使用公钥验证签名文件，如果验证通过则可以获取证书。于此同时，还会比对相应的devices、app id、entitlements(权限)是否一致。

  -5、使用iOS 设备中的苹果公钥验证证书签名，如果签名验证成功则会获取到 Mac 公钥。

  -6、使用 Mac 公钥验证 ipa 安装包签名，如果验证成功则直接安转应用。

  -【 2、5】步骤，其中苹果充当 CA 机构，确保 Mac 公钥的合法性。

  -【3、4 】步骤是为了防止devices、App id 、权限等被串改。

###      2.6 签名流程对应的操作 

​       

### 2.7 线上 App 签名机制

   -如果 APP 是从 AppStore 下载安装的，会发现里面是没有 mobileprovision 文件。

   -线上 app 的验证流程简单很多，应用上传到 Apple 后台，Apple 会用自己的私钥进行签名，下载应用的设备中包含 Apple 公钥，应用下载完成，直接可以用设备中的 Apple 公钥进行验证。流程如下：

### 2.8 加解密 补充内容 -------- HTTPS

   -**超文本传输安全协议**经由 超文本传输协议http 进行通信，但利用SSL/TLS来加密数据包。

   -HTTPS开发的主要目的，是提供对网络服务器的身份认证，保护交换数据的隐私与完整性。

   -采用 混合密码系统，https 中的服务端相当于消息接收者，客服端相当于消息发送者。

   -HTTPS协议栈 如下图：

-**HTTPS流程步骤**

**1. 客户端发起HTTPS请求**

-用户在浏览器里输入一个https网址，然后连接到server的443端口。

**2. 服务端的配置**

-采用HTTPS协议的服务器必须要有一套数字证书，可以自己制作，也可以向组织申请。区别就是自己颁发的证书需要客户端验证通过，才可以继续访问，而使用受信任的公司申请的证书则不会弹出提示页面(startssl就是个不错的选择，有1年的免费服务)。这套证书其实就是一对公钥和私钥。

**3. 传送证书**

-这个证书其实就是公钥，只是包含了很多信息，如证书的颁发机构，过期时间等等。

**4. 客户端解析证书**

-这部分工作是由客户端的TLS来完成的，首先会验证公钥是否有效，比如颁发机构，过期时间等等，如果发现异常，则会弹出一个警告框，提示证书存在问题。如果证书没有问题，那么就生成一个**随机值**（即**对称加密的 密钥**）。然后用证书对该随机值进行加密 （即用 非对称加密的公钥 加密 对称加密的密钥 ）。

**5. 传送加密信息**

-这部分传送的是用证书加密后的随机值，目的就是让服务端得到这个随机值，以后客户端和服务端的通信就可以通过这个随机值来进行加密解密了。【即 服务端 与客户端 完成协调 对称加密的 密钥】

**6. 服务端解密信息**

-服务端用私钥解密后，得到了客户端传过来的随机值【对称密钥】，然后把内容通过该值进行对称加密。

**7. 传输加密后的信息**

-这部分信息是服务段用**对称密钥**加密后的信息，可以在客户端被还原

**8. 客户端解密信息**

客户端用之前生成的**随机值**解密服务段传过来的信息，于是获取了解密后的内容。整个过程第三方即使监听到了数据，也束手无策。

#### **【SSL/TLS概念**】------> SSL/TLS是加密通信协议

**传输层安全性协议**（英语：Transport Layer Security，[缩写](https://baike.baidu.com/item/缩写)作**TLS**），及其前身**安全套接层**（Secure Sockets Layer，缩写作**SSL**）是一种[安全协议](https://baike.baidu.com/item/安全协议)，它实现了将应用层的报文进行加密后再交由TCP进行传输的功能。

SSL/TLS协议的基本思路是采用 非对称加密算法，也就是说，客户端先向服务器端索要公钥，然后用公钥加密信息，服务器收到密文后，用自己的私钥解密。

TLS协议主要解决如下三个网络安全问题。

1.保密(message privacy)，保密通过加密encryption实现，所有信息都加密传输，第三方无法嗅探；

2.完整性(message integrity)，通过MAC校验机制，一旦被篡改，通信双方会立刻发现；

3.认证(mutual authentication)，双方认证,双方都可以配备证书，防止身份被冒充；

SSL/TLS协议的基本过程是这样的：

（1） 客户端向服务器端索要并验证公钥。

（2） 双方协商生成"对话密钥"。

（3） 双方采用"对话密钥"进行加密通信。

所以说SSL/TLS协议主要是包含**非对称加密（公钥加密**）和**对称加密**，用**非对称加密**来得到**对称加密的"对话秘钥"**，然后用**对称加密**来进行**加密通信**。