想象以下场景

• Alice发的内容有可能是被篡改的，或者有人伪装成Alice发消息，或者就是Alice发的，但她可以否认
• 问题来了：Bob如何确定这段消息的真实性？如何识别篡改、伪装、否认？

解决方案?

引入了这篇文章的主角 - 数字签名。

数字签名

数字签名是为了解决，消息是否被篡改

• 在数字签名技术中，有以下2种行为

  • 生成签名
    • 由消息的发送者完成，通过“签名密钥”生成
  • 验证签名
    • 由消息的接收者完成，通过“验证密钥”验证

• 思考

  • 如何能保证这个签名是消息发送者自己签的？

• 答案

  • 用消息发送者的私钥进行签名

数字签名和公钥密码

• 数字签名，其实就是将公钥密码反过来使用

  

数字签名的过程

这种数字签名方式有一个弊端， 消息体积变大一倍，因为加密操作跟单项散列函数不一样，加密后消息体积跟原始消息体积大小相当。

Alice 向 Bob发送一个消息，则实际发送了两倍于本身消息的体积。

如何改进呢？

数字签名的过程-改进

改进就是，使用单向散列函数

Alice在制作签名 ( 也就是用自己的私钥加密消息时)，不加密消息本身，而是加密消息经过单向散列函数计算后的散列值。

Bob在验证签名时，用Alice的公钥解密收到的签名，就会解密出消息的散列值， 这时我们拿到Alice发送的消息，进行单向散列函数计算，如果两者一致， 则签名验证成功。

数字签名-疑惑

• 思考一下

  • 如果有人篡改了文件内容或者签名内容，会是什么结果？
  • 结果是：签名验证失败，证明内容会篡改

• 数字签名不能保证机密性？

  • 数字签名的作用不是为了保证机密性，仅仅是为了能够识别内容有没有被篡改(也就是是不是消息发送者本人发送的)

• 数字签名的作用

  • 确认消息的完整性
  • 识别消息是否被篡改
  • 防止消息发送人否认

数字签名无法解决的问题

• 要正确使用签名，前提是

  • 用于验证签名的公钥必须属于真正的发送者

• 如果遭遇了中间人攻击，那么

  • 公钥将是伪造的
  • 数字签名将失效

• 所以在验证签名之前，首先得先验证公钥的合法性

  • 如何验证公钥的合法性？
  • 证书

中间人攻击

简介：

中间人攻击（Man-in-the-Middle Attack, MITM）是一种由来已久的网络入侵手段，并且当今仍然有着广泛的发展空间，如SMB会话劫持、DNS欺骗等攻击都是典型的MITM攻击。简而言之，所谓的MITM攻击就是通过拦截正常的网络通信数据，并进行数据篡改和嗅探，而通信的双方却毫不知情。

随着计算机通信网技术的不断发展，MITM攻击也越来越多样化。最初，攻击者只要将网卡设为混杂模式，伪装成代理服务器监听特定的流量就可以实现攻击，这是因为很多通信协议都是以明文来进行传输的，如HTTP、FTP、Telnet等。后来，随着交换机代替集线器，简单的嗅探攻击已经不能成功，必须先进行ARP欺骗才行。如今，越来越多的服务商（网上银行，邮箱登陆）开始采用加密通信，SSL(Secure Sockets Layer 安全套接层)是一种广泛使用的技术，HTTPS、FTPS等都是建立在其基础上的。 [1]

接下来，我们来学习，**证书(Certificate)**相关知识，学习完证书相关， 就可以正式把iOS签名机制串起来学习啦～