密码协议学习笔记(3):实体认证协议

发布时间 2023-09-08 17:30:19作者: Isakovsky

基于对称密码的实体认证:

对称密码,一次传输,单向认证:

Alice与Bob拥有一个共享的对称密钥$k_{A,B}$,某次传输中,Bob要验证对面的通信者是Alice,只需要让Alice发送用该密钥加密的Bob的ID以及时间戳($T_A$)或序列号($SN_A$)(防止重放攻击),如果Bob得到的密文解密后确实是有意义的信息,便可确信对方(有意愿在此时与Bob通信的人)就是$k_{A,B}$的持有者.

$Enc_{AB}(ID_B,[T_A/SN_A])$

问题:时间戳需要同步时钟,序列号需要维护序列号管理器

对称密码,两次传输,单向认证:

Bob选择随机数$N_B$,发送给Alice

Alice使用$k_AB$将$N_B$和Bob的ID加密后发送回去.

$Enc_{AB}(N_B,ID_B)$

对称密码,两次传输,双向认证:

对称密码,一次传输,单向认证应用两次即可.

示意图略.

对称密码,三次传输,双向认证:

对称密码,两次传输,单向认证的扩展.

Alice   Bob
  $N_B \leftarrow$ 选择一次性随机数$N_B$
选择一次性随机数$N_A$ $Enc_{AB}(N_A,N_B,ID_B) \rightarrow$  
    解密,如果能得到自己取的随机数$N_B$,则认为对面确实持有$k_{AB}$(这意味着对面是真实的Alice)
  $Enc_{AB}(N_B,N_A) \leftarrow$  
解密,如果能得到$N_B,N_A$,则认为对面确实持有$k_{AB}$    

基于哈希函数的实体认证:

如果协议中实体身份不需要保密,则可使用哈希函数进行实体认证

假设Alice与Bob共享密钥$k_{AB}$,并约定带密钥的哈希函数$Hash_{AB}(\cdot)$

哈希函数,一次传输,单向认证:

该方法还是使用时间戳$T$或随机数$SN$

$$Alice \qquad [T_A/SN_A],ID_B,Hash_{AB}([T_A/SN_A],ID_B) \rightarrow \qquad Bob$$

哈希函数,两次传输,单向认证:

同对称密码,两次传输,单向认证,基于随机数.

Alice   Bob
  $N_B \leftarrow$ 选择随机数$N_B$
计算$Hash_{AB}(N_B,ID_B)$ $Hash_{AB}(N_B,ID_B) \rightarrow$  
    也计算$Hash_{AB}(N_B,ID_B)$并验证与发来的消息是否一致

哈希函数,两次传输,双向认证:

同样是哈希函数,一次传输,单向认证应用两次.

示意图略.

哈希函数,三次传输,双向认证:

Alice   Bob
  $N_B \leftarrow$ 选择一次性随机数$N_B$
选择一次性随机数$N_A$ $Hash_{AB}(N_A,N_B,ID_B) \rightarrow$  
    计算$Hash_{AB}(N_A,N_B,ID_B)$并验证发来的消息是否一致,如果一致,则认为对面确实持有$k_{AB}$(这意味着对面是真实的Alice)
  $Hash_{AB}(N_B,N_A) \leftarrow$  
同样计算$Hash_{AB}(N_B,N_A)$并验证发来的消息是否一致    

基于公钥密码的实体认证:

如果通信双方没有共享密钥,那么对称密码或哈希函数的实体认证便无法实现,此时可以应用非对称密码来解决这个问题.

(回顾:$Sign_{(\cdot)}(\cdot)$签名算法,需要持有私钥$sk_{(\cdot)}$才可生成签名,但只需公钥$pk_{\cdot}$即可验证某签名是否由某明文生成,

Torrent:可简写为T,可信中心,会为自己认可的用户颁发证书$Cert_{(\cdot)}(ID_{(\cdot)},pk_{(\cdot)},Sign_{T}(ID_{(\cdot)},pk_{(\cdot)}))$,并发布自己的公钥$pk_T$供其他人验证证书有效性).

公钥密码,一次传输,单向认证:

$$Alice \rightarrow \qquad \begin{gather*} [T_A/SN_A] \\ ID_B \\ Sign_{A}([T_A/SN_A],ID_B) \\ Cert_A=(ID_A,pk_A,Sign_T(ID_A,pk_A))  \end{gather*} \qquad \rightarrow  Bob$$

