Encryption、Signature、Token&SessionID、HTTPS
前言：iOS的安全有很多种，其中涉及到网络安全，主要能实现数据的保密性、完整性及身份验证等，这里就牵涉到了以下一些关键词:
加密解密、数字签名和证书、Token&SessionID、Https等；
加密与解决了解iOS加密算法之前，可以先了解一下加密算法;
加密与解密是一套完整的技术，先来看看这两个词语的专业解释。
- 加密：数据加密的基本过程就是对原来为明文的文件或数据按某种算法进行处理，使其成为不可读的一段代码为“密文”，使其只能在输入相应的密钥之后才能显示出原容，通过这样的途径来达到保护数据不被非法人窃取、阅读的目的。
- 解密：该过程的逆过程为解密，即将该编码信息转化为其原来数据的过程。
- 保密性：防止用户的标识或数据被读取。
- 数据完整性：防止数据被更改。
- 身份验证：确保数据发自特定的一方。
以下我们主挑加密来分析，解密与之逆向理解即可。
从宏观上来看，加密算法可以归结为如下三大类：
3.1. 哈希算法 - 英语：Secure Hash Algorithm，缩写为SHA）是一个密码散列函数家族，是FIPS所认证的安全散列算法。能计算出一个数字消息所对应到的，长度固定的字符串（又称消息摘要）的算法。且若输入的消息不同，它们对应到不同字符串的机率很高。
3.2. 对称加密算法 - 对称加密(也叫私钥加密)指加密和解密使用相同密钥的加密算法。有时又叫传统密码算法，就是加密密钥能够从解密密钥中推算出来，同时解密密钥也可以从加密密钥中推算出来。而在大多数的对称算法中，加密密钥和解密密钥是相同的，所以也称这种加密算法为秘密密钥算法或单密钥算法。
3.3. 非对称加密算法 - 非对称加密算法需要两个密钥：公开密钥（publickey:简称公钥）和私有密钥（privatekey:简称私钥）。公钥与私钥是一对，如果用公钥对数据进行加密，只有用对应的私钥才能解密。因为加密和解密使用的是两个不同的密钥，所以这种算法叫作非对称加密算法。
下表中补充了常用但严格意义上不算算法的其他编码方式：
| 分类 | 名称 |
|---|---|
| 哈希算法 | SHA-1 SHA-2 SHA-224 SHA-256 SHA-384 SHA-512 HMAC |
| 对称加密算法 | DES 3DES AES TripleDES TDEA Blowfish RC2 RC4 RC5 IDEA |
| 非对称加密算法 | RSA Elgamal 背包算法 Rabin D-H ECC（椭圆曲线加密算法） |
| 其他编码 | md5 base64 加盐 |
Base64是一种将二进制流表示为 64 个字符的编码方式。Base64并不是一种加密方式，明文使用Base64编码后的字符串通过索引表可以直接还原为明文。因此，Base64只能算是一个编码算法，对数据内容进行编码来适合传输。
对于安全性要求高的项目中，加密是必不可少的一项技术。以下是app中常用的加密及编码方式:
- 对称加密:
- DES
- 3DES
- AES
- 哈希算法:
- SHA-2
- 非对称加密:
- RSA
- 其他编码方式:
- md5
- base64
- 加盐
证明消息是某个特定的人，而不是随随便便一个人发送的（有效性）；除此之外，数字签名还能证明消息没有被篡改（完整性）。简单来说，数字签名就是非对称加密的逆应用，用私钥加密消息，用公钥解密消息。
数字签名在发送方：
- 对消息进行哈希计算，得到哈希值
- 利用私钥对哈希值进行加密，生成签名
- 将签名附加在消息后面，一起发送过去
数字签名验证在接收方：
- 收到消息后，提取消息中的签名
- 用公钥对签名进行解密，得到哈希值1。
- 对消息中的正文进行哈希计算，得到哈希值2。
- 比较哈希值1和哈希值2，如果相同，则验证成功。
上面的一切都很完美，你用公钥能够解密，说明确实是私钥方发送的，你很放心，但有没有想过，万一这把公钥本身，就被人做了手脚？为了保证“公钥”是可信的，数字证书应运而生。
数字证书一般包含：公钥，证书的数字签名，公钥拥有者的信息。若证书验证成功，这表示该公钥是合法，可信的。
数字证书里有个概念，认证机构(Certification Authority， CA)，发送方先把自己的公钥给CA，CA对其进行加密得到加密后的发送方公钥（用的是CA的私钥和CA加密算法），也就是CA的数字证书。
如何生成证书？
- 发送方将公钥A给CA
- CA用自己的私钥，对发送方的公钥和一些相关信息一起加密，生成"数字证书"
- 发送方发送时不仅发送内容、数字签名，还包含发送方的数字证书。
如何验证证书？
- 接收方拿到后，首先使用CA的公钥验证证书的数字签名，
- 验证通过后则可以使用数字证书中的发送方公钥。
CA是第三方机构，CA公钥是公开的，通过其他可信的方式提前获取得到的，因此不可能伪造。
Token:可以设置过期时间
SessionID:
因为HTTP在传输数据时使用的是明文是不安全的，为了解决这一隐患网景公司推出了SSL安全套接字协议层，SSL是基于HTTP之下TCP之上的一个协议层，是基于HTTP标准并对TCP传输数据时进行加密，所以HPPTS是HTTP+SSL/TCP的简称。
在SSL 3之后SSL重命名为TLS，是更为安全的升级版 SSL。
SSL/TLS协议基本过程包含四次握手，所以常说的HTTPS的七次握手就是TCP的三次加SSL/TLS的四次。
(1) 客户端发出请求（ClientHello） 首先，客户端（通常是浏览器）先向服务器发出加密通信的请求，这被叫做ClientHello请求。在这一步，客户端主要向服务器提供以下信息。
- 支持的协议版本，比如TLS 1.0版。
- 一个客户端生成的随机数，稍后用于生成"对话密钥"。
- 支持的加密方法。
- 支持的压缩方法。
(2) 服务器回应（SeverHello） 服务器收到客户端请求后，向客户端发出回应，这叫做SeverHello。服务器的回应包含以下内容。
- 确认使用的加密通信协议版本，比如TLS 1.0版本。如果浏览器与服务器支持的版本不一致，服务器关闭加密通信。
- 一个服务器生成的随机数，稍后用于生成"对话密钥"。
- 确认使用的加密方法。
- 服务器证书。
(3) 客户端回应
客户端收到服务器回应以后，首先验证服务器证书。如果证书不是可信机构颁布、或者证书中的域名与实际域名不一致、或者证书已经过期，就会向访问者显示一个警告，由其选择是否还要继续通信。如下图
如果证书没有问题，客户端就会从证书中取出服务器的公钥。然后，向服务器发送下面三项信息。
- 一个随机数。该随机数用服务器公钥加密，防止被窃听。
- 编码改变通知，表示随后的信息都将用双方商定的加密方法和密钥发送。
- 客户端握手结束通知，表示客户端的握手阶段已经结束。这一项同时也是前面发送的所有内容的hash值，用来供服务器校验。
上面第一项的随机数，是整个握手阶段出现的第三个随机数，又称"pre-master key"。有了它以后，客户端和服务器就同时有了三个随机数，接着双方就用事先商定的加密方法，各自生成本次会话所用的同一把"会话密钥"。
(4) 服务器的最后回应 服务器收到客户端的第三个随机数pre-master key之后，计算生成本次会话所用的"会话密钥"。然后，向客户端最后发送下面信息。
编码改变通知，表示随后的信息都将用双方商定的加密方法和密钥发送。
服务器握手结束通知，表示服务器的握手阶段已经结束。
至此，整个握手阶段全部结束。接下来，客户端与服务器进入加密通信，就完全是使用普通的HTTP协议，只不过用"会话密钥"加密内容。