iOS数据安全与加密算法

作者: 陵无山 | 来源:发表于2018-07-21 15:17 被阅读304次

背景

随着移动互联网的普及，被越来越多的心怀不轨的人觊觎，也越来越多的安全问题暴露了出来。开发者开发出来的应用被安装在设备上之后，用户并不具有专业的安全知识。因此，开发者有义务为用户的安全保驾护航，能够为用户提供可信赖的服务才会被其青睐。
攻击者在暗，我们在明，我们不知道对方会使用怎样的方式威胁到应用的安全。因此我先就最坏的情况来考虑，即会有人恶意去逆向我们的应用，我们应该怎么样去应对这些可能出现的危险。

总之，黑客很厉害，关键是其中有很多心怀不轨的坏人，所以开发应用时讲究安全很重要。

常用的逆向分析手段

要知道怎么防备，我们就需要知道一些常用的逆向分析方式，这样才能知己知彼。通常来说分析有三种手段：

静态分析

静态分析这一阶段主要会利用给各种工具，来帮助开发者分析目标软件，常用的工具有比如Hopper、IDA、Keychain-Dumper、Class-dump等。
其中IDA是效果最好也是最贵的，代码还原度很高，基本上可以照着理清楚代码的逻辑了。

动态分析

动态分析是指在软件运行的过程中进行调试分析。
在iOS中runtime扮演了一个很重要的角色，我们在动态分析的过程中往往也是借助了runtime的强大能力来进行的，比如我们可以动态地更改代码的行为、可以获取到当前的视图层次等等。
这一部分我们可以利用的工具有包括Cycript、Reveal、LLDB等。

网络分析

网络分析是指利用像Charles这样的抓包分析工具，分析应用的流量信息，安全意识比较差的公司做的一些产品我们往往能从中得到一些敏感信息。

iOS 安全手段

二进制安全

攻击者会拿到我们的应用进行分析，然后可能会篡改我们的执行文件或者是资源文件，因此我们有必要采用一些手段来防止他们窥探以及对应用的行为进行修改.

防止调试器依附
通常黑客可能会通过gdb或者lldb来调试我们的应用以验证代码的行为，为后一步攻击做准备。而调试器之所以能够工作是因为Ptrace的存在，它为调试器提供了监控目标进程的机会。因此，通常情况下，我们在应用中禁用掉它，这可以参考我之前写的这篇文章以及github的demo
越狱检测
当应用被安装在一台越狱后的设备之后，它所面临的安全风险就会相对来说大很多。而可能处于安全性的考虑，可能我们并不希望我们的应用运行在这样的环境下，因此我们可以通过一些检测来判断是否处在越狱的设备上。通常来说越狱设备上会安装Cydia、MobileSubstrate等。我们可以在代码中检测Applications下是否有相关应用存在，如果存在就可以给用户相应的提示并进行处理。
```
  - (BOOL)jailBreaked {
      if ([[UIApplication sharedApplication] canOpenURL:[NSURL URLWithString:@"cydia://"]]) {
          return YES;
      }
      return NO;
  }
```
敏感字符串安全
- 编译之后的应用中对已经初始化的字符串依然是可见的，把应用丢到IDA或者Hopper中很容易就看到一些敏感字符串的值了。
- 因此字符串的加密处理是很有必要的，比如我们可以用一些简单的加密算法加密特别敏感的字符串，这样初始化出来的字符串是一串不可读的问题，需要使用的时候再进行解密。
混淆
- 这一步主要是为了迷惑敌人的视线，提升分析难度。编译的时候可以通过脚本加入无意义的代码以及将正常的字符串替换为无意义的代码。
- 但是这样的方式会给自己在维护的时候带来一定困难，比如你的代码通过混淆后发生了crash，通过dsym符号表解析出来的崩溃信息也变得不可读了，还得对照混淆时候的映射表来查看，所以需要三思这个到底值不值得做。
- 除此之外，我们还可以混淆文件名。前几天想逆向看看滴滴的模块化是如何做的，无意发现了一张很有意思的图片，后缀表示是一个图片，但是实际上是个存有字符串的文件。我们可以用类似的方式伪装一些相对重要的文件
敏感业务用更安全的语言
OC是一门具有动态特性的语言，这给了攻击者很多机会去修改你原有代码的行为，甚至是加上新的代码。因此在核心部分可以使用更加安全的代码，比如我们可以使用C甚至汇编去写。往简单来说用Swift来写代码都比OC一定程度上来得安全。
自检
我们可以对二进制文件或者资源文件进行md5，然后交给我们的server去比对是否来自一个合法的应用，这一定程度上也能够提供一些防护性。

数据安全

简单介绍

