JP2008099112A - Interconnectivity improvement method - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To solve the problem of interconnectivity due to the coexistence of an apparatus that encrypts and transmits a Message 4 and an apparatus that transmits the Message 4 without encrypting it due to the interpretation error of specifications. <P>SOLUTION: When a Message 3 is retransmitted after the transmission of an encrypted Message 4, the Message 4 is retransmitted in plain text. <P>COPYRIGHT: (C)2008,JPO&INPIT

Description

  Regarding 4-Way Handshake for wireless LAN.

  In recent years, wireless local area networks (WLANs) such as 802.11b / 11g / 11a have been installed in various products, and short-range wireless technology has become familiar. WLAN is very useful and convenient because it allows us to wirelessly connect devices that were previously connected by wire, freeing us from problems such as installation location and complicated cables. With these advantages, WLAN is expected to continue to evolve.

  As described above, WLAN is very convenient, but it is installed in various devices and is used by many people, and anxiety such as eavesdropping and security problems peculiar to wireless communication have become apparent.

  Therefore, WLAN industry groups have formulated security standards (WPA (Wi-Fi Protected Access)) that summarize security standards to enhance WLAN security.

  WPA is a very strong security standard composed of encryption and authentication technologies such as TKIP, AES, 802.1x, and 802.11i.

  Among sequences for performing WPA, there is a sequence for deriving PTK (Pairwise Transient Key) called 4-way handshake. Hereinafter, description will be given using the 4-Way Handshake sequence of FIG.

  First, it is assumed that the Supplicant and the Authenticator have the same PMK (Pairwise Master Key) according to the previous procedure not described.

  In step S301, the supplicant generates a random number called SNonce.

  In step S302, the authenticator generates a random number called ANonce, and in step S303, sends Message1 including ANonce to the supplicant.

  In step S304, the supplicant derives the PTK using the PMK and SNonce that the supplicant has and the received ANonce. In step S305, the supplicant transmits Message2 including SNonce to the authenticator.

  In step S306, the authenticator derives the PTK using its own PMK, ANonce, and the received SNonce. Therefore, the PTK derived by the Supplicant and Authenticator is the same.

  In step S307, the authenticator transmits Message3 including ANonce to the supplicant, and starts encryption in step S309.

When the Supplicant receives Message3, encryption starts in step S308, and when Message4 is transmitted to the authenticator in step S310, 4-Way Handshake is completed.
IEEE802.11i Specification

  In the 4-Way Handshake sequence shown in Fig. 3, it should be noted that Message4 is encrypted with PTK.

  However, at present, a communication device that encrypts and transmits Message4 and a communication device that transmits Message4 without encryption are mixed because of differences in the interpretation of specifications.

  The specification is correct to send Message4 encrypted. Therefore, if the communication device that receives Message 4 supports only encrypted Message 4, 4-Way Handshake will not succeed with a communication device that transmits Message 4 in plain text. In addition, since there are many communication devices that transmit Message4 in plain text, there is a high possibility that this situation will occur.

  Also, since there are many communication devices that send Message4 in plaintext, if the communication device that receives Message4 supports only plaintext, the communication device that encrypts and sends Message4 as specified is 4-way Handshake does not succeed.

  Here, an example in which an authenticator that supports only plaintext Message4 and a supplicant that encrypts and transmits Message4 fails in 4-way handshake using the sequence of FIG.

  Steps S401 to S407 are the same as S301 to S307 in FIG. However, since the Authenticator has not started encryption after sending Message3, it cannot understand the encrypted Message4 sent in Step S409, and resends Message3 in Step S411. As a result, 4-Way Handshake has failed between the two devices.

  In addition, an example in which the authenticator that supports only encrypted Message 4 and the Supplicant that transmits Message 4 in plain text fails in 4-way handshake will be described using the sequence of FIG.

  Steps S501 to S507 are the same as S301 to S307 in FIG. However, since Supplicant has not started encryption after receiving Message3, plaintext Message4 is transmitted in step S509, and encryption is started in Authenticator. Therefore, Message3 is retransmitted in step S511 without understanding this. As a result, 4-Way Handshake has failed between the two devices.

  As described above, a communication device that encrypts and transmits Message4 and a communication device that does not support the received encrypted Message4 have a problem in interconnectivity because 4-way handshake ends in failure.

  In addition, communication devices that transmit Message4 in plaintext and communication devices that do not support received plaintext Message4 have had problems with interoperability because 4-way handshake failed.

  In a communication device that encrypts 4-Way Handshake Message 4 and transmits it, if Message 4 is rejected and Message 3 is retransmitted by the 4-Way Handshake partner device, Message 4 is sent in plain text and retried.

  Also, memorize the MAC address of the partner device and whether the device is compatible with encrypted Message4, and encrypt Message4 by referring to the information in the next and subsequent 4-Way Handshake. Select whether or not to do.

  Also, if Message3 is retransmitted from the other device after sending Message4, it is determined whether this is because the message4 was not supported by the encrypted Message4 or the message4 did not reach the other device. Therefore, the interconnectivity is further improved by determining the radio wave intensity as a threshold value.

  In a communication device that transmits 4-Way Handshake Message 4 in plain text, if Message 4 is rejected and Message 3 is retransmitted by a 4-Way Handshake partner device, Message 4 is encrypted and retried.

  Also, memorize the MAC address of the partner device and whether the device is compatible with plain text Message4, and refer to the information in the next and subsequent 4-Way Handshake to encrypt Message4. Choose whether or not.

  In addition, when Message3 is retransmitted from the other device after sending Message4, to determine whether this is because the message4 is not compatible with plaintext Message4 or because the Message4 did not reach the other device. The interoperability is further improved by determining the radio wave intensity as a threshold value.

  4-Way Handshake interoperability is improved.