这样,Bob就认证了对面那个有意愿与自己通信的人就是$sk_A$的持有者.

还是一样的问题,需要时间戳和序列号.

(有风险的)公钥密码,两次传输,单向认证:

Alice   Bob
  $N_B \leftarrow$ 选择随机数$N_B$
对$N_B$签名

$Sign_{A}(N_B,ID_B)$

$Cert_A=(ID_A,pk_A,Sign_T(ID_A,pk_A)) \rightarrow$

 
   

使用$pk_T$验证证书有效性,然后使用$pk_A$验证签名有效性.

若验证成功,则确认了对面的人是私钥$sk_A$的持有者.

该协议的风险在Alice身上,$N_B$是由Bob给出的,Bob完全可以制造一些带后门的$N_B$让Alice去签名.

比如令$N_B=h(\text{将A名下的所有财产转至B名下})$,其中$h(\cdot)$是某个哈希函数,这样Bob就得到了Alice对此信息的签名.

(改进的)公钥密码,两次传输,单向认证:

改进的方案是允许Alice在待签名的数据中加入自己可以控制的信息.

Alice   Bob
  $N_B \leftarrow$ 选择随机数$N_B$
也选取一个随机数$N_A$,然后对$N_A,N_B,ID_B$一起签名

$N_A,Sign_{A}(N_A,N_B,ID_B)$

$Cert_A=(ID_A,pk_A,Sign_T(ID_A,pk_A)) \rightarrow$

 
    使用$pk_T$验证证书有效性,然后使用$pk_A$验证签名有效性

公钥密码,两次传输,双向认证:

公钥密码,一次传输,单向认证应用两次.

示意图略.

(有风险的)公钥密码,三次传输,双向认证:

将基于对称密码/哈希函数的三次传输,双向认证的思路机械地照搬到公钥密码上是不安全的.

(博主注:因为没有对称密钥的存在,认证的发起人只需要提供一个随机数即可发起认证,这个行为是没有门槛的.)

(博主注:为了更直观地理解后面叙述的中间人攻击过程,将协议中的三次传输分别用红色,绿色,蓝色标注)

Alice   Bob
  $N_B \leftarrow$ 选择一次性随机数$N_B$
选择一次性随机数$N_A$

$N_A,Sign_A(N_A,N_B,ID_B)$

$Cert_A=(ID_A,pk_A,Sign_T(ID_A,pk_A)) \rightarrow$

 
    用$pk_T$验证证书,用$pk_A$验证签名,确认有效性.
 

$N_B',Sign_B(N_B',N_A,ID_A)$

$Cert_B=(ID_B,pk_B,Sign_T(ID_B,pk_B))$

$\leftarrow$

再选择一个一次性随机数$N_B'$
用$pk_T$验证证书,用$pk_B$验证签名,确认有效性.    

对于此协议,存在着中间人攻击的风险:

Alice   Eve   Bob
  $N_E \leftarrow$ 伪造一次性随机数$N_E$,谎称是Bob发送的    
选择一次性随机数$N_A$并生成签名

$N_A,N_E,Sign_A(N_A,N_E,ID_B)$

$Cert_A=(ID_A,pk_A,Sign_T(ID_A,pk_A))$

$\rightarrow$

     
    冒充$Alice$将$N_A$发送给Bob
$N_A \rightarrow$
 
     

$N_B,N_A,Sign_B(N_B,N_A,ID_A)$

$Cert_B=(ID_B,pk_B,Sign_T(ID_B,pk_B))$

$\leftarrow$

选择一次性随机数$N_B$并生成签名
 

$N_B,N_A,Sign_B(N_B,N_A,ID_A)$

$Cert_B=(ID_B,pk_B,Sign_T(ID_B,pk_B))$

$\leftarrow$

Eve从Bob处套取了签名,直接将签名转发即可.

 

 
Alice以为$N_B$是对方生成的三号随机数,验证的结果自然是签名有效.

 

 

 

Bob可能在等待回信,或者因为本地时钟超时终止协议.

注意,在此攻击过程中,Alice和Bob都以为是对方先发起的认证.

(博主注:有点类似于间谍(Eve)遇到哨兵(Alice)时,抢先要求对方报出口令,然后又用套取的口令在别的哨兵(Bob)处套取回令)

这是因为,本质上该协议就是公钥密码,两次传输,单向认证协议使用不同的随机数独立地重复了两次.为解决这个问题,只需要让这两次协议的调用不再独立即可.

