基于对称密码的实体认证:
对称密码,一次传输,单向认证:
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