(First embodiment)
Embodiment 1 of the present invention is shown in FIG. The Supplicant is, for example, a PC or PDA with a WLAN card inserted, or a digital camera or printer having a WLAN function. On the other hand, the authenticator is, for example, an AP (Access Point).

  In this embodiment, the basic operation of the Supplicant is to encrypt and transmit Message 4 of 4-way handshake. In addition, it is assumed that the Authenticator supports only the 4-way handshake Message4 that is not encrypted.

  Hereinafter, description will be given along the sequence of FIG.

  First, it is assumed that the Supplicant and the Authenticator have the same PMK (Pairwise Master Key) according to the previous procedure not described.

  In step S101, the supplicant generates a random number called SNonce.

  In step S102, the authenticator generates a random number called ANonce, and in step S103, sends Message1 including ANonce to the supplicant. Note that step S101 is not a problem even after step S103.

  In step S104, the supplicant derives the PTK using the PMK and SNonce that the supplicant has and the received ANonce. In step S105, the supplicant transmits Message2 including SNonce to the authenticator.

  In step S106, the authenticator derives the PTK using its own PMK, ANonce, and received SNonce. Therefore, the PTK derived by the Supplicant and Authenticator is the same.

  In step S107, the authenticator transmits Message3 including ANonce to the supplicant.

  In step S108, the supplicant starts encryption, and transmits Message4 encrypted in step S109 to the authenticator.

  However, in step S110, since the encrypted Message4 received by the authenticator cannot be understood, Message3 is retransmitted in step S111.

  Here, when the supplicant detects that the retransmission of Message3 has been received, the supplicant temporarily cancels the encryption in step S112, and transmits Message4 ′ in plain text in step S113.

  The authenticator receives the message 4 ′, understands it, and proceeds to step S114.

  In step S114, the authenticator starts encryption, and in step S115, the supplicant starts encryption.

  By performing Message4 encryption control as described above, 4-Way Handshake with Authenticator that supports only Message4 not encrypted can be successful.