我们的应用可能会在本地存储一系列的文件，包括用户数据，数据库文件，甚至在日益兴起的Hybrid开发或者是各种Patch方式中我们会下载的源码文件。我们应该尽可能地确保这些文件不会轻易被窃取到，即使窃取到了之后黑客也没办法使用.

最基础的是我们发送网络请求时，使用get和post方式发送请求。两者具体区别就不做解释了，只是引出相关安全性问题
- get：将参数暴露在外，（绝对不安全-->明文请求或者傻瓜式请求）
- post：将参数放到请求体body中，（相对于get比较安全-->但是我们可以很容易用一些软件截获请求数据。比如说Charles（青花瓷））
Charles（大部分app的数据来源都使用该工具来抓包，并做网络测试）

注意：Charles在使用中的乱码问题，可以显示包内容，然后打开info.plist文件，找到java目录下面的VMOptions，在后面添加一项：-Dfile.encoding=UTF-8
要想非常安全的传输数据，建议使用https。抓包不可以，但是中间人攻击则有可能。建议双向验证防止中间人攻击
中间人攻击
当我们上网浏览网页，从网上获取数据的时候，我们知道，不管是http还是https协议，都是服务端被动，客户端主动。所以，客户端第一次发出请求之后，通常无法确定服务端是不是合法。就很可能就会出现以下情景，正常情况下，我们想要根据文章aid查看某篇文章内容，其流程如下：

查看aid=100的文章.png

但如果遭受黑客攻击，流程就会这样的：

看aid=100的文章时遭受攻击.png

这就是中间人攻击，此时恶意服务端完全可以发起双向攻击：对上可以欺骗服务端，对下可以欺骗客户端，更严重的是客户端段和服务端完全感知不到已经被攻击了。

关于中间人攻击维基百科上有更深入的定义：
中间人攻击（Man-in-the-middle attack，缩写：MITM）是指攻击者与通讯的两端分别创建独立的联系，并交换其所收到的数据，使通讯的两端认为他们正在通过一个私密的连接与对方直接对话，但事实上整个会话都被攻击者完全控制。在中间人攻击中，攻击者可以拦截通讯双方的通话并插入新的内容。在许多情况下这是很简单的（例如，在一个未加密的Wi-Fi无线接入点的接受范围内的中间人攻击者，可以将自己作为一个中间人插入这个网络）。
一个中间人攻击能成功的前提条件是攻击者能将自己伪装成每一个参与会话的终端，并且不被其他终端识破。中间人攻击是一个（缺乏）相互认证的攻击。大多数的加密协议都专门加入了一些特殊的认证方法以阻止中间人攻击。例如，SSL协议可以验证参与通讯的一方或双方使用的证书是否是由权威的受信任的数字证书认证机构颁发，并且能执行双向身份认证。
证书锁定可以避免中间人攻击提高安全性

数据安全的原则

在网络上不允许传输用户隐私数据的明文（即:App网络传输安全，指对数据从客户端传输到Server中间过程的加密，防止网络世界当中其他节点对数据的窃听）
在本地不允许保存用户隐私数据的明文（即:App数据存储安全，主要指在磁盘做数据持久化的时候所做的加密）。
App代码安全（即:包括代码混淆，加密或者app加壳

手段

数据保护
- 我们需要将类似用户密码这样的敏感数据存到keychain中。我们还会在本地存储多种类型的文件，其中可能会包含一些敏感信息。
  
  使用苹果自己的SSKeyChain钥匙串，我们也能保证用户的数据安全，我们将用户的账号信息保存到钥匙串中能保证数据安全的原因是因为只有苹果公司才知道钥匙串保存在内存中的哪个位置
  使用SSKeyChain我们进行下面两步骤操作：
  1. 在工程中加入Security.framework框架。
  2. 把SSKeychain.h和SSKeychain.m加到项目文件夹。
  加入了需要的文件夹后，SSKeyChain的作者samsoffes在实例代码中给出了使用SSKeyChain的方法

    //获取所有账号
    + (NSArray *)allAccounts;
    //通过账号名字获取服务名
    + (NSArray *)accountsForService:(NSString *)serviceName;
    //通过服务名和账号获取密码
    + (NSString *)passwordForService:(NSString*)serviceNameaccount:(NSString *)account;
    //通过服务名和账号删除密码
    + (BOOL)deletePasswordForService:(NSString*)serviceNameaccount:(NSString *)account;
    //通过服务名和账号设置密码
    + (BOOL)setPassword:(NSString *)passwordforService:(NSString*)serviceName account:(NSString *)account;

