首页 > 其他分享 >密码协议学习笔记(3):实体认证协议

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

时间:2023-09-08 17:33:38浏览次数:42  
标签:协议 Enc Alice 笔记 认证 AB Bob ID rightarrow

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

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

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$

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

 

 

交错攻击:

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

标签:协议,Enc,Alice,笔记,认证,AB,Bob,ID,rightarrow
From: https://www.cnblogs.com/isakovsky/p/17679717.html

相关文章

  • React项目笔记-环境搭建、路由封装(跳转Navigate、懒加载lazy)、模块化样式引入、状态管
    环境准备nodev16.15.0npm8.5.5AntDesignofReact:https://ant.design/docs/react/introduce-cn一,创建项目npminitvite√Projectname:...vite-project-react√Selectaframework:»React√Selectavariant:»TypeScript然后使用vscode打开项目,由于......
  • RabbitMQ 笔记一
    1.RabbitMQ-如何保证消息不丢失1.生产者确认机制RabbitMQ提供了publisherconfirm机制来避免消息发送到MQ过程中丢失。消息发送到MQ以后,会返回一个结果给发送者,表示消息是否处理成功消息失败之后如何处理:1回调方法即时重发2记录日志3保存到数据库然后定时重发,成功发送后即刻删除......
  • 4. Oracle数据库提示ERROR: ORA-12560: TNS: 协议适配器错误
    造成ORA-12560:TNS:协议适配器错误的问题的原因有三个:有关服务没有启动windows平台个一如下操作:开始—程序—管理工具—服务,打开服务面板,启动TNSlistener服务。注册表问题我这里错误的原因是之后又创建了一个数据库,似乎是将之前ORACLE_SID的值冲掉了,这里改回来即可解决......
  • 华为认证数通考试真题DAY4
    1、链路聚合是企业网络中的常用技术。下列描述中哪些是链路聚合技术的优点?(多选)A.提高可靠性 B.提高安全性 C.增加带宽 D.实现负载分担2、某交换机收到一个带有VLAN标签的数据帧,但发现在其MAC地址表中查询不到该数据帧的目的MAC地址,则交换机对该数据帧的处理行为是()。A.交换......
  • GB国标28181协议下设备接入EasyCVR后,如何调用接口获取RTMP和RTSP视频流
    EasyCVR是一款安防视频监控平台,具有强大的可拓展性、灵活的视频能力和轻快的部署特性。它支持多种主流标准协议,包括国标GB28181、RTSP/Onvif、RTMP等,并能够接入各个厂家的私有协议与SDK,例如海康Ehome、海大宇等设备的SDK。该平台不仅具备传统安防视频监控的功能,如视频监控直播、云......
  • 提升AI视频监控汇聚平台EasyCVR的用户体验:优化多分屏默认播放协议配置
    EasyCVR智能视频监控平台提供高度拓展和开放度,可作为独立的业务平台使用,也能被调用和集成为视频能力层。该平台具备兼容性,支持自由调用和第三方集成。此外,它还支持与TSINGSEE青犀视频平台的AI智能分析网关接入,提供多种智能分析功能如人脸检测、车辆检测等。通过EasyCVR平台,用户可以......
  • TSINGSEE青犀视频集成平台EasyCVR:支持多种视频流协议的强大功能
    EasyCVR国标视频综合管理平台是一款以视频为核心的智慧物联应用平台。它基于分布式、负载均衡等流媒体技术进行开发,提供广泛兼容、安全可靠、开放共享的视频综合服务。该平台具备多种功能,包括视频直播、录像、回放、检索、云存储、告警上报、语音对讲、集群、智能AI分析以及平台级......
  • RTSP流媒体协议视频平台EasyNVR新版存在跨域问题的原因排查
    针对客户反馈的TSINGSEE青犀视频全线产品存在的跨域问题,以前的版本确实遇到过这类问题。目前,我们在服务器端已经进行了允许跨域的配置。然而,仍然有一些客户可能会遇到类似的问题。在本文中,我们将介绍我们采用的解决方法。我们测试了其他浏览器,都是可以获取数据的:我们注意到存在跨域......
  • RTSP协议视频智能安防监控平台EasyNVR的录像播放及下载接口支持返回在线m3u8格式视频
    随着视频智能安防监控系统的普及,安防监控平台在各行各业的项目中得到了广泛应用。未来,AI智能将成为安防监控的主导方向。为了满足行业需求,TSINGSEE青犀视频不断提升现有产品的适应能力,进一步推动智能安防监控系统的发展。目前,EasyNVR作为TSINGSEE青犀视频开发的稳定可靠的智能安防......
  • RTSP协议视频平台EasyNVR接入大华摄像头无法拉取H265格式视频流的解决方案
    EasyNVR作为视频智能安防监控平台,在早期版本中已经集成了EasyPlayer.JS播放器。随着EasyPlayer.JS网页视频播放器的升级,EasyNVR也支持了H.265编码格式的视频播放。此外,EasyNVR还可以集成iframe的视频播放功能,这些功能的存在为EasyNVR智能安防监控平台带来了更多的扩展性。我们将Eas......