哈工大计算机网络课程网络安全基本原理之：身份认证

在日常生活中，在很多场景下我们都需要对当前身份做认证，比如使用密码、人脸识别、指纹识别等，这些都是身份认证的常用方式。本节介绍的身份认证，是在计算机网络安全中的身份认证，从端到端之间通信的角度来看，通信双方的两个实体如何来确认另一方通信实体的真实身份。

身份认证（Authentication）

在介绍身份认证时，我们以一个网络安全的拟人模型，模拟一个场景来讨论一下身份认证的基本原理。为此，假设：

目标：Bob希望Alice“证明”她的身份。（是不是真的Alice还是其他假扮的）

为了讨论身份认证的一般性原理和过程，这里我们假设去设计几个身份认证的协议，来形象化地区分不同协议间在认证过程中的区别，并反映身份认证协议的演进。这里假设的协议我们称为AP。

AP 1.0

这里我们首先观察一个最简单的场景，在这个场景下，Alice为了向Bob证实自己的身份，直接向Bob发送一段信息：“I am Alice”

作为这样简单的认证方式，显然我们很容易想出可能的认证失效场景：

在网络中任何另一方Trudy都可以简单的声明自己是“Alice“，因为在网络中，Bob实际上是看不到Alice的。因此，这种简单直接声明的方式是非常不可靠的，要进行身份认证，还需要一些其他的信息。

AP2.0

为此，我们对上述协议做个改进：

AP2.0：Alice在IP分组中声明“I am Alice“，IP分组包含Alice的源IP地址。

然而在现在的Internet网络中，上述方式仍然是非常不可靠的，因为实际上IP地址也可以有很多方式来伪装和篡改的。

Trudy可以构造一个IP分组，来伪装成Alice的IP地址，向Bob发送IP分组。

为此，再进一步升级协议。

AP3.0

在AP3.0的改进中，我们借助于日常生活中分辨对方身份的常用方式之一，口令。比如在潜伏者或者间谍对接时，都会有一个密令，两个人分别有密令的上句和下句。如果碰头时，两句话对上了，则能够成功辨别对方身份，碰头成功。

因此在AP3.0中，我们也加入口令这个概念：

AP3.0：Alice声明“I am Alice"的同时，发送她的秘密口令进行“证明”

在现在网络使用中，我们实际上也会经常用到以上场景，比如登陆网站时需要输入用户名和密码等。

但这种方式，在一些更严苛的场景来说，事实上仍然存在风险。其中最典型的一种失效场景就是嗅探。

比如说Trudy可以利用嗅探工具，在Alice或Bob端的网络进行嗅探，嗅探Alice给Bob发送的分组。通过对这个分组的分析，如果这个口令包含在分组中，就可以把口令提取出来。之后，Trudy就可以假扮成Alice向Bob发送带有口令的IP分组。

从更简单的结果来说，就比如账号被盗这样的结果，就是一种上述口令身份认证失效的场景。

为了避免嗅探，通常可以不在传输的IP分组中使用明文的口令，而是把该口令进行加密再传输（Alice与Bob之间共享对称密钥，然后按照某个加密算法进行加密）。因此，基于上面的思想，我们对AP3.0协议再改进一下。

AP3.1

协议AP3.1：Alice声明“I am Alice“的同时，发送她的加密的秘密口令进行“证明”。

在AP3.1中，Alice向Bob发送的IP分组中，就包含了加密的口令，Bob收到后，利用对称密钥进行解密后进行身份认证。那么这种方式是否就是绝对安全的了呢？

实际上，这种方式也无法绝对安全，尤其在网络中存在很多攻击，其中一种就是所谓的回放攻击（playback attack），即第三方Trudy可以使用工具截获Alice与Bob间通信的分组。虽然Trudy无法对加密的口令进行解密，但是它可以把加密的口令原封不动记录下来。之后，它只需要把这个加密的口令放到分组中发送给Bob即可，相当于把这个截获的分组“回放”给Bob，此时Bob端也会认为这个分组是Alice发送的。

因此，即使AP3.1中，对口令进行了加密，也仍然存在被攻击的漏洞和风险。因此，我们还需要进一步地进行改进。而改进的方向来说，在协议3.1中之所以会被攻克，是因为没有办法预防“回放攻击”，为此在改进的协议中，就是要找到一种机制能够避免“回放攻击”。

AP4.0

目标：避免“回放攻击”

解决方案：即使第三方记录了某次传输分组中的加密口令，但在将来再次使用时是无效的。换句话说，口令只在当前传输分组中有效，下次同样的口令就无效了。