我们在使用的时候是可以设置其访问安全限制的。比如下面在使用FileManager的时候使用 FileProtectionType.complete 用以保证文件只有在设备未被锁定时才可访问。同样在使用Keychain的时候也有类似的做法。
```
      try? FileManager.default.setAttributes([.protectionKey: FileProtectionType.complete], ofItemAtPath: "your path ")
```
数据擦除
有些敏感数据我们希望用完就把它给干掉，不留一点痕迹。比如用户在输入密码进行登录的时候，我们的viewModel上有一个叫做password的property。登录完成之后，我们即使把这个属性置为空之后值都依然在内存当中，这个时候我们可能需要手动地把这些敏感内容给擦掉。
防止键盘缓存
键盘的自动更正机制会缓存用户的输入，如果在一台越狱设备上的话很可能被第三方应用轻易地读取到缓存中的数据。
简单来说我们可以把UITextfield的autocorrectionType属性设置为No来关掉这个功能。在一些安全性要求较高的应用当中通常会自定义键盘，这样可以防止缓存被第三方应用读取到也能够防止被录屏（系统键盘按下有效果）

网络安全

在网络请求时，数据的安全性至关重要，而仅仅用 POST 请求提交用户的隐私数据，还是不能完全解决安全问题。因此：我们经常会用到加密技术，比如说在登录的时候，我们会先把密码用MD5加密再传输给服务器或者直接对所有的参数进行加密再POST到服务器。下面是一些网络安全手段：

不传输明文
我们不应该在网络中明文传输敏感数据。否则即使在没越狱的手机上，很容易遭到中间人攻击，黑客可以轻而易举地获取到用户的敏感数据
使用https
HTTPS（全称：Hyper Text Transfer Protocol over Secure Socket Layer），是以安全为目标的HTTP通道，简单讲是HTTP的安全版.
- 在HTTP下加入SSL层，HTTPS的安全基础是SSL，因此加密的详细内容就需要SSL。它是一个URI scheme（抽象标识符体系），句法类同http:体系。用于安全的HTTP数据传输。
- HTTPS的主要思想是在不安全的网络上创建一安全信道，并可在使用适当的加密包和服务器证书可被验证且可被信任时，对窃听和中间人攻击提供合理的保护
- HTTPS的信任继承基于预先安装在浏览器中的证书颁发机构（如VeriSign、Microsoft等）（意即“我信任证书颁发机构告诉我应该信任的”）
- 因此，一个到某网站的HTTPS连接可被信任，如果服务器搭建自己的https 也就是说采用自认证的方式来建立https信道，这样一般在客户端是不被信任的，所以我们一般在浏览器访问一些https站点的时候会有一个提示，问你是否继续
使用更安全的协议
比如我们可以使用二进制协议或者是自定义协议来提高安全性
Hybrid应用安全
如今React Native、Cordova等应用得越来越广，安全性也变得越来越重要。
在这样的开发中，Mobile扮演的角色就是一个浏览器，因此在前端开发中常用的防护手段也在此使用，比如JS代码混淆、XSS防护、加密传输等。

非恶意攻击造成的安全问题

以上大部分都是一些比较恶意的针对终端用户的攻击防护，所谓防君子不防小人，想要搞破坏的人总是会找到办法的。我们也还应该注意一些无意之间容易造成的安全问题。

应用退到后台
苹果会在应用退到后台的时候进行截屏，会将当户当前的状态截图保存下来，这可能会在无意之中造成用户数据的泄漏，因此我们可能需要主动地替换掉这张截图
警惕iCloud备份
用户在开启iCloud的情况下，可能会自动对文件目录进行自动备份，我们需要指定包含敏感信息的文件不能进行备份
注意Touch ID的变化
自从iPhone有Touch ID之后大大的方便了用户的使用，比如我们可以按一个手指就进行支付、登录等操作。我们在开发这样的业务逻辑的时候，应该考虑到这样的场景，会不会因为一些正常情况下手机借给朋友造成了信息或者财产的流逝
防止类似XcodeGhost事件再次发生
早前发生的XcodeGhost事件掀起了一阵波澜，让我们意识到，即使是非越狱设备上也可能由于疏忽造成一些安全问题，因此我们需要警惕类似的事件再次发生

数据加密的常用方式

常用加密算法

常用加密算法	名称	描述
编码方案	Base64	通过简单 BASE64编码防止数据明文传输
哈希(散列)函数	MD5(消息摘要算法)/SHA1/SHA256	对普通请求、返回数据，生成MD5校验（MD5中加入动态密钥），进行数据完整性（简单防篡改，安全性较低，优点：快速）校验
非对称加密算法	RSA	对于重要数据，使用RSA进行数字签名，起到防篡改作
对称加密算法	DES/AES	对于比较敏感的数据，如用户信息（登陆、注册等），客户端发送使用RSA加密，服务器返回使用DES(AES)加密
HTTPS	HTTP+SSL协议	要想非常安全的传输数据，建议使用https。抓包不可以，但是中间人攻击则有可能。建议双向验证防止中间人攻击