(改进的)公钥密码,三次传输,双向认证:

Alice   Bob
  $N_B \leftarrow$ 选择一次性随机数$N_B$
选择一次性随机数$N_A$

$N_A,Sign_A(N_A,N_B,ID_B)$

$Cert_A=(ID_A,pk_A,Sign_T(ID_A,pk_A)) \rightarrow$

 
    用$pk_T$验证证书,用$pk_A$验证签名,确认有效性.
 

$Sign_B(N_B,N_A,ID_A)$

$Cert_B=(ID_B,pk_B,Sign_T(ID_B,pk_B))$

$\leftarrow$

不再选取新的随机数
用$pk_T$验证证书,用$pk_B$验证签名,确认有效性.    

基于可信第三方(TTP)的实体认证:

(回顾:TTP,Trusted,Third Party,可信第三方,可信第三方总是提供合法输入,即,它不会成为主动攻击者的"马甲")

TTP安全地保存了它和所有实体的共享密钥,比如,TTP与Alice之间的共享密钥可记为$k_{AT}$,与$Bob$之间的共享密钥可记为$k_{BT}$

(有风险的)Needham-Schroeder协议:

该协议能同时达到实体认证和协商密钥的效果.

TTP   Alice   Bob
  $N_A,ID_A,ID_B \leftarrow$ 生成随机数$N_A$    
随机生成$k_{AB}$作为Alice和Bob的会话密钥

$Enc_{AT}(N_A,ID_B,k_{AB},Enc_{BT}(k_{AB},ID_A))$

$\rightarrow$

     
 

 

解密,检查$N_A$是自己发出的随机数,Bob是与自己通信的主体

若是,则保存$k_{AB}$并转发$Enc_{BT}(k_{AB},ID_A))$

$Enc_{BT}(k_{AB},ID_A)) \rightarrow$  
 

 

 

$Enc_{AB}(N')\leftarrow$

用$k_{BT}$解密并验证密文中的ID是否与发来信息的Alice相符合.

如果是,则生成随机数$N'$用于确认Alice确实掌握了密钥$k_{AB}$

 

 

计算$Enc_{AB}(N'-1)$并发回

$Enc_{AB}(N'-1) \rightarrow$

 

对Needham-Schroeder协议的攻击:

由于该协议中,Bob未与TTP直接通信,因此它无法查证自己收到的消息是Alice直接转发来的,此时,如果存在攻击者记录了之前的会话$Enc_{BT}(k_{AB}',ID_A)$并获得了旧的密钥$k_AB'$,则它可以以重放通信的方式进行中间人攻击.

TTP   Alice   Eve   Bob
  $N_A,ID_A,ID_B \leftarrow$ 生成随机数$N_A$        
随机生成$k_{AB}$作为Alice和Bob的会话密钥

$Enc_{AT}(N_A,ID_B,k_{AB},Enc_{BT}(k_{AB},ID_A))$

$\rightarrow$

         
 

 

解密,检查$N_A$是自己发出的随机数,Bob是与自己通信的主体

若是,则保存$k_{AB}$并转发$Enc_{BT}(k_{AB},ID_A))$

$Enc_{BT}(k_{AB},ID_A)) \rightarrow$      
        将信息篡改为保存下来的旧会话信息 $Enc_{BT}(K_{AB}',ID_A) \rightarrow$  
          $Enc_{AB'}(N')\leftarrow$

用$k_{BT}$解密并验证密文中的ID是否与发来信息的Alice相符合.

如果是,则生成随机数$N'$

       

计算$Enc_{AB'}(N'-1)$并发回

$Enc_{AB'}(N'-1) \rightarrow$

 

 

这样,Eve就可以截获Bob发给Alice的信息.

(使用时间戳机制改进的)Needham-Schroeder协议

在通信中加入时间戳$T$,防止利用旧会话信息的重放攻击.

TTP   Alice   Bob
  $ID_A,ID_B \leftarrow$      
随机生成$k_{AB}$作为Alice和Bob的会话密钥

$Enc_{AT}(ID_B,k_{AB},Enc_{BT}(k_{AB},ID_A,T))$

$\rightarrow$

     
 

 

解密,检查Bob是与自己通信的主体

若是,则保存$k_{AB}$并转发$Enc_{BT}(k_{AB},ID_A,T))$

$Enc_{BT}(k_{AB},ID_A,T)) \rightarrow$  
 

 

 

 

用$k_{BT}$解密并验证密文中的ID是否与发来信息的Alice相符合.

同时,还要根据网络延迟判断时间戳$T$是否有效.

如果是,则认可Alice身份和会话密钥$k_{AB}$

注意,因为有了时间戳机制,无需再使用随机数$N'$重复验证.

基于随机数的,双方都与TTP通信的,实体认证协议:

使用时间戳涉及时钟同步问题,因此可令Bob也向TTP进行认证,以保证有效性.

  TTP  
     
Alice

$(ID_A,ID_B)$

代表发起实体认证的意向

$\rightarrow$

Bob

 

  TTP  
     
Alice:生成随机数$N_A$   Bob:生成随机数$N_B$

 

  TTP  
$ID_A,ID_B,N_A \nearrow$   $\nwarrow ID_B,ID_A,N_B $
Alice   Bob

 

  TTP:生成$k_{AB}$并发送  
$Enc_{AT}(ID_A,ID_B,N_A,k_AB) \swarrow$   $\searrow Enc_{BT}(ID_B,ID_A,N_B,k_{AB})$
Alice   Bob

 

  TTP  
     
Alice:生成随机数$N'$ $Enc_{AB}(N')\rightarrow$ Bob

 

  TTP  
     
