哈工大计算机网络课程网络安全基本原理之:身份认证
在日常生活中,在很多场景下我们都需要对当前身份做认证,比如使用密码、人脸识别、指纹识别等,这些都是身份认证的常用方式。本节介绍的身份认证,是在计算机网络安全中的身份认证,从端到端之间通信的角度来看,通信双方的两个实体如何来确认另一方通信实体的真实身份。
身份认证(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还无法感知,仍然以为是与对方在安全通信。因此,事实上这种中间人攻击也确实存在着很难被检测的问题。