信息安全和相应技术对应的关系
安全算法和作用的关系图.png

Base64

Base64简单说明
描述：Base64可以成为密码学的基石，非常重要。
特点：可以将任意的二进制数据进行Base64编码
结果：所有的数据都能被编码为并只用65个字符就能表示的文本文件。
65字符：A~Z a~z 0~9 + / =
对文件进行base64编码后文件数据的变化：编码后的数据~=编码前数据的4/3，会大1/3左右。

命令行进行Base64编码和解码

 编码：base64 123.png -o 123.txt
 解码：base64 123.txt -o test.png -D

Base64编码原理
1. 将所有字符转化为ASCII码；
2. 将ASCII码转化为8位二进制；
3. 将二进制3个归成一组(不足3个在后边补0)共24位，再拆分成4组，每组6位；
4. 统一在6位二进制前补两个0凑足8位；
5. 将补0后的二进制转为十进制；
6. 从Base64编码表获取十进制对应的Base64编码；
处理过程说明：
a.转换的时候，将三个byte的数据，先后放入一个24bit的缓冲区中，先来的byte占高位。
b.数据不足3byte的话，于缓冲区中剩下的bit用0补足。然后，每次取出6个bit，按照其值选择查表选择对应的字符作为编码后的输出。
c.不断进行，直到全部输入数据转换完成。
d.如果最后剩下两个输入数据，在编码结果后加1个“=”；
e.如果最后剩下一个输入数据，编码结果后加2个“=”；
f.如果没有剩下任何数据，就什么都不要加，这样才可以保证资料还原的正确性。
g.编码"Man"->Base64:"TWFu"

man-base64.png

实现

 a.说明：
     1）从iOS7.0 开始，苹果就提供了base64的编码和解码支持
     2)如果是老项目，则还能看到base64编码和解码的第三方框架，如果当前不再支持iOS7.0以下版本，则建议替换。

 b.相关代码：
 //给定一个字符串，对该字符串进行Base64编码，然后返回编码后的结果
 -(NSString *)base64EncodeString:(NSString *)string
 {
     //1.先把字符串转换为二进制数据
     NSData *data = [string dataUsingEncoding:NSUTF8StringEncoding];

     //2.对二进制数据进行base64编码，返回编码后的字符串
     return [data base64EncodedStringWithOptions:0];
 }

 //对base64编码后的字符串进行解码
 -(NSString *)base64DecodeString:(NSString *)string
 {
     //1.将base64编码后的字符串『解码』为二进制数据
     NSData *data = [[NSData alloc]initWithBase64EncodedString:string options:0];

     //2.把二进制数据转换为字符串返回
     return [[NSString alloc]initWithData:data encoding:NSUTF8StringEncoding];
 }

 c.终端测试命令
     $ echo -n A | base64
     $ echo -n QQ== |base64 -D

常见的加密算法和其它

base64 编码格式
密码学演化 "秘密本"-->RSA
常见的加密算法
- 1）消息摘要（单向散列函数）
- 2）对称加密
- 3）非对称加密
- 4）证书等

哈希散列函数

单向散列函数的特点：
- ①加密后密文的长度是定长的
- ②如果明文不一样，那么散列后的结果一定不一样
- ③如果明文一样，那么加密后的密文一定一样（对相同数据加密，加密后的密文一样）
- ④所有的加密算法是公开的
- ⑤不可以逆推反算
经典加密算法
- 1）MD5加密
- 2）SHA1
- 3）SHA512
MD5加密算法简单说明
- 1）对字符串进行MD5加密可以得到一个32个字符的密文
- 2）加密之后不能根据密文逆推出明文
- 3）MD5已经被破解（暴力破解|碰撞检测）

MD5加密进阶

1）先加盐，然后再进行MD5
2）先乱序，再进行MD5加密
3）乱序|加盐，多次MD5加密等
4）使用消息认证机制，即HMAC-MD5-先对密钥进行加密，加密之后进行两次MD5散列

5）加密命令行

  MD5加密-字符串    $ echo -n "520it" |md5
  MD5加密-文件1     $ md5 abc.png
  SHA1加密：        $ echo -n "520it" |openssl sha -sha1
  SHA256            $ echo -n "520it" |openssl sha -sha256
  SHA512            $ echo -n "520it" |openssl sha -sha512
  hmacMD5加密       $ echo -n "520it" |openssl dgst -md5 -hmac "123"

