WO2010066186A1 - 一种三步握手协议方法 - Google Patents

一种三步握手协议方法 Download PDF

Info

Publication number
WO2010066186A1
WO2010066186A1 PCT/CN2009/075381 CN2009075381W WO2010066186A1 WO 2010066186 A1 WO2010066186 A1 WO 2010066186A1 CN 2009075381 W CN2009075381 W CN 2009075381W WO 2010066186 A1 WO2010066186 A1 WO 2010066186A1
Authority
WO
WIPO (PCT)
Prior art keywords
message
ptk
nonce
initiator
mac
Prior art date
Application number
PCT/CN2009/075381
Other languages
English (en)
French (fr)
Inventor
铁满霞
曹军
胡亚楠
肖跃雷
黄振海
Original Assignee
西安西电捷通无线网络通信有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 西安西电捷通无线网络通信有限公司 filed Critical 西安西电捷通无线网络通信有限公司
Priority to JP2011539880A priority Critical patent/JP5313360B2/ja
Priority to EP09831463.6A priority patent/EP2375627B1/en
Publication of WO2010066186A1 publication Critical patent/WO2010066186A1/zh

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0838—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these
    • H04L9/0841—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these involving Diffie-Hellman or related key agreement protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
    • H04L9/0869—Generation of secret information including derivation or calculation of cryptographic keys or passwords involving random numbers or seeds
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0891—Revocation or update of secret information, e.g. encryption key update or rekeying
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3242—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving keyed hash functions, e.g. message authentication codes [MACs], CBC-MAC or HMAC
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3271—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using challenge-response
    • H04L9/3273—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using challenge-response for mutual authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/80—Wireless