(Second Embodiment)
A second embodiment of the present invention is shown in FIG. The Supplicant is, for example, a PC or PDA with a WLAN card inserted, or a digital camera or printer having a WLAN function. On the other hand, the authenticator is, for example, an AP (Access Point).

  In this embodiment, the basic operation of the Supplicant is to send Message 4 of 4-Way Handshake in plain text. In addition, it is assumed that the Authenticator supports only the encrypted 4-way Handshake Message4.

  Hereinafter, description will be given along the sequence of FIG.

  First, it is assumed that the Supplicant and the Authenticator have the same PMK (Pairwise Master Key) according to the previous procedure not described.

  In step S201, the supplicant generates a random number called SNonce.

  In step S202, the authenticator generates a random number called ANonce, and in step S203, transmits Message1 including ANonce to the supplicant. Note that step S201 is not a problem even after step S203.

  In step S204, the supplicant derives a PTK using the PMK and SNonce that the supplicant has and the received ANonce. In step S205, the supplicant transmits Message2 including SNonce to the authenticator.

  In step S206, the authenticator derives a PTK using its own PMK, ANonce, and the received SNonce. Therefore, the PTK derived by the Supplicant and Authenticator is the same.

  In step S207, the authenticator transmits Message3 including ANonce to the supplicant, and starts encryption in step S208.

  The Supplicant that has received Message 3 transmits plain text Message 4 to the authenticator in step S209.

  However, since plaintext Message4 received by the authenticator cannot be understood in step S210, Message3 is retransmitted in step S211.

  Here, when the supplicant detects that the retransmission of Message3 has been received, encryption starts in step S212, and encrypted Message4 ′ is transmitted in step S213.

  The authenticator receives the message 4 ′, understands this, and succeeds in 4-way handshake.

  By performing Message4 encryption control as described above, 4-Way Handshake with an Authenticator that only supports Message4 encrypted can be successful.

(Third embodiment)
In the first embodiment, a method has been described in which plaintext Message4 ′ is transmitted to an authenticator that supports only plaintext Message4 when encrypted message4 is rejected by the supplicant.

  Also, in the second embodiment, a method has been described in which an encrypted Message4 ′ is transmitted to an authenticator that supports only encrypted Message4 when plaintext Message4 is rejected by the Supplicant.

  In the third embodiment, a method for performing more efficient operation by adding means for storing information of the authenticator to the above two embodiments will be described.

  In Example 1 or Example 2, when 4-Way Handshake is successful, the authenticator associates information X (i) indicating whether plaintext Message4 was accepted or encrypted Message4 was accepted, and MAC address Y (i) of the authenticator Store in the storage device Z.

  Next, when 4-Way Handshake is performed, it is confirmed whether or not the storage device Z has the MAC address of the authenticator that is currently performing the 4-Way Handshake.

  When the corresponding MAC address is found in the storage device Z, the information X (j) is referred to from the MAC address Y (j). As a result of the reference, the authenticator recognizes whether it is compatible with plain text Message4 or encrypted Message4. And when actually sending Message 4 of 4-Way Handshake, it is sent in a supported format (encrypted or plain text).

  By performing the control as described above, it is possible to prevent the Authenticator that once performed 4-Way Handshake from failing due to Message4 encryption inconsistency, so 4-Way Handshake can be implemented more efficiently. .

Proposed interconnectivity improvement method 1 Proposed interconnectivity improvement method 2 4-Way Handshake sequence Failure example 1 due to Message4 inconsistency Failure example 2 due to Message4 inconsistency

Claims (4)

In a communication device that encrypts 4-Way Handshake Message4 and sends it,
A method for improving interoperability, characterized in that when Message 4 is rejected and Message 3 is retransmitted by a 4-Way Handshake partner device, Message 4 is rewritten as plain text. In the interconnectivity improvement method of Claim 1,
Whether to memorize the MAC address of the partner device and whether the device is compatible with encrypted Message4, and refer to the information in the next and subsequent 4-Way Handshake to encrypt Message4 A method for improving interoperability, characterized by selecting whether or not. In a communication device that sends 4-Way Handshake Message4 in plain text,
A method for improving interoperability, comprising: encrypting Message4 and retrying when Message4 is rejected and Message3 is retransmitted by a partner device of 4-Way Handshake. In the interconnectivity improvement method of Claim 4,
Stores the MAC address of the partner device and whether or not the device is compatible with plain text Message4, and whether to encrypt Message4 by referring to the information in the next and subsequent 4-way handshake A method for improving interconnectivity, characterized in that:

Images