散列函数应用领域
1）搜索多个关键字，先对每个关键字进行散列，然后多个关键字进行或运算，如果值一致则搜索结果一致
2）版权对文件进行散列判断该文件是否是正版或原版的
3）文件完整性验证 对整个文件进行散列，比较散列值判断文件是否完整或被篡改
消息认证机制（HMAC）简单说明
1）原理
①消息的发送者和接收者有一个共享密钥
②发送者使用共享密钥对消息加密计算得到MAC值（消息认证码）
③消息接收者使用共享密钥对消息加密计算得到MAC值
④比较两个MAC值是否一致
2）使用
①客户端需要在发送的时候把（消息）+（消息·HMAC）一起发送给服务器
②服务器接收到数据后，对拿到的消息用共享的KEY进行HMAC，比较是否一致，如果一致则信任

简单示例

 #pragma mark - md5加密方法
 - (NSString *)md5String {
     const char *str = self.UTF8String;
     uint8_t buffer[CC_MD5_DIGEST_LENGTH];
     CC_MD5(str, (CC_LONG)strlen(str), buffer);
     return [self stringFromBytes:buffer length:CC_MD5_DIGEST_LENGTH];
 }
  
 #pragma mark - HMACMD5加密方法
 - (NSString *)hmacMD5StringWithKey:(NSString *)key {
     const char *keyData = key.UTF8String;
     const char *strData = self.UTF8String;
     uint8_t buffer[CC_MD5_DIGEST_LENGTH];
     CCHmac(kCCHmacAlgMD5, keyData, strlen(keyData), strData, strlen(strData), buffer);
     return [self stringFromBytes:buffer length:CC_MD5_DIGEST_LENGTH];
 }
  
 /**
  *  返回二进制 Bytes 流的字符串表示形式
  *  @param bytes  二进制 Bytes 数组
  *  @param length 数组长度
  *  @return 字符串表示形式
  */
 - (NSString *)stringFromBytes:(uint8_t *)bytes length:(int)length {
     NSMutableString *strM = [NSMutableString string];
     for (int i = 0; i < length; i++) {
         [strM appendFormat:@"%02x", bytes[i]];
     }
     return [strM copy];
 }
  
 // md5加密调用
 NSLog(@"%@",[@"520it" md5String]);
 // (明文+加盐)MD5加密调用
 NSLog(@"%@",[[@"520it" stringByAppendingString:salt] md5String]);
 // hmacMD5加密调用（先加密+乱序）
 NSLog(@"%@",[@"520it" hmacMD5StringWithKey:@"xiaomage"]);

MD5认证图解

MD5认证图解.png

对称加密

对称加密的特点
1）加密/解密使用相同的密钥
2）加密和解密的过程是可逆的（明文->密文->明文）
对称加密算法图解.png
经典算法
1）DES 数据加密标准
2）3DES 使用3个密钥，对消息进行（密钥1·加密）+（密钥2·解密）+（密钥3·加密）
3）AES 高级加密标准
分组密码简单说明
- 密码算法可以分为分组密码和流密码两种。
- 分组密码：每次只能处理特定长度的一组数据的一类密码算法。一个分组的比特数量就称之为分组长度。
  
  DES和3DES的分组长度都是64比特。即每次只能加密64比特的明文，并生成64比特的密文。AES的分组长度有128比特、192比特和256比特可以选择。
- 流密码：对数据流进行连续处理的一类算法。流密码中一般以1比特、8比特或者是32比特等作为单位俩进行加密和解密。
ECB分组模式
ECB模式的全称为Electronic CodeBook模式。又成为电子密码本模式。
特点：
- 1）使用ECB模式加密的时候，相同的明文分组会被转换为相同的密文分组。
- 2）类似于一个巨大的明文分组->密文分组的对照表。

ECB模式加密.png

CBC分组模式
CBC模式全称为Cipher Block Chainning模式（密文分组链接模式|电子密码链条）
特点：在CBC模式中，首先将明文分组与前一个密文分组进行XOR运算，然后再进行加密

终端测试命令：
    加密 $ openssl enc -des-ecb -K 616263 -nosalt -in 123.txt -out 123.bin
    解密 $ openssl enc -des-ecb -K 616263 -nosalt -in 123.bin -out 1231.txt -d

简单示例


/**
 *  加密字符串并返回base64编码字符串
 *
 *  @param string    要加密的字符串
 *  @param keyString 加密密钥
 *  @param iv        初始化向量(8个字节)
 *
 *  @return 返回加密后的base64编码字符串
 */
- (NSString *)encryptString:(NSString *)string keyString:(NSString *)keyString iv:(NSData *)iv;
/**
 *  解密字符串
 *
 *  @param string    加密并base64编码后的字符串
 *  @param keyString 解密密钥
 *  @param iv        初始化向量(8个字节)
 *
 *  @return 返回解密后的字符串
 */