Definitions

  • the present invention relates to the field of network security technologies, and in particular, to a three-step handshake protocol method.
  • Ultra-wideband UWB Ultra Wideband
  • PTK Pairwise Temporal Key
  • the initiator sends a message to the responder: MN 11 SC I IPTKID
  • the temporary key identification PTKID is a value randomly selected by the initiator (not the temporary key identifier TKID used in the locally stored or ongoing four-step handshake protocol or the group temporary key GTK (Group Temporal Key) distribution protocol ( Temporal Key Identifier ) is the same), the master key identifier MKID is the flag of the paired master key PMK, and the I-Nonce is the random number generated by the initiator using the random number generation function, the paired temporary key message integrity code PTK- The MIC is 0, indicating that the pairwise temporary key message integrity code PTK-MIC is not calculated;
  • the responder After the responder receives the message 1, if the message sequence number MN is 1, the status code SC is 0, and the paired temporary key message integrity code PTK-MIC is 0, the message is discarded, otherwise the master key is verified. Identifies whether the MKID is a paired master pre-shared by the initiator and the responder The identifier of the key PMK; if not, discard the message, otherwise verify whether there is a four-step handshake protocol that the MKID is executing using the master key; if it exists, discard the message and set the status code SC to 2 ( Indicates that there is a four-step handshake protocol that the MKID is executing using the master key) to report the protocol status to the initiator, otherwise verify the paired temporary key identification PTKID; if the paired temporary key identifies the PTKID with the locally stored or ongoing If the temporary key identifier TKID used in the four-step handshake protocol or the group temporary key GTK distribution protocol is the same, the message is discarded and the status code SC
  • the initiator After the initiator receives the message 2, if the message sequence number MN is 2, the status code SC is 0, and the paired temporary key identifier PTKID and the master key identifier MKID are the corresponding values in the message 1, the message is discarded. Otherwise, the extended function is used to calculate the paired master key PMK, I-Nonce, R-Nonce, the initiator's MAC address I-MAC and the responder's MAC address R-MAC to obtain the paired temporary key PTK and the key.
  • the paired temporary key message integrity code PTK-MIC is the local key confirmation key KCK to message 3 (except the paired temporary key message integrity code PTK-MIC) Other parameters), the initiator's MAC address I-MAC and the responder's MAC address R-MAC calculated message integrity code MIC;
  • the responder After the responder receives the message 3, if the message sequence number MN is 3, the status code SC is 0, and the paired temporary key identifier PTKID and the master key identifier MKID are not corresponding to the value in the message 2, the message is discarded. Otherwise, the local key confirmation key KCK is used to recalculate message 3 (other parameters than the paired temporary key message integrity code PTK-MIC), the initiator's MAC address I-MAC, and the responder's MAC address R- The message integrity code MIC of the MAC is compared with the paired temporary key message integrity code PTK-MIC in message 3.
  • the message is discarded and the status code SC is set to 1 (indicating security verification) Does not pass) to report the protocol status to the responder, otherwise send a message to the initiator 4: MN 11 SC I (PTKID
  • the paired temporary key message integrity code PTK-MIC is the local key confirmation key KCK to the message 4 (except Paired temporary key message integrity code PTK-MIC Parameters), MAC address MAC address of the initiator and the responder I-MAC of R-MAC message integrity code calculated the MIC;
  • the initiator After the initiator receives the message 4, if the message sequence number MN is 4, the status code SC is 0, and the paired temporary key identifier PTKID and the master key identifier MKID are the corresponding values in the message 3, the message is discarded. Otherwise, the local key confirmation key KCK is used to recalculate message 4 (other parameters than the paired temporary key message integrity code PTK-MIC), the initiator's MAC address I-MAC, and the responder's MAC address R- MAC message complete The code MIC is compared with the paired temporary key message integrity code PTK-MIC in message 4; if the two are not the same, the message is discarded, otherwise the initiator and the responder successfully complete the four-step handshake protocol. The respective paired temporary key PTK and key confirmation key KCK are obtained respectively.
  • the unicast service data between the two is protected by the paired temporary key PTK.
  • the present invention solves the above technical problems existing in the background art, and provides a three-step handshake protocol method suitable for an ultra-wideband network, which is more computationally resource-saving.
  • a three-step handshake protocol method characterized in that: the method comprises the following steps: 1) The initiator sends a message 1 to the responder, the message 1 including the paired temporary key identifier PTKID, the master key identifier MKID, and the update Identifies the UD and the random number I-Nonce, where the PTKID is a value randomly selected by the initiator, and the paired PTKID does not match the temporary secret used in the locally stored or ongoing three-step handshake protocol or the group temporary key GTK distribution protocol.
  • the key identifier TKID is the same, the MKID is a flag of the paired master key PMK, UD indicates whether it is the update process of the paired temporary key PTK, and the I-Nonce is a random number generated by the initiator;
  • the responder After receiving the message 1, the responder verifies the MKID and the PTKID, and after the MKID and the PTKID pass the verification, performs the step al)
  • step a2) Verify that UP is the PTK update process; if not, perform step a2), and if so, check if I-Nonce has successfully negotiated with the last saved PTK locally.
  • the I-Nonce value negotiated by the initiator and the responder is the same. If not, the message is discarded. If they are the same, step a2) is performed;
  • A2) Calculating a random number R-Nonce using a random number generating function, and using the extended function pair paired master key PMK:, I-Nonce, R-Nonce, initiator's MAC address I-MAC, and responder's MAC address
  • the R-MAC calculates the PTK, the key confirmation key KCK, and the seed of the I-Nonce of the next ⁇ negotiation process, and then uses the extension function to calculate the I-Nonce of the next PTK negotiation process and saves it.
  • the initiator sends message 2, which includes PTKID, MKID, UD, R-Nonce and paired temporary key message integrity code PTK-MIC, where PTKID, MKID and UD are the same as corresponding values in message 1, PTK-
  • the MIC is the message integrity code MIC calculated by the local KCK for other parameters in the message 2 except the PTK-MIC, the I-Nonce in the message 1, the initiator's MAC address I-MAC, and the responder's MAC address R-MAC. ;
  • the initiator After receiving the message 2, the initiator compares whether the corresponding parameters in the message 2 and the message 1 are the same. If not, the message is discarded; otherwise, the master key PMK, I-Nonce, R-Nonce, initiator The MAC address I-MAC and the responder's MAC address R-MAC are calculated to obtain the I-Nonce of the next PTK negotiation process and saved, and the local KCK is used to recalculate the MIC and compare it with the PTK-MIC in the message 3; If the information is different, the message is discarded, otherwise the message 3 is sent to the initiator, and the message 3 includes PTKID, MKID, UD, R-Nonce, PTK-MIC;
  • the responder After receiving the message 3, the responder compares whether the corresponding parameters in the message 3 and the message 2 are the same, and discards the message if they are not the same; otherwise, the MIC is recalculated by using the local KCK and compared with the PTK-MIC in the message 3. If the two are not the same, discard the message. If they are the same, the three-step handshake protocol process ends.
  • the I-Nonce when I-Nonce establishes the PTK for the first time, the I-Nonce is generated by the initiator using the random number generation function.
  • the PTK is updated, the I-Nonce is the initiator of the last PTK negotiation process and The value negotiated by the responder.
  • Step 4) further includes steps 5) and 6), the specific steps are as follows: 5)
  • the responder sends a message 4 to the initiator, the message 4 includes a PTKID, an MKID, UD, I-Nonce, PTK-MIC, etc., where PTKID, MKID, UD, and I-Nonce are the same as the corresponding values in Message 1, and PTK-MIC is a parameter other than PTK-MIC in Message 4 using local KCK,
  • the verification of MKID and PTKID includes:
  • Whether the comparison message 2 and the corresponding parameter in the message 1 are the same include: comparing whether the corresponding values in the PTKID, the MKID, the UD and the I-Nonce in the message 2 and the message 1 are true.
  • the calculating of the master key PMK:, I-Nonce, R-Nonce, the initiator's MAC address I-MAC, and the responder's MAC address R-MAC to obtain the I-Nonce of the next PTK negotiation process and saving includes:
  • the MAC address I-MAC and the responder's MAC address R-MAC are calculated to obtain the PTK:, KCK and the seed of the I-Nonce of the next PTK negotiation process;
  • the extension function is used for the seed to calculate the I-Nonce of the next PTK negotiation process and save it.
  • the initiator recalculating the MIC using the local KCK includes:
  • the local KCK is used to recalculate the parameters other than the PTK-MIC in Message 2, the I-Nonce in Message 1, the MAC address of the initiator, the I-MAC, and the MAC address of the Responder's MAC address R-MAC.
  • the message 3 includes PTKID, MKID, UD, R-Nonce, PTK-MIC, where PTKID, MKID, UD and random number R-Nonce are the same as corresponding values in message 2, and PTK-MIC uses local KCK to message 3 other parameters except PTK-MIC, the initiator's MAC address I-MAC and the responder's MAC address R-MAC calculated MIC.
  • comparison message 3 and the corresponding parameter in the message 2 are the same include: comparing whether the PTKID, the MKID, the UD, and the random number R-Nonce in the message 3 and the corresponding value in the message 2 are true.
  • the responder recalculates the MIC using the local KCK to include:
  • the local KCK is used to recalculate the parameters other than the PTK-MIC in Message 3, the initiator's MAC address I-MAC, and the responder's MAC address R-MAC MIC.
  • the present invention provides a three-step handshake protocol method suitable for an ultra-wideband network.
  • the sender directly sends the I-Nonce construct message 1 generated and saved by the last paired temporary key PTK negotiation process.
  • the message exchanged by the three-step handshake protocol does not need to be encrypted, so the four-step handshake protocol of ECMA386 not only has anti-replay function, but also has advantages in resource-constrained applications.
  • the paired temporary key identifier PTKID is a randomly selected value of the initiator (not associated with a locally stored or ongoing three-step handshake protocol or a temporary key identifier used in a group temporary key GTK distribution protocol)
  • the TKID is the same)
  • the master key identifier MKID is a flag of the paired master key PMK
  • the update flag UD indicates whether it is the update process of the paired temporary key PTK
  • the I-Nonce is the random number generated by the initiator (at the first time)
  • the pairwise temporary key PTK is established, the I-Nonce is generated by the initiator using the random number generating function.
  • the I-Nonce is initiated after the last paired temporary key PTK negotiation process succeeds.
  • step 2.5 Verifying that the update identifier UD is a paired temporary key PTK update process; if not, performing step 2.5), and if so, checking whether the I-Nonce has successfully negotiated with the locally saved last paired temporary key PTK. The I-Nonce value negotiated by the initiator and the responder is the same. If not, the message is discarded. If they are the same, step 2.5) is performed;
  • the temporary key identifier PTKID, the master key identifier MKID, and the update identifier UD are the same as the corresponding values in the message 1, and the paired temporary key message integrity code PTK-MIC is the local key confirmation key KCK pair message 2 ( In addition to the paired temporary key message integrity code PTK-MIC other parameters), the random number I-Nonce in message 1, the initiator's MAC address I-MAC and the responder's MAC address R-MAC calculated message complete MIC
  • step 3.2) If the paired temporary key identifier PTKID, the master key identifier MKID, and the update identifier UD and the random number I-Nonce are different from the corresponding values in the message 1, the message is discarded, and if they are the same, step 3.2) ;
  • extension function to calculate the paired master key PMK, I-Nonce, R-Nonce, the initiator's MAC address I-MAC and the responder's MAC address R-MAC to obtain the paired temporary key PTK, the key Confirm the seed KCK and the seed of the I-Nonce of the next paired temporary key ⁇ negotiation process, and then use the extension function to calculate the I-Nonce of the next paired temporary key PTK negotiation process and save it, using the local
  • the key confirmation key KCK recalculates message 2 (other parameters than the paired temporary key message integrity code PTK-MIC), the random number I-Nonce in message 1, the initiator's MAC address I-MAC, and the response
  • the message integrity code MIC of the MAC address R-MAC of the user is compared with the paired temporary key message integrity code PTK-MIC in message 2; if the two are not the same, the message is discarded, otherwise the initiator is Sending message 3, the message 3 includes PTKID, MKID, UD, R-N
  • the responder may also send the message 4 to the initiator after receiving the message 3, ie in the above step 4) After performing the following steps 5) and 6).
  • the responder sends a message 4 to the initiator, the message 4 including PTKID, MKID, UD, I-Nonce, PTK-MIC, etc., wherein the paired temporary key identifier PTKID, the master key identifier MKID, the update identifier UD, and the random number I-Nonce is the same as the corresponding value in message 1.
  • the paired temporary key message integrity code PTK-MIC is the local key confirmation key KCK to message 4 (except the paired temporary key message integrity code PTK-MIC) Other parameters), the initiator's MAC address I-MAC and the responder's MAC address R-MAC calculated message integrity code MIC;

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Power Engineering (AREA)
  • Mobile Radio Communication Systems (AREA)