Alice $Enc_{AB}(N'-1)\leftarrow$ Bob:计算并回复

五次传输双向认证:

同样是一个能够同时完成实体认证和密钥交换的协议.

Alice   Bob   TTP
生成随机数$N_A$ $N_A \rightarrow$      
    生成随机数$N_B$

$N_A,N_B,ID_A$

$\rightarrow$

 
     

$Enc_{BT}(N_B,k_{AB},ID_A)$

$Enc_{AT}(N_A,k_{AB},ID_B)$

$\leftarrow$

随机选取$k_{AB}$作为会话密钥
 

$Enc_{AT}(N_A,k_{AB},ID_B)$

$Enc_{AB}(N',N_A)$

$\leftarrow$

解密并验证$Enc_{BT}(N_B,k_{AB},ID_A)$

再选取一个随机数$N'$

   

解密并验证$Enc_{AT}(N_A,k_{AB},ID_B)$

计算并发送$Enc_{AB}(N_A,N')$证明自己掌握了$k_{AB}$

$Enc_{AB}(N_A,N')$

$\rightarrow$

 

   

 

 

解密并验证$Enc_{AB}(N_A,N')$

   

基于口令(password)的实体认证:

一般用于计算机主机(Host)$H$验证用户(User)$U$身份的情况.

直接基于口令的认证协议:

Host以$(ID_U,pw_U)$的形式保存用户名与口令.

当User要登录主机时:

$User \qquad \rightarrow ID_U \rightarrow \qquad Host$

$User \qquad \leftarrow \text{请输入口令} \leftarrow \qquad Host$

$User \qquad \rightarrow pw_U \rightarrow \qquad Host$

然后Host检查$(ID_U,pw_U)$是否保存在文档中,若是,则允许User登录.

问题:

仅适用于本地登录或专线连接.

如果User和Host在可窃听信道两端,则会导致窃听与重放攻击.

明文保存的$(ID_U,pw_U)$可能被非法读取.

单向函数的口令认证协议:

主机中只存储口令的单向函数(one way function)$OWF(\cdot)$值.$(ID_U,OWF(pw_U))$

问题:

弱口令会导致攻击者穷举弱口令计算单向函数值,并与截获的信息进行比较的字典式攻击.

单向函数+加盐的口令认证协议:

盐(salt)指一段随机数,用于增加口令的随机性,主机在计算存储OWF时加入盐一起计算,即$OWF(pw_U,salt)$.

主机中只存储$(ID_U,salt,OWF(pw_U,salt))$

问题:

仍会导致攻击者窃取主机中的salt后,进行基于salt的字典式攻击,但这样攻击者的花销就会大得多.

基于哈希链的一次性口令认证:SKey

定义$Hash^n(\cdot)=Hash(\cdots(Hash(\cdot))\cdots)$,哈希函数运行$n$次.

主机中保存$(ID_U,c,Hash^{c}(pw_U))$

$User \qquad \rightarrow ID_U \rightarrow \qquad Host$

$User \qquad \leftarrow c,\text{请输入口令} \leftarrow \qquad Host$

$User \qquad \rightarrow Hash^{c-1}(pw_U) \rightarrow \qquad Host$

Host计算$Hash(Hash^{c-1}(pw_U))$是否与文档中的$Hash^{c}(pw_U)$匹配,若匹配则允许User登录,并将口令更新为$(ID_U,c-1,Hash^{c-1}(pw_U))$,下次User需要使用$Hash^{c-2}(pw_U)$作为口令登录.

当$c$最终减为$1$时,用户和主机需要重新初始化设置口令.

对SKey的中间人攻击:

若User与Host之间的信道可篡改,User又没有记录自己密钥$pw_U$的计数器$c$,则攻击者可以通过修改计数器值的方式进行中间人攻击.

User   Eve   Host
  $ID_U,\rightarrow$   $ID_U,\rightarrow$  
 

$c-1$,"请输入口令"

$\leftarrow$

 

$c$,"请输入口令"

$\leftarrow$

 
 

$Hash^{c-2}(pw_U)$

$\rightarrow$

计算$Hash^{c-1}(pw_U)=Hash(Hash^{c-2}(pw_U))$

$Hash^{c-1}(pw_U)$

$\rightarrow$

将计数器更新为$c-1$,并建立连接.

Eve既可以直接截获本次连接发送的信息,也可以使用$Hash^{c-2}(pw_U)$下次冒充User登录.

(博主注:如果协议中Host与User协商了签名算法,登录时要求User提供一个随机数$N$,而Host返回$c$时一起返回$Sign(N,c)$,则可避免此种攻击)

加密的密钥交换协议(Encrypted Key Exchange,EKE):

在EKE协议中,用户$U$和主机$H$共享口令$pw_U$,另外还需约定一种对称加密体制$SEnc(\cdot)$和公钥加密体制$AEnc(\cdot)$

该协议也能同时做到实体认证与密钥协商.协议执行结束后用户和主机将完成双向实体认证,并得到共享密钥.

User   Host
生成一对密钥对$(pk,sk)$

$ID_U, SEnc_{pw_U}(pk)$

$\rightarrow$

(博主注:直接将口令作为密钥似乎不太可行,需要将口令哈希一下才能作为密钥使用)

 
 

$SEnc_{pw_U}(AEnc_{pk}(k))$

$\leftarrow$

解密$SEnc_{pw_U}(pk)$得到$pk$

随机生成一个密钥$k$

用$pk$加密$k$得到$AEnc_{pk}(k)$

再将$AEnc_{pk}(k)$用$pw_U$加密

用$pw_U$解密$SEnc_{pw_U}(AEnc_{pk}(k))$得到$AEnc_{pk}(k)$

再用$sk$解密$AEnc_{pk}(k)$得到$k$

生成一个随机数$N_U$并用$k$加密得到$SEnc_{k}(N_U)$

$SEnc_{k}(N_U)$

$\rightarrow$

 

 

$SEnc_k(N_U,N_E)$

$\leftarrow$

解密得到$N_U$

再生成一个随机数$N_E$

计算$SEnc_k(N_U,N_E)$

解密得到$N_E$

计算$SEnc_k(N_E)$

$SEnc_k(N_E)$

$\leftarrow$

解密得到$N_E$后则允许登录,并协商了会话密钥$k$

对实体认证协议的攻击:

消息重放攻击:

在可窃听信道上窃听到消息,在之后的某个时间重新发送给原接收者,以伪装成原发送者.

解决方案:

时间戳,计数器,随机数.

中间人攻击:

修改计数器的值.

解决方案:

使用签名等方式防止计数器的值被篡改.

平行会话攻击:

该类攻击指在攻击者操控下,被攻击的两个或多个协议并发执行,从可以协议甲中得到的信息作为对协议乙的应答.

(即,某小孩和两个象棋大师下棋,用一人的招数去对付另外一人.)

Woo-Lam协议:

介绍该协议作为用于描述平行会话攻击的"靶子".

该协议的目的是为了让Bob对Alice产生单方向的认证.Alice与$TTP$共享密钥$k_{AT}$,Bob与TTP共享密钥$k_{BT}$,约定的对称加密算法$Enc_{(\cdot)}(\cdot)$

Alice   Bob   TTP
 

$ID_A$

$\rightarrow$

     
 

$N_B$

$\leftarrow$

生成随机数$N_B$    
计算$Enc_{AT}(N_B)$

$Enc_{AT}(N_B)$

$\rightarrow$

再加密一层

$Enc_{BT}(ID_A,Enc_{AT}(N_B))$

$Enc_{BT}(Enc_{AT}(N_B))$

$\rightarrow$

 
     

$Enc_{BT}(N_B)$

$\leftarrow$

解密得到$N_B$,然后加密为$Enc_{BT}(N_B)$发送回去
    检查是否能解密出自己生成的随机数$N_B$

 

 

对Woo-Lam协议的平行会话攻击:

如果Bob与多个实体同时会话,则会遭到如下的攻击:

假设Eve也是系统中的一个实体,它与TTP共享密钥$k_{ET}$

红色表示"Alice"与Bob之间运行的协议,蓝色表示Eve与Bob运行的协议

    TTP    
         
"Alice"(实际上是Eve假冒的)

$ID_A$

$\rightarrow$

Bob

$ID_E$

$\leftarrow$

Eve

 

    TTP    
         
"Alice"

$N_B$

$\leftarrow$

Bob

$N_B'$

$\rightarrow$

Eve

 

    TTP    
         
"Alice"

$Enc_{ET}(N_B)$

$\rightarrow$

Bob

$Enc_{ET}(N_B)$

$\leftarrow$

Eve

 

    TTP    
   

$\uparrow$

$Enc_{BT}(ID_A,Enc_{ET}(N_B))$

$Enc_{BT}(ID_E,Enc_{ET}(N_B))$

   
"Alice"

 

Bob

 

Eve

TTP用$k_{BT}$解密$Enc_{BT}(ID_A,Enc_{ET}(N_B))$得到$ID_A,Enc_{ET}(N_B)$,用$k_{AT}$解密$Enc_{ET}(N_B)$,得到的是乱文$R$

TTP用$k_{BT}$解密$Enc_{BT}(ID_E,Enc_{ET}(N_B))$得到$ID_E,Enc_{ET}(N_B)$,用$k_{ET}$解密$Enc_{ET}(N_B)$,得到的是$N_B$

    TTP    
   

$\downarrow$

$Enc_{BT}(R)$

$Enc_{BT}(N_B)$

   
"Alice"

 

Bob

 

Eve

尽管在示意图中,使用不同的颜色标注了不同的会话,然而由于这些会话都是同时发生的,且消息上没有标签,因此Bob会认为$Enc_{BT}(N_B)$来自与"Alice"的会话从而认可"Alice"的身份,认为$Enc_{BT}(R)$来自于Eve的会话从而拒绝认可Eve的身份.

改进的Woo-Lam协议:

为防御平行会话攻击,对Woo-Lam协议做出如下改进:TTP返回消息时,将ID也加密进密文里

Alice   Bob   TTP
 

$ID_A$

$\rightarrow$

     
 

$N_B$

$\leftarrow$

生成随机数$N_B$    
计算$Enc_{AT}(N_B)$

$Enc_{AT}(N_B)$

$\rightarrow$

再加密一层

$Enc_{BT}(ID_A,Enc_{AT}(N_B))$

$Enc_{BT}(Enc_{AT}(N_B))$

$\rightarrow$

 
     

$Enc_{BT}(ID_A,N_B)$

$\leftarrow$

解密得到$N_B$,然后和Alice的ID一起加密为$Enc_{BT}(ID_A,N_B)$发送回去
    检查是否能解密出自己生成的随机数$N_B$

 

 

然而,此协议仍是不安全的.

反射攻击:

当某实体发送信息时被攻击者截获,攻击者将原消息(或者稍作处理后的消息)返回给原发送者,然而原发送者不会意识到这是自己产生的.

(达尔巴用蒙古话向杨过问话,杨过虽然不懂蒙古话,但是原样复述了一遍,就把达尔巴这个傻子忽悠的团团转)

对改进的Woo-Lam协议的反射攻击:

(该过程中,恶意攻击者Eve既伪装为Alice,又伪装为TTP)

(全 · 员 · 恶 · 人)

Eve伪装的"Alice"   Bob   Eve伪装的"TTP"
  $ID_A \rightarrow$      
  $\leftarrow N_B$ 生成随机数$N_B$    
直接将随机数作为它本该计算得出的密文返回 $\rightarrow N_B$      
    计算$Enc_{BT}(ID_A,N_B)$

$Enc_{BT}(ID_A,N_B)$

$\rightarrow$

 
     

$Enc_{BT}(ID_A,N_B)$

$\leftarrow$

直接将密文返回
   

解密,得到$ID_A,N_B$

于是认为本次协议是有效的.

 

 

交错攻击:

类似于平行会话攻击,但被攻击协议是交错而非同时执行.