- (NSString *)decryptString:(NSString *)string keyString:(NSString *)keyString iv:(NSData *)iv;
// 调用
EncryptionTools *encrypt = [EncryptionTools sharedEncryptionTools];
NSLog(@"%@",[encrypt encryptString:@"LN123" keyString:@"LN" iv:nil]);
NSLog(@"%@",[encrypt decryptString:@"OPcTMDB5paivqtYo9Fj+hQ==" keyString:@"LN" iv:nil]);

非对称加密RSA

非对称加密的特点
- 1）使用公钥加密，使用私钥解密
- 2）公钥是公开的，私钥保密
- 3）加密处理安全，但是性能极差
经典算法---RSA
- RSA 原理
  - （1）求N，准备两个质数p和q,N = p x q
  - （2）求L,L是p-1和q-1的最小公倍数。L = lcm（p-1,q-1）
  - （3）求E，E和L的最大公约数为1（E和L互质）
  - （4）求D，E x D mode L = 1
- RSA加密小实践
  - （1）p = 17,q = 19 =>N = 323
  - （2）lcm（p-1,q-1）=>lcm（16，18）=>L= 144
  - （3）gcd（E,L）=1 =>E=5
  - （4）E乘以几可以mode L =1? D=29可以满足
  - （5）得到公钥为：E=5,N=323
  - （6）得到私钥为：D=29,N=323
  - （7）加密明文的E次方 mod N = 123的5次方 mod 323 = 225（密文）
  - （8）解密密文的D次方 mod N = 225的29次方 mod 323 = 123（明文）

非对称加密RSA图解.png

**openssl生成密钥命令**
生成强度是 512 的 RSA 私钥：`$ openssl genrsa -out private.pem 512`
以明文输出私钥内容：`$ openssl rsa -in private.pem -text -out private.txt`
校验私钥文件：`$ openssl rsa -in private.pem -check`
从私钥中提取公钥：`$ openssl rsa -in private.pem -out public.pem -outform PEM -pubout`
以明文输出公钥内容：`$ openssl rsa -in public.pem -out public.txt -pubin -pubout -text`
使用公钥加密小文件：`$ openssl rsautl -encrypt -pubin -inkey public.pem -in msg.txt -out msg.bin`
使用私钥解密小文件：`$ openssl rsautl -decrypt -inkey private.pem -in msg.bin -out a.txt`
将私钥转换成 DER 格式：`$ openssl rsa -in private.pem -out private.der -outform der`
将公钥转换成 DER 格式：`$ openssl rsa -in public.pem -out public.der -pubin -outform der`

简单示例

// 公钥加密时调用类方法：
+ (NSString *)encryptString:(NSString *)str publicKey:(NSString *)pubKey;
+ (NSData *)encryptData:(NSData *)data publicKey:(NSString *)pubKey;
// 私钥解密时调用类方法
+ (NSString *)decryptString:(NSString *)str privateKey:(NSString *)privKey;
+ (NSData *)decryptData:(NSData *)data privateKey:(NSString *)privacy;
 
/** 调用 */
NSString *str = [RSAUtil encryptString: @"LN" publicKey:RSA_Public_key];
NSLog(@"RSA公钥加密数据-->\n%@",str);
 
NSString *str1 = [RSAUtil decryptString:str privateKey:RSA_Privite_key];
NSLog(@"RSA私钥解密数据-->%@",str1);

数字签名

数字签名的应用场景
答：需要严格验证发送方身份信息情况
数字签名原理
- 1）客户端处理
  - ①对"消息"进行 HASH 得到 "消息摘要"
  - ②发送方使用自己的私钥对"消息摘要" 加密(数字签名)
  - ③把数字签名附着在"报文"的末尾一起发送给接收方
- 2）服务端处理
  - ①对"消息" HASH 得到 "报文摘要"
  - ②使用公钥对"数字签名" 解密
  - ③对结果进行匹配

数字签名图解.png

数字证书