为此在协议AP4.0中引入这样 “一次性随机数（nonce）“概念：一个生命期内只用一次的数R。

协议AP4.0：为了证明是“真实的”Alice，Bob向Alice发送一个随机数R，Alice必须返回R，并利用共享密钥进行加密。过程如下所示：

• Alice向Bob声明自己的身份，发送“I am Alice“。
• 但是Bob仅以此无法判断Alice身份，在AP4.0协议中，Bob会返回一个不重复的随机数R
• Alice在接收到返回的随机数R后，为了证明她是真实的Alice，会利用Alice与Bob间共享的对称密钥，对随机数R进行加密，然后返回给Bob
• Bob接收到这个加密随机数R后，会利用共享的对称密钥进行解密，解密后与之前发送给Alice的明文随机数R进行比对，如果匹配成功，则Bob可以确认Alice的真实身份。

上述流程的关键在于，只有Alice和Bob之间才拥有一对共享的对称密钥，并以此来对随机数R进行加解密。

但这也正是AP4.0协议仍然存在的不足，其实也是对称加密方法的不足。在对称加密方法中，两端之间需要一个共享密钥，而这个共享密钥在网络传输中是可能被截获的，一旦这个密钥被截获，那剩下的通信过程一定都是不再安全的。

为此，更进一步的自然会想到，在对称加密的方式上进行改进，使用非对称加密方式，利用公钥技术来进行加密。

AP 5.0

协议AP5.0：利用一次性随机数以及公钥加密技术。

使用公钥加密技术后，认证过程变成以下过程：

• Alice向Bob发送身份认证：“I am Alice“
• Bob为了证实Alice的真实身份，且不是“回放攻击”的，会向Alice返回一个随机数R
• Alice会利用自己的私钥对收到的随机数R进行加密，将密文发送给Bob
• Bob接收到后，需要再次向Alice发送请求，申请获取Alice的公钥
• Alice将公钥返回给Bob
• Bob根据该公钥，对加密的随机数R进行解密，再与之前的明文随机数R进行比对，如果匹配，则能够证实Alice的身份。

上述方式，私钥是唯一保存在Alice身上的，其他第三方是没有该私钥的，因而也就无法构成出相同的使用该私钥加密的密文。而私钥是不会在网络中进行传输的，减轻了被截获的风险。

但但是…，是的，即使如此，协议AP5.0还是仍然存在风险（悲伤…），这个风险漏洞就是中间人攻击（man in the middle attach）。

什么是中间人攻击问题呢？

假设Alice与Bob之间进行通信，作为第三方入侵者Trudy介入两者通信之间，对于Alice她扮演Bob，对于Bob她扮演Alice。所有Alice和Bob之间的通信，全部被Trudy进行截获，使得Alice和Bob分别都以为他们实际上是与对方在通信。

中间人攻击这整个过程可以如上图所示，过程大致如下：

• Alice在向Bob声明自己身份时，发送“I am Alice“，然后被中间人Trudy截获了，Trudy把这个信息转发给Bob。

• 按照协议AP5.0，Bob会返回一个随机数R给Alice，同样被Trudy截获。

• 此时，Trudy会用它自己的私钥对随机数R加密后，返回给Bob。同时，Trudy又会把R发送给Alice。

• Alice会用自己的私钥加密后，返回给Bob，同样被Trudy截获。

• 由于Bob收到的加密随机数R是由Trudy返回的，Trudy可能通过修改包含R的IP分组的源IP地址等方式，让Bob把Trudy的IP地址当成了Alice，因为Bob会向Trudy请求公钥来解密。

• 作为Trudy，会把她自己的公钥返回给Bob。同时，由于上面Alice用自己的私钥加密后被Trudy截获，所以Trudy也会向Alice所要公钥。

• Alice把公钥返回给Trudy。

• 由于Bob利用Trudy返回的公钥解密后，与之前发送的明文随机数R比对后发现匹配，则通过认证。此时，Bob就完全认为Trudy就是Alice了。

• 此后，如果Bob和Alice之间通信的话，Bob就会用之前Trudy的公钥（Bob以为是Alice的公钥，实际上是Trudy的公钥）加密数据后发送。Bob以为发送给Alice，实际上发送给了Trudy。

• Trudy用自己的私钥解密后获取了明文，再用之前Alice返回的公钥进行加密，再返回给Alice。

这一过程我们看到，Bob和Alice之间的所有通信信息，都已经被一个中间入侵者Trudy截获了，而且Bob和Alice还无法感知，仍然以为是与对方在安全通信。因此，事实上这种中间人攻击也确实存在着很难被检测的问题。