Description

一种三步握手协议方法 本申请要求于 2008 年 12 月 9 日提交中国专利局、 申请号为 200810184137.1、 发明名称为"一种三步握手协议方法"的中国专利申 请的优先权， 其全部内容通过引用结合在本申请中。 技术领域
本发明涉及网络安全技术领域， 尤其涉及一种三步握手协议方 法。
背景技术
欧洲电月禽厂商十办会 ECMA ( European Computer Manufacturers Association, ECMA )于 2005年推出 ECMA368标准定义超宽带 UWB ( Ultra Wideband )物理层和 MAC层规范。 超宽带 UWB是一种无载 波通信技术，利用纳秒至微秒级的正弦波窄脉冲传输数据。 ECMA368 标准中设计了一种四步握手协议 ( 4-way handshake ), 用于建立或更 新超宽带 UWB 设备之间的成对临时密钥 PTK ( Pairwise Temporal Key )„ 该四步握手协议如下：
1 ) 发 起 者 向 响 应 者 发 送 消 息 1 ： MN 11 SC I IPTKID | |MKID | |I-Nonce | (PTK-MIC , 其中消息序号 MN为 1 , 状态码 SC为 0, 表示协议处于正常状态， 成对临时密钥标识 PTKID 是发起者随机选取的值（不与本地存储的或正在进行的四步握手协议 或成组临时密钥 GTK ( Group Temporal Key )分发协议中使用的临时 密钥标识 TKID ( Temporal Key Identifier )相同）， 主密钥标识 MKID 是成对主密钥 PMK的标志， I-Nonce是发起者利用随机数产生函数 计算生成的随机数， 成对临时密钥消息完整性码 PTK-MIC为 0, 表 示没有计算成对临时密钥消息完整性码 PTK-MIC;
2 )响应者收到消息 1后， 若消息序号 MN为 1 , 状态码 SC为 0 且成对临时密钥消息完整性码 PTK-MIC为 0不成立，则丟弃该消息， 否则验证主密钥标识 MKID是否为发起者和响应者预共享的成对主 密钥 PMK的标识； 若不是， 则丟弃该消息， 否则验证是否存在使用 该主密钥标识 MKID正在执行的四步握手协议； 若存在，则丟弃该消 息并设置状态码 SC为 2 (表示存在使用该主密钥标识 MKID正在执 行的四步握手协议）来向发起者报告协议状态， 否则验证成对临时密 钥标识 PTKID; 若成对临时密钥标识 PTKID与本地存储的或正在进 行的四步握手协议或成组临时密钥 GTK分发协议中使用的临时密钥 标识 TKID相同， 则丟弃该消息并设置状态码 SC为 3 (表示该成对 临时密钥标识 PTKID与本地存储的或正在进行的四步握手协议或成 组临时密钥 GTK分发协议中使用的临时密钥标识 TKID相同）来向 发起者报告协议状态，否则生成随机数 R-Nonce并利用扩展函数对成 对主密钥 PMK, I-Nonce, R-Nonce, 发起者的 MAC地址 I-MAC和 响应者的 MAC地址 R-MAC进行计算得到成对临时密钥 PTK和密钥 确认密钥 KCK ( Key Confirmation Key ), 然后向发起者发送消息 2 = MN 11 SC I (PTKID | |MKID | |R-Nonce | (PTK-MIC , 其中消息序号 MN为 2, 状态码 SC为 0,成对临时密钥标识 PTKID和主密钥标识 MKID与消 息 1中的对应值相同， 成对临时密钥消息完整性码 PTK-MIC是利用 本地密钥确认密钥 KCK对消息 2 (除成对临时密钥消息完整性码 PTK-MIC外的其他参数）、 发起者的 MAC地址 I-MAC和响应者的 MAC 地址 R-MAC 计算的消息完整性码 MIC ( Message Integrity Code );
3 )发起者收到消息 2后，若消息序号 MN为 2,状态码 SC为 0, 成对临时密钥标识 PTKID和主密钥标识 MKID是消息 1中的对应值 不成立， 则丟弃该消息， 否则利用扩展函数对成对主密钥 PMK, I-Nonce, R-Nonce, 发起者的 MAC地址 I-MAC和响应者的 MAC地 址 R-MAC进行计算得到成对临时密钥 PTK和密钥确认密钥 KCK, 然后利用本地密钥确认密钥 KCK重新计算消息 2 (除成对临时密钥 消息完整性码 PTK-MIC外的其他参数）、发起者的 MAC地址 I-MAC 和响应者的 MAC地址 R-MAC的消息完整性码 MIC并与消息 2中的 成对临时密钥消息完整性码 PTK-MIC进行比较； 若两者不相同， 则 丟弃该消息并设置状态码 SC为 1 (表示安全验证不通过）来向响应 者 报告 协议 状 态 ， 否 则 向 响 应 者 发 送 消 息 3 ： MN 11 SC I IPTKID | |MKID | |I-Nonce | (PTK-MIC , 其中消息序号 MN为 3 , 状态码 SC为 0,成对临时密钥标识 PTKID和主密钥标识 MKID与消 息 2中的对应值相同， 成对临时密钥消息完整性码 PTK-MIC是利用 本地密钥确认密钥 KCK对消息 3 (除成对临时密钥消息完整性码 PTK-MIC外的其他参数）、 发起者的 MAC地址 I-MAC和响应者的 MAC地址 R-MAC计算的消息完整性码 MIC;
4 )响应者收到消息 3后，若消息序号 MN为 3 ,状态码 SC为 0, 成对临时密钥标识 PTKID和主密钥标识 MKID是消息 2中的对应值 不成立， 则丟弃该消息， 否则利用本地密钥确认密钥 KCK重新计算 消息 3 (除成对临时密钥消息完整性码 PTK-MIC外的其他参数）、 发 起者的 MAC地址 I-MAC和响应者的 MAC地址 R-MAC的消息完整 性码 MIC并与消息 3中的成对临时密钥消息完整性码 PTK-MIC进行 比较； 若两者不相同， 则丟弃该消息并设置状态码 SC为 1 (表示安 全验证不通过）来向响应者报告协议状态，否则向发起者发送消息 4: MN 11 SC I (PTKID | |MKID | |R-Nonce | (PTK-MIC , 其中消息序号 MN为 4, 状态码 SC为 0,成对临时密钥标识 PTKID和主密钥标识 MKID与消 息 3中的对应值相同， 成对临时密钥消息完整性码 PTK-MIC是利用 本地密钥确认密钥 KCK对消息 4 (除成对临时密钥消息完整性码 PTK-MIC外的其他参数）、 发起者的 MAC地址 I-MAC和响应者的 MAC地址 R-MAC计算的消息完整性码 MIC;
5 )发起者收到消息 4后，若消息序号 MN为 4,状态码 SC为 0, 成对临时密钥标识 PTKID和主密钥标识 MKID是消息 3中的对应值 不成立， 则丟弃该消息， 否则利用本地密钥确认密钥 KCK重新计算 消息 4 (除成对临时密钥消息完整性码 PTK-MIC外的其他参数）、 发 起者的 MAC地址 I-MAC和响应者的 MAC地址 R-MAC的消息完整 性码 MIC并与消息 4中的成对临时密钥消息完整性码 PTK-MIC进行 比较； 若两者不相同， 则丟弃该消息， 否则发起者和响应者成功完成 了四步握手协议， 各自获得了相应的成对临时密钥 PTK和密钥确认 密钥 KCK。
发起者和响应者完成上述四步握手协议之后，利用成对临时密钥 PTK保护两者之间的单播业务数据。
从上述的四步握手协议可见： 每次需要进行成对临时密钥 PTK 更新时， 发起者和响应者需利用正在使用的成对临时密钥 PTK加密 交互四步握手协议， 且发起者需重新计算生成新的随机数 I-Nonce。 而超宽带 UWB通信网络在某些应用中，设备是低功率、低能耗的（使 用电池供电）， 它们的能源、 通信和计算等资源相当受限， 在更新成 对临时密钥 PTK时会面临资源受限的困惑。
发明内容
本发明为解决背景技术中存在的上述技术问题，而提供一种更为 节省计算资源的适合超宽带网络的三步握手协议方法。
本发明的技术解决方案是：
1、 一种三步握手协议方法， 其特征在于： 该方法包括以下步骤： 1 )发起者向响应者发送消息 1 , 消息 1 中包括成对临时密钥标识 PTKID、 主密钥标识 MKID、 更新标识 UD和随机数 I-Nonce, 其中 PTKID是发起者随机选取的值 , 该成对 PTKID不与本地存储的或正 在进行的三步握手协议或成组临时密钥 GTK分发协议中使用的临时 密钥标识 TKID相同， MKID是成对主密钥 PMK的标志， UD表示 是否为成对临时密钥 PTK的更新过程， I-Nonce是发起者生成的随机 数；
2 )响应者收到消息 1后， 对 MKID、 PTKID进行验证， 并在 所述 MKID、 PTKID通过验证后， 执行步骤 al )
al )验证 UP是否为 PTK更新过程; 若不是， 则执行步骤 a2 ) , 若是，则检查 I-Nonce是否与本地保存的上一次 PTK协商过程成功后 发起者和响应者所协商的 I-Nonce值相同，若不相同，则丟弃该消息， 若相同， 则执行步骤 a2 ) ；
a2 )利用随机数产生函数计算生成随机数 R-Nonce, 并利用扩 展函数对成对主密钥 PMK：、 I-Nonce, R-Nonce、发起者的 MAC地址 I-MAC和响应者的 MAC地址 R-MAC进行计算得到 PTK、 密钥确认 密钥 KCK和下一次 ΡΤΚ协商过程的 I-Nonce的种子， 然后对该种子 使用扩展函数计算得到下一次 PTK协商过程的 I-Nonce并保存 ,并向 发起者发送消息 2, 消息 2中包括 PTKID、 MKID、 UD、 R-Nonce和 成对临时密钥消息完整性码 PTK-MIC, 其中 PTKID、 MKID和 UD 与消息 1中的对应值相同， PTK-MIC是利用本地 KCK对消息 2中除 PTK-MIC外的其他参数、 消息 1中的 I-Nonce、 发起者的 MAC地址 I-MAC和响应者的 MAC地址 R-MAC计算的消息完整性码 MIC;
3 )发起者收到消息 2后， 比较消息 2与消息 1中对应的参数是 否相同， 如果不相同则丟弃该消息； 否则， 对主密钥 PMK、 I-Nonce, R-Nonce、发起者的 MAC地址 I-MAC和响应者的 MAC地址 R-MAC 进行计算得到下一次 PTK协商过程的 I-Nonce并保存，利用本地 KCK 重新计算 MIC并与消息 3中的 PTK-MIC进行比较； 若两者不相同， 则丟弃该消息， 否则向发起者发送消息 3 , 消息 3 中包括 PTKID、 MKID, UD、 R-Nonce、 PTK-MIC;
4 )响应者收到消息 3后， 比较消息 3与消息 2中对应的参数是 否相同， 如果不相同则丟弃该消息； 否则利用本地 KCK 重新计算 MIC并与消息 3中的 PTK-MIC进行比较； 若两者不相同， 则丟弃该 消息， 若相同， 结束三步握手协议过程。
所述步骤 1 ) 中 I-Nonce在第一次建立 PTK时， I-Nonce是发起 者利用随机数产生函数生成的， 在更新 PTK 时， I-Nonce 为上一次 PTK协商过程成功后发起者和响应者所协商的值。
所述步骤 4 )之后还包括步骤 5 )和步骤 6 ) , 其具体步骤如下： 5 )响应者向发起者发送消息 4, 消息 4包括 PTKID, MKID、 UD、 I-Nonce、 PTK-MIC等， 其中 PTKID、 MKID、 UD和 I-Nonce 与消息 1中的对应值相同 , PTK-MIC是利用本地 KCK对消息 4中除 PTK-MIC 外的其他参数、 发起者的 MAC地址 I-MAC和响应者的 MAC地址 R-MAC计算的 MIC;
6 )发起者收到消息 4后， 进行如下处理：
6.1 )若 PTKID、 MKID、 UD和 I-Nonce与消息 1中的对应值不 相同， 则丟弃该消息， 若相同， 则执行 6.2 )操作；
6.2 )利用本地 KCK重新计算消息 4中除 PTK-MIC外的其他参 数、 发起者的 MAC地址 I-MAC和响应者的 MAC地址 R-MAC的 MIC, 并与消息 4中的 PTK-MIC进行比较； 若两者不相同， 则丟弃 该消息， 若相同， 则发起者和响应者成功完成了四步握手协议， 各自 获得了相应的 PTK密钥、 确认密钥 KCK和下一次双方用于 PTK更 新时的 I-Nonce„
对 MKID、 PTKID进行验证包括：
2.1 )验证 MKID 是否为发起者和响应者预共享的成对主密钥 PMK的标识； 若不是， 则丟弃该消息， 若是则执行步骤 2.2 ) ；
2.2 )验证是否存在使用该 MKID正在执行的三步握手协议； 若 存在， 则丟弃该消息， 若不存在， 则执行步骤 2.3 ) ；
2.3 )验证 PTKID; 若 PTKID与本地存储的或正在进行的三步握 手协议或成组临时密钥 GTK分发协议中使用的 TKID相同， 则丟弃 该消息， 若不相同， 则执行步骤 2.4 ) 。
所述比较消息 2与消息 1中对应的参数是否相同包括： 比较消息 2中的 PTKID、 MKID, UD和 I-Nonce与消息 1中的 对应值是否成立。
所述对主密钥 PMK：、 I-Nonce、 R-Nonce, 发起者的 MAC地址 I-MAC和响应者的 MAC地址 R-MAC进行计算得到下一次 PTK协商 过程的 I-Nonce并保存包括：
利用扩展函数对成对主密钥 PMK、 I-Nonce, R-Nonce、 发起者 的 MAC地址 I-MAC和响应者的 MAC地址 R-MAC进行计算得到 PTK：、 KCK和下一次 PTK协商过程的 I-Nonce的种子；
对该种子使用扩展函数计算得到下一次 PTK 协商过程的 I-Nonce并保存。
所述发起者利用本地 KCK重新计算 MIC包括：
利用本地 KCK重新计算消息 2中除 PTK-MIC外的其他参数、 消息 1中的 I-Nonce、 发起者的 MAC地址 I-MAC和响应者的 MAC 地址 R-MAC的 MIC。
所述消息 3中包括 PTKID、 MKID、 UD、 R-Nonce、 PTK-MIC, 其中 PTKID、 MKID、 UD和随机数 R-Nonce与消息 2中的对应值相 同 , PTK-MIC是利用本地 KCK对消息 3中除 PTK-MIC外的其他参 数、 发起者的 MAC地址 I-MAC和响应者的 MAC地址 R-MAC计算 的 MIC。
所述比较消息 3与消息 2中对应的参数是否相同包括： 比较消息 3中的 PTKID、 MKID、 UD和随机数 R-Nonce与消息 2中的对应值是否成立。
所述响应者利用本地 KCK重新计算 MIC包括：
利用本地 KCK重新计算消息 3中除 PTK-MIC外的其他参数、 发起者的 MAC地址 I-MAC和响应者的 MAC地址 R-MAC的 MIC。
本发明提供一种适合超宽带网络的三步握手协议方法， 当成对临 时密钥 PTK更新时， 发送者直接利用上一次成对临时密钥 PTK协商 过程产生并保存的 I-Nonce构造消息 1发送给响应者， 同时三步握手 协议所交互的消息无需进行加密处理， 因此相比 ECMA386的四步握 手协议不仅具有防重放的功能， 而且在资源受限的应用中更具有优 势。
具体实施方式
本发明的具体实现方法如下：
1 ) 向响应者发送消息 1 , 消息 1中包括 PTKID、 MKID、 UD、 I-Nonce 等， 其中成对临时密钥标识 PTKID是发起者随机选取的值 (不与本地存储的或正在进行的三步握手协议或成组临时密钥 GTK 分发协议中使用的临时密钥标识 TKID相同）， 主密钥标识 MKID是 成对主密钥 PMK的标志，更新标识 UD表示是否为成对临时密钥 PTK 的更新过程， I-Nonce是发起者生成的随机数 (在第一次建立成对临 时密钥 PTK时， I-Nonce是发起者利用随机数产生函数生成的， 在更 新成对临时密钥 PTK时， I-Nonce为上一次成对临时密钥 PTK协商 过程成功后发起者和响应者所协商的值） ；
2 )响应者收到消息 1后， 进行如下处理：
2.1 )验证主密钥标识 MKID是否为发起者和响应者预共享的成 对主密钥 PMK的标识；若不是，则丟弃该消息，若是则执行步骤 2.2 );
2.2 )验证是否存在使用该主密钥标识 MKID正在执行的三步握 手协议； 若存在， 则丟弃该消息， 若不存在， 则执行步骤 2.3 ) ；
2.3 证成对临时密钥标识 PTKID;若成对临时密钥标识 PTKID 与本地存储的或正在进行的三步握手协议或成组临时密钥 GTK分发 协议中使用的临时密钥标识 TKID相同， 则丟弃该消息， 若不相同， 则执行步骤 2.4 ) ；
2.4 )验证更新标识 UD是否为成对临时密钥 PTK更新过程； 若 不是， 则执行步骤 2.5 ) , 若是， 则检查 I-Nonce是否与本地保存的 上一次成对临时密钥 PTK协商过程成功后发起者和响应者所协商的 I-Nonce值相同，若不相同，则丟弃该消息，若相同，则执行步骤 2.5 )；
2.5 )利用随机数产生函数计算生成随机数 R-Nonce, 并利用扩 展函数对成对主密钥 PMK：、 I-Nonce、 R-Nonce、发起者的 MAC地址 I-MAC 和响应者的 MAC地址 R-MAC进行计算得到成对临时密钥 PTK、 密钥确认密钥 KCK和下一次成对临时密钥 ΡΤΚ协商过程的 I-Nonce的种子， 然后对该种子使用扩展函数计算得到下一次成对临 时密钥 PTK协商过程的 I-Nonce并保存， 并向发起者发送消息 2 , 消 息 2中包括 PTKID、 MKID, UD、 R-Nonce、 PTK-MIC等， 其中成 对临时密钥标识 PTKID、主密钥标识 MKID和更新标识 UD与消息 1 中的对应值相同， 成对临时密钥消息完整性码 PTK-MIC是利用本地 密钥确认密钥 KCK 对消息 2 (除成对临时密钥消息完整性码 PTK-MIC外的其他参数） 、 消息 1 中的随机数 I-Nonce、 发起者的 MAC地址 I-MAC和响应者的 MAC地址 R-MAC计算的消息完整性 码 MIC;
3 )发起者收到消息 2后， 进行如下处理：
3.1 )若成对临时密钥标识 PTKID、 主密钥标识 MKID和更新标 识 UD和随机数 I-Nonce与消息 1中的对应值不相同，则丟弃该消息， 若相同， 则执行步骤 3.2 ) ；
3.2 )利用扩展函数对成对主密钥 PMK、 I-Nonce, R-Nonce、 发 起者的 MAC地址 I-MAC和响应者的 MAC地址 R-MAC进行计算得 到成对临时密钥 PTK、 密钥确认密钥 KCK和下一次成对临时密钥 ΡΤΚ协商过程的 I-Nonce的种子， 然后对该种子使用扩展函数计算得 到下一次成对临时密钥 PTK协商过程的 I-Nonce并保存，利用本地密 钥确认密钥 KCK 重新计算消息 2 (除成对临时密钥消息完整性码 PTK-MIC外的其他参数） 、 消息 1 中的随机数 I-Nonce、 发起者的 MAC地址 I-MAC和响应者的 MAC地址 R-MAC的消息完整性码 MIC 并与消息 2中的成对临时密钥消息完整性码 PTK-MIC进行比较； 若 两者不相同， 则丟弃该消息， 否则向发起者发送消息 3 , 消息 3中包 括 PTKID、 MKID, UD、 R-Nonce、 PTK-MIC等， 其中成对临时密 钥标识 PTKID、 主密钥标识 MKID、 更新标识 UD和随机数 R-Nonce 与消息 2中的对应值相同， 成对临时密钥消息完整性码 PTK-MIC是 利用本地密钥确认密钥 KCK对消息 3 (除成对临时密钥消息完整性 码 PTK-MIC外的其他参数 )、 发起者的 MAC地址 I-MAC和响应者 的 MAC地址 R-MAC计算的消息完整性码 MIC;
4 )响应者收到消息 3后， 进行如下处理：
4.1 )若成对临时密钥标识 PTKID、 主密钥标识 MKID、 更新标 识 UD和随机数 R-Nonce与消息 2中的对应值不相同，则丟弃该消息， 若相同， 则执行 4.2 )操作；
4.2 )利用本地密钥确认密钥 KCK重新计算消息 3 (除成对临时 密钥消息完整性码 PTK-MIC外的其他参数） 、 发起者的 MAC地址 I-MAC和响应者的 MAC地址 R-MAC的消息完整性码 MIC并与消息 3 中的成对临时密钥消息完整性码 PTK-MIC进行比较； 若两者不相 同， 则丟弃该消息， 若相同， 则发起者和响应者成功完成了三步握手 协议， 各自获得了相应的成对临时密钥 PTK密钥、确认密钥 KCK和 下一次双方用于成对临时密钥 PTK更新时的 I-Nonce。
为了便于安装成对临时密钥 PTK并向发起者通知响应者已成功 协商出成对临时密钥 PTK,响应者在收到消息 3后还可以向发起者发 送消息 4, 即在上述步骤 4 )后执行如下步骤 5 )和 6 ) 。
5 )响应者向发起者发送消息 4, 消息 4包括 PTKID, MKID、 UD、 I-Nonce, PTK-MIC等， 其中成对临时密钥标识 PTKID、 主密 钥标识 MKID、 更新标识 UD和随机数 I-Nonce与消息 1中的对应值 相同， 成对临时密钥消息完整性码 PTK-MIC是利用本地密钥确认密 钥 KCK对消息 4 (除成对临时密钥消息完整性码 PTK-MIC外的其他 参数 ) 、 发起者的 MAC地址 I-MAC和响应者的 MAC地址 R-MAC 计算的消息完整性码 MIC；
6 )发起者收到消息 4后， 进行如下处理：
6.1 )若成对临时密钥标识 PTKID、 主密钥标识 MKID、 更新标 识 UD和随机数 I-Nonce与消息 1中的对应值不相同，则丟弃该消息， 若相同， 则执行 6.2 )操作；
6.2 )利用本地密钥确认密钥 KCK重新计算消息 4 (除成对临时 密钥消息完整性码 PTK-MIC外的其他参数）、 发起者的 MAC地址 I-MAC和响应者的 MAC地址 R-MAC的消息完整性码 MIC, 并与消 息 4中的成对临时密钥消息完整性码 PTK-MIC进行比较； 若两者不 相同， 则丟弃该消息， 若相同， 则发起者和响应者成功完成了四步握 手协议， 各自获得了相应的成对临时密钥 PTK密钥、 确认密钥 KCK 和下一次双方用于成对临时密钥 ΡΤΚ更新时的 I-Nonce。
虽然通过实施例描绘了本申请， 本领域普通技术人员知道， 本申 请有许多变形和变化而不脱离本申请的精神，希望所附的权利要求包 括这些变形和变化而不脱离本申请的精神。

Claims

权 利 要 求
1、 一种三步握手协议方法， 其特征在于： 该方法包括以下步骤： 1 )发起者向响应者发送消息 1 , 消息 1 中包括成对临时密钥标识 PTKID、 主密钥标识 MKID、 更新标识 UD和随机数 I-Nonce, 其中 PTKID是发起者随机选取的值 , 该成对 PTKID不与本地存储的或正 在进行的三步握手协议或成组临时密钥 GTK分发协议中使用的临时 密钥标识 TKID相同， MKID是成对主密钥 PMK的标志， UD表示 是否为成对临时密钥 PTK的更新过程， I-Nonce是发起者生成的随机 数；
2 )响应者收到消息 1后， 对 MKID、 PTKID进行验证， 并在 所述 MKID、 PTKID通过验证后， 执行步骤 al )
al )验证 UP是否为 PTK更新过程; 若不是， 则执行步骤 a2 ) , 若是，则检查 I-Nonce是否与本地保存的上一次 PTK协商过程成功后 发起者和响应者所协商的 I-Nonce值相同，若不相同，则丟弃该消息， 若相同， 则执行步骤 a2 ) ；
a2 )利用随机数产生函数计算生成随机数 R-Nonce, 并利用扩 展函数对成对主密钥 PMK：、 I-Nonce、 R-Nonce、发起者的 MAC地址 I-MAC和响应者的 MAC地址 R-MAC进行计算得到 PTK、 密钥确认 密钥 KCK和下一次 ΡΤΚ协商过程的 I-Nonce的种子， 然后对该种子 使用扩展函数计算得到下一次 PTK协商过程的 I-Nonce并保存 ,并向 发起者发送消息 2, 消息 2中包括 PTKID、 MKID, UD、 R-Nonce和 成对临时密钥消息完整性码 PTK-MIC, 其中 PTKID、 MKID和 UD 与消息 1中的对应值相同， PTK-MIC是利用本地 KCK对消息 2中除 PTK-MIC外的其他参数、 消息 1中的 I-Nonce、 发起者的 MAC地址 I-MAC和响应者的 MAC地址 R-MAC计算的消息完整性码 MIC;
3 )发起者收到消息 2后， 比较消息 2与消息 1中对应的参数是 否相同， 如果不相同则丟弃该消息； 否则， 对主密钥 PMK、 I-Nonce, R-Nonce、发起者的 MAC地址 I-MAC和响应者的 MAC地址 R-MAC 进行计算得到下一次 PTK协商过程的 I-Nonce并保存，利用本地 KCK 重新计算 MIC并与消息 3中的 PTK-MIC进行比较； 若两者不相同， 则丟弃该消息， 否则向发起者发送消息 3 , 消息 3 中包括 PTKID、 MKID、 UD、 R-Nonce、 PTK-MIC;
4 )响应者收到消息 3后， 比较消息 3与消息 2中对应的参数是 否相同， 如果不相同则丟弃该消息； 否则利用本地 KCK 重新计算 MIC并与消息 3中的 PTK-MIC进行比较； 若两者不相同， 则丟弃该 消息， 若相同， 结束三步握手协议过程。
2、 根据权利要求 1 所述的三步握手协议方法， 其特征在于： 所 述步骤 1 ) 中 I-Nonce在第一次建立 PTK时， I-Nonce是发起者利用 随机数产生函数生成的， 在更新 PTK时， I-Nonce为上一次 PTK协 商过程成功后发起者和响应者所协商的值。
3、 根据权利要求 1所述的三步握手协议方法， 其特征在于： 所 述步骤 4 )之后还包括步骤 5 )和步骤 6 ) , 其具体步骤如下：
5 )响应者向发起者发送消息 4, 消息 4包括 PTKID, MKID、 UD、 I-Nonce、 PTK-MIC等， 其中 PTKID、 MKID、 UD和 I-Nonce 与消息 1中的对应值相同 , PTK-MIC是利用本地 KCK对消息 4中除 PTK-MIC 外的其他参数、 发起者的 MAC地址 I-MAC和响应者的 MAC地址 R-MAC计算的 MIC;
6 )发起者收到消息 4后， 进行如下处理：
6.1 )若 PTKID、 MKID、 UD和 I-Nonce与消息 1中的对应值不 相同， 则丟弃该消息， 若相同， 则执行 6.2 )操作；
6.2 )利用本地 KCK重新计算消息 4中除 PTK-MIC外的其他参 数、 发起者的 MAC地址 I-MAC和响应者的 MAC地址 R-MAC的 MIC , 并与消息 4中的 PTK-MIC进行比较； 若两者不相同， 则丟弃 该消息， 若相同， 则发起者和响应者成功完成了四步握手协议， 各自 获得了相应的 PTK密钥、 确认密钥 KCK和下一次双方用于 PTK更 新时的 I-Nonce„ 4、 根据权利要求 1〜3任意一项所述的三步握手协议方法， 其特 征在于： 对 MKID、 PTKID进行验证包括：
2.1 )验证 MKID 是否为发起者和响应者预共享的成对主密钥 PMK的标识； 若不是， 则丟弃该消息， 若是则执行步骤 2.2 ) ；
2.2 )验证是否存在使用该 MKID正在执行的三步握手协议； 若 存在， 则丟弃该消息， 若不存在， 则执行步骤 2.3 ) ；
2.3 )验证 PTKID; 若 PTKID与本地存储的或正在进行的三步握 手协议或成组临时密钥 GTK分发协议中使用的 TKID相同， 则丟弃 该消息， 若不相同， 则执行步骤 2.
4 ) 。
5、 根据权利要求 1〜3任意一项所述的方法， 其特征在于， 所述 比较消息 2与消息 1中对应的参数是否相同包括：
比较消息 2中的 PTKID、 MKID, UD和 I-Nonce与消息 1中的 对应值是否成立。
6、 根据权利要求 1〜3任意一项所述的方法， 其特征在于， 所述 对主密钥 PMK：、 I-Nonce, R-Nonce, 发起者的 MAC地址 I-MAC和 响应者的 MAC地址 R-MAC进行计算得到下一次 PTK协商过程的 I-Nonce并保存包括：
利用扩展函数对成对主密钥 PMK、 I-Nonce, R-Nonce、 发起者 的 MAC地址 I-MAC和响应者的 MAC地址 R-MAC进行计算得到 PTK：、 KCK和下一次 PTK协商过程的 I-Nonce的种子；
对该种子使用扩展函数计算得到下一次 PTK 协商过程的 I-Nonce并保存。
7、 根据权利要求 1〜3任意一项所述的方法， 其特征在于， 所述 发起者利用本地 KCK重新计算 MIC包括：
利用本地 KCK重新计算消息 2中除 PTK-MIC外的其他参数、 消息 1中的 I-Nonce、 发起者的 MAC地址 I-MAC和响应者的 MAC 地址 R-MAC的 MIC。
8、 根据权利要求 1〜3任意一项所述的方法， 其特征在于， 所述 消息 3中包括 PTKID、 MKID、 UD、 R-Nonce、 PTK-MIC ,其中 PTKID、 MKID、 UD和随机数 R-Nonce与消息 2中的对应值相同， PTK-MIC 是利用本地 KCK对消息 3中除 PTK-MIC外的其他参数、 发起者的 MAC地址 I-MAC和响应者的 MAC地址 R-MAC计算的 MIC。
9、 根据权利要求 1〜3任意一项所述的方法， 其特征在于， 所述 比较消息 3与消息 2中对应的参数是否相同包括：
比较消息 3中的 PTKID、 MKID, UD和随机数 R-Nonce与消息 2中的对应值是否成立。
10、 根据权利要求 1〜3任意一项所述的方法， 其特征在于， 所 述响应者利用本地 KCK重新计算 MIC包括：
利用本地 KCK重新计算消息 3中除 PTK-MIC外的其他参数、 发起者的 MAC地址 I-MAC和响应者的 MAC地址 R-MAC的 MIC。
PCT/CN2009/075381 2008-12-09 2009-12-08 一种三步握手协议方法 WO2010066186A1 (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2011539880A JP5313360B2 (ja) 2008-12-09 2009-12-08 ３ウェイ・ハンドシェイク・プロトコルの方法
EP09831463.6A EP2375627B1 (en) 2008-12-09 2009-12-08 Three-way handshake protocol method

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN200810184137.1 2008-12-09
CN 200810184137 CN101431519B (zh) 2008-12-09 2008-12-09 一种三步握手协议方法

Publications (1)

Publication Number Publication Date
WO2010066186A1 true WO2010066186A1 (zh) 2010-06-17

Family

ID=40646685

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2009/075381 WO2010066186A1 (zh) 2008-12-09 2009-12-08 一种三步握手协议方法

Country Status (4)

Country Link
EP (1) EP2375627B1 (zh)
JP (1) JP5313360B2 (zh)
CN (1) CN101431519B (zh)
WO (1) WO2010066186A1 (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2012512577A (ja) * 2008-12-18 2012-05-31 西安西電捷通無線網絡通信股▲ふん▼有限公司 セキュリティ・プロトコルの最初のメッセージの保護方法

Families Citing this family (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101431519B (zh) * 2008-12-09 2011-06-01 西安西电捷通无线网络通信股份有限公司 一种三步握手协议方法
WO2011075880A1 (zh) * 2009-12-21 2011-06-30 西安西电捷通无线网络通信股份有限公司 一种适合超宽带网络的握手协议方法
WO2014091336A1 (en) * 2012-12-13 2014-06-19 Abb Research Ltd A system and a method for generating secure key
CN105025444A (zh) * 2014-04-16 2015-11-04 中兴通讯股份有限公司 一种实现设备到设备发现业务的方法及终端
TWI566616B (zh) * 2015-03-04 2017-01-11 瑞昱半導體股份有限公司 三方交握方法以及電腦可讀媒體
CN106033252B (zh) * 2015-03-11 2020-05-08 瑞昱半导体股份有限公司 三方交握方法以及电脑可读媒体
US12075246B2 (en) 2019-04-29 2024-08-27 Sonicwall Inc. Securing transmission paths in a mesh network
US12022295B2 (en) 2019-04-29 2024-06-25 Sonicwall Inc. Streamlined creation and expansion of a wireless mesh network
US11997635B2 (en) * 2019-04-29 2024-05-28 Sonicwall Inc. Establishing simultaneous mesh node connections
CN114124367B (zh) 2020-08-31 2023-03-24 Oppo广东移动通信有限公司 一种数据传输方法、装置及存储介质

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1905436A (zh) * 2005-07-28 2007-01-31 北京航空航天大学 保证数据交换安全的方法
WO2008125731A1 (en) * 2007-04-12 2008-10-23 Nokia Corporation A handshake procedure
CN101431519A (zh) * 2008-12-09 2009-05-13 西安西电捷通无线网络通信有限公司 一种三步握手协议方法

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060126847A1 (en) * 2004-11-12 2006-06-15 Jin-Meng Ho System and method for establishing secure communications between devices in distributed wireless networks
JP2009539330A (ja) * 2006-05-26 2009-11-12 クゥアルコム・インコーポレイテッド 従来方式の有線ベースのプロトコルのための無線アーキテクチャ
US8175272B2 (en) * 2007-03-12 2012-05-08 Motorola Solutions, Inc. Method for establishing secure associations within a communication network

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1905436A (zh) * 2005-07-28 2007-01-31 北京航空航天大学 保证数据交换安全的方法
WO2008125731A1 (en) * 2007-04-12 2008-10-23 Nokia Corporation A handshake procedure
CN101431519A (zh) * 2008-12-09 2009-05-13 西安西电捷通无线网络通信有限公司 一种三步握手协议方法

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
"High Rate Ultra Wideband PHY and MAC Standard, 1st edition", STANDARD ECMA-368, December 2005 (2005-12-01), pages 226 - 228 *
See also references of EP2375627A4 *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2012512577A (ja) * 2008-12-18 2012-05-31 西安西電捷通無線網絡通信股▲ふん▼有限公司 セキュリティ・プロトコルの最初のメッセージの保護方法

Also Published As

Publication number Publication date
JP5313360B2 (ja) 2013-10-09
CN101431519B (zh) 2011-06-01
EP2375627A1 (en) 2011-10-12
CN101431519A (zh) 2009-05-13
JP2012511289A (ja) 2012-05-17
EP2375627B1 (en) 2016-03-02
EP2375627A4 (en) 2013-07-03

Similar Documents

Publication Publication Date Title
WO2010066186A1 (zh) 一种三步握手协议方法
RU2454832C2 (ru) Способ аутентификации доступа, применяемый к ibss-сети
JP5399404B2 (ja) 一方向アクセス認証の方法
US20120017088A1 (en) Wireless local area network terminal pre-authentication method and wireless local area network system
WO2010069233A1 (zh) 一种安全协议第一条消息的保护方法
WO2009067902A1 (fr) Procédé d'authentification d'accès bidirectionnelle
WO2011020274A1 (zh) 一种有线局域网的安全访问控制方法及其系统
WO2012048501A1 (zh) 一种基于对称密码算法的实体鉴别方法及系统
WO2010003335A1 (zh) IPv6网络中协商SA的方法、系统和设备
WO2010135890A1 (zh) 基于对称加密算法的双向认证方法及系统
WO2011022915A1 (zh) 一种基于预共享密钥的网络安全访问控制方法及其系统
WO2010135892A1 (zh) 基于哈希函数的双向认证方法及系统
WO2014114191A1 (zh) 一种智能卡安全通讯的方法
CN104754581A (zh) 一种基于公钥密码体制的lte无线网络的安全认证方法
WO2012075825A1 (zh) 无线局域网中端站的安全配置方法、ap、sta、as及系统
Nguyen et al. Enhanced EAP-based pre-authentication for fast and secure inter-ASN handovers in mobile WiMAX networks
WO2013166908A1 (zh) 密钥信息生成方法及系统、终端设备、接入网设备
WO2012055204A1 (zh) 一种基于wapi的管理帧保护方法和装置
WO2011020279A1 (zh) 一种基于公钥证书的身份鉴别方法及其系统
WO2011072513A1 (zh) 交换设备间安全连接的建立方法及系统
WO2010121462A1 (zh) 一种自组网络下wapi站点间安全关联的建立方法
Zisiadis et al. Enhancing WPS security
CN106992866A (zh) 一种基于nfc无证书认证的无线网络接入方法
WO2012040949A1 (zh) 一种移动WiMAX网络中EAP认证快速切换方法
RU2010123869A (ru) Способ управления ключами

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 09831463

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2011539880

Country of ref document: JP

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 2009831463

Country of ref document: EP