简单说明
证书和驾照很相似，里面记有姓名、组织、地址等个人信息，以及属于此人的公钥，并有认证机构施加数字签名,只要看到公钥证书，我们就可以知道认证机构认证该公钥的确属于此人
数字证书的内容
- 1）公钥
- 2）认证机构的数字签名
证书的生成步骤
- 1）生成私钥 openssl genrsa -out private.pem 1024
- 2）创建证书请求 openssl req -new -key private.pem -out rsacert.csr
- 3）生成证书并签名，有效期10年 openssl x509 -req -days 3650 -in rsacert.csr -signkey private.pem -out rsacert.crt
- 4）将 PEM 格式文件转换成 DER 格式 openssl x509 -outform der -in rsacert.crt -out rsacert.der
- 5）导出P12文件 openssl pkcs12 -export -out p.p12 -inkey private.pem -in rsacert.crt
iOS开发中的注意点
- 1）在iOS开发中，不能直接使用 PEM 格式的证书，因为其内部进行了Base64编码，应该使用的是DER的证书，是二进制格式的
- 2）OpenSSL默认生成的都是PEM格式的证书
证书锁定的缺点
- 证书锁定尽管带了较高的安全性，但是这种安全性的提高却牺牲了灵活性。一旦当证书发生变化时，我们的客户端也必须随之升级，除此之外，我们的服务端不得不为了兼容以前的客户端而做出一些妥协或者说直接停用以前的客户端，这对开发者和用户来说并不是那么的友好。
- 但实际上，极少情况下我们才会变动证书。因此，如果产品安全性要求比较高还是启动证书锁定吧。
- 在iOS开发中，我们可以自己给自己签发数字证书，就类似于12306购票网站。从而保证了数据的安全性。

证书锁定避免中间人攻击.png

使用Https

https简单说明
- HTTPS（全称：Hyper Text Transfer Protocol over Secure Socket Layer），是以安全为目标的HTTP通道，简单讲是HTTP的安全版。
- 即HTTP下加入SSL层，HTTPS的安全基础是SSL，因此加密的详细内容就需要SSL。它是一个URI scheme（抽象标识符体系），句法类同http:体系。用于安全的HTTP数据传输。
- https:URL表明它使用了HTTP，但HTTPS存在不同于HTTP的默认端口及一个加密/身份验证层（在HTTP与TCP之间）。
HTTPS和HTTP的区别主要为以下四点：
- 一、https协议需要到ca申请证书，一般免费证书很少，需要交费。
- 二、http是超文本传输协议，信息是明文传输，https 则是具有安全性的ssl加密传输协议。
- 三、http和https使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443。
- 四、http的连接很简单，是无状态的；HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，比http协议安全。
简单说明
- 1）HTTPS的主要思想是在不安全的网络上创建一安全信道，并可在使用适当的加密包和服务器证书可被验证且可被信任时，对窃听和中间人攻击提供合理的保护。
- 2）HTTPS的信任继承基于预先安装在浏览器中的证书颁发机构（如VeriSign、Microsoft等）（意即“我信任证书颁发机构告诉我应该信任的”）。
- 3）因此，一个到某网站的HTTPS连接可被信任，如果服务器搭建自己的https 也就是说采用自认证的方式来建立https信道，这样一般在客户端是不被信任的。
- 4）所以我们一般在浏览器访问一些https站点的时候会有一个提示，问你是否继续。

对开发的影响。

1、如果是自己使用NSURLSession来封装网络请求，涉及代码如下。

- (void)touchesBegan:(NSSet *)touches withEvent:(UIEvent *)event
{
    NSURLSession *session = [NSURLSession sessionWithConfiguration:[NSURLSessionConfiguration defaultSessionConfiguration] delegate:self delegateQueue:[NSOperationQueue mainQueue]];

    NSURLSessionDataTask *task =  [session dataTaskWithURL:[NSURL URLWithString:@"https://www.apple.com"] completionHandler:^(NSData *data, NSURLResponse *response, NSError *error) {
        NSLog(@"%@", [[NSString alloc] initWithData:data encoding:NSUTF8StringEncoding]);
    }];
    [task resume];
}
/*
 只要请求的地址是HTTPS的, 就会调用这个代理方法
 我们需要在该方法中告诉系统, 是否信任服务器返回的证书
 Challenge: 挑战 质问 (包含了受保护的区域)
 protectionSpace : 受保护区域
 NSURLAuthenticationMethodServerTrust : 证书的类型是 服务器信任
 */
- (void)URLSession:(NSURLSession *)session didReceiveChallenge:(NSURLAuthenticationChallenge *)challenge completionHandler:(void (^)(NSURLSessionAuthChallengeDisposition, NSURLCredential *))completionHandler
{
    //    NSLog(@"didReceiveChallenge %@", challenge.protectionSpace);
    NSLog(@"调用了最外层");
    // 1.判断服务器返回的证书类型, 是否是服务器信任
    if ([challenge.protectionSpace.authenticationMethod isEqualToString:NSURLAuthenticationMethodServerTrust]) {
        NSLog(@"调用了里面这一层是服务器信任的证书");
        /*
         NSURLSessionAuthChallengeUseCredential = 0,                     使用证书
         NSURLSessionAuthChallengePerformDefaultHandling = 1,            忽略证书(默认的处理方式)
         NSURLSessionAuthChallengeCancelAuthenticationChallenge = 2,     忽略书证, 并取消这次请求
         NSURLSessionAuthChallengeRejectProtectionSpace = 3,            拒绝当前这一次, 下一次再询问
         */
//        NSURLCredential *credential = [NSURLCredential credentialForTrust:challenge.protectionSpace.serverTrust];

        NSURLCredential *card = [[NSURLCredential alloc]initWithTrust:challenge.protectionSpace.serverTrust];
        completionHandler(NSURLSessionAuthChallengeUseCredential , card);
    }
}

2、如果使用AFN网络请求

AFHTTPSessionManager *manager = [AFHTTPSessionManager manager];
 
// 更改解析方式（请求网页源码应使用原始解析）
manager.responseSerializer = [AFHTTPResponseSerializer serializer];
 
// 设置对证书的处理方式
// 允许自签名证书，必须的
manager.securityPolicy.allowInvalidCertificates = YES;
// 是否验证域名的CN字段（不是必须的，但是如果写YES，则必须导入证书）
manager.securityPolicy.validatesDomainName = NO;
 
[manager GET:@"https://kyfw.12306.cn/otn" parameters:nil progress:nil success:^(NSURLSessionDataTask * _Nonnull task, id  _Nullable responseObject) {
 
    NSLog(@"success---%@",[[NSString alloc]initWithData:responseObject encoding:NSUTF8StringEncoding]);
} failure:^(NSURLSessionDataTask * _Nullable task, NSError * _Nonnull error) {
 
    NSLog(@"error---%@",error);
}];

ATS
- iOS9中新增App Transport Security（简称ATS）特性, 让原来请求时候用到的HTTP，全部都转向TLS1.2协议进行传输。
- 这意味着所有的HTTP协议都强制使用了HTTPS协议进行传输。
- 如果我们在iOS9下直接进行HTTP请求是会报错。系统会告诉我们不能直接使用HTTP进行请求，需要在Info.plist中控制ATS的配置。
- "NSAppTransportSecurity"是ATS配置的根节点，配置了节点表示告诉系统要走自定义的ATS设置。
- "NSAllowsAritraryLoads"节点控制是否禁用ATS特性，设置YES就是禁用ATS功能;
- 采用解决方法，修改配置信息。

ATS配置.png

* ATS默认的条件
    *  1)服务器TLS版本至少是1.2版本
    *  2)连接加密只允许几种先进的加密
    *  3)证书必须使用SHA256或者更好的哈希算法进行签名，要么是2048位或者更长的RSA密钥，要么就是256位或更长的ECC密钥。

* AFSecurityPolicy，内部有三个重要的属性，如下：
    * AFSSLPinningMode SSLPinningMode; //该属性标明了AFSecurityPolicy是以何种方式来验证
    * BOOL allowInvalidCertificates; //是否允许不信任的证书通过验证，默认为NO
    * BOOL validatesDomainName; //是否验证主机名，默认为YES

```
"AFSSLPinningMode"枚举类型有三个值，分别是AFSSLPinningModeNone、AFSSLPinningModePublicKey、AFSSLPinningModeCertificate。

"AFSSLPinningModeNone"代表了AFSecurityPolicy不做更严格的验证，"只要是系统信任的证书"就可以通过验证，不过，它受到allowInvalidCertificates和validatesDomainName的影响；

"AFSSLPinningModePublicKey"是通过"比较证书当中公钥(PublicKey)部分"来进行验证，通过SecTrustCopyPublicKey方法获取本地证书和服务器证书，然后进行比较，如果有一个相同，则通过验证，此方式主要适用于自建证书搭建的HTTPS服务器和需要较高安全要求的验证；

"AFSSLPinningModeCertificate"则是直接将本地的证书设置为信任的根证书，然后来进行判断，并且比较本地证书的内容和服务器证书内容是否相同，来进行二次判断，此方式适用于较高安全要求的验证。

如果HTTPS服务器满足ATS默认的条件，而且SSL证书是通过权威的CA机构认证过的，那么什么都不用做。如果上面的条件中有任何一个不成立，那么都只能修改ATS配置。
```

HTTP 和HTTPS的区别
- HTTP:当客户端发送请求,那么服务器会直接返回数据.

http不安全链接.png

* HTTPS：当客户端第一次发送请求的时候，服务器会返回一个包含公钥的受保护空间（也成为证书），当我们发送请求的时候，公钥会将请求加密再发送给服务器，服务器接到请求之后，用自带的私钥进行解密，如果正确再返回数据。这就是 HTTPS 的安全性所在。

https安全链接.png

参考文章，感谢这些作者

下一个学习目标xcode .xcodeproj文件分析