AUSTRALIA Patent Act COMPLETE SPECIFICATION INNOVATION PATENT SECURED KEY EXCHANGE IN WiFi NETWORKS USING QUANTUM KEY DISTRIBUTION The following statement is a full description of this invention, including the best method of performing it known to us.
[000t] WiFi wireless local area networks, which are based on IEEE 802.11 standard, are popular and widely used in places like coffee shops, air ports, conference halls, libraries etc. However, since there are no boundaries in wireless networks, they are vulnerable to security threats than wired networks. Therefore, providing secure communication for WiFi networks has become one of the prime concerns. [0002] Traditional way to protect WiFi is offered by virtual private network (VPN) over the existing public Internet. However, there are many reports about the attacks on VPNs, which shows that it is necessary to seek more secure technology to protect WiFi. [0003] In order to encrypt data exchanged between the two users (better known as Authenticator and Supplicant), a unique secrete key has to be used at either ends. In the present IEEE 802.11i standard, this key is exchanged via a process called 4-Way Handshake. Though this process rectified several security flaws that previous technology had, it is still subject to security attacks. On the other hand, users could benefit from any design that offers improved security. [0004] Based on the laws of physics, quantum cryptography allows the exchange of cryptographic key between two parties with unconditional security. Quantum Key Distribution (QKD) that associated with quantum cryptography is an area that has never been employed in wireless networks so far. QKD comprise of 4 main phases, namely: Sifting, Error Estimation, Reconciliatiori and Privacy Amplification. [0005] In this invention, a novel method of using QKD in WiFi networks for key exchange is used. Conceptual classic and quantum communication channels are proposed and defined. The key exchange process of existing IEEE 802.11 i has been modified with QKD to achieve secure key distribution which will ultimately used to encrypt data communication. [ooo6] The IEEE 802.11i consists of a defined key hierarchy as shown in Figure 1, which is used for subsequent data encryption to achieve secure communication. This key hierarchy consists of Pairwise Master Key (PMK), Pairwise Transient Key (PTK), EAPOL-key confirmation key (KCK), EAPOL-key encryption key (KEK) and Temporal Key (TK). The aim of this design is to obtain the same key hierarchy through QKD, which has never been done before.
2 [0007] Since this implementation is mainly done via software development, communication flow diagrams are used to explain the process wherever possible. There are three main participants in the 802.11 i key exchange process. [o008] The user or the client that wants to be authenticated is known as Supplicant or Station. The actual server doing the authentication is called Authentication Server. The Authenticator or the Access Point allows only the supplicants who are authorised by the authentication server to gain access to the network. [0009] Figure 2 shows the existing IEEE 802.11i Authentication and Key Establishment process. This communication flow continues as usual between the Authenticator and the Supplicant with 802.11 Association and 802.1X Authentication until the completion of Extensible Authentication Protocol (EAP) key exchange (flow 13 of Figure 2). At the end of the IEEE 802.1X authentication, both the supplicant and the authenticator hold PMK. A special emphasis has been given to the EAP types such as EAP-TLS, EAP-TTLS which offer mutual authentication. Since the two parties are mutually authenticated at this stage, the message authenticity is preserved. [ooio] From this point onwards the QKD based key distribution in WiFi (the invention) commences (Flows 3 to 6 of Figure 4). [oo1] As this point, the wireless transmission switches over from Wireless Channel to Quantum Channel (Figure 3 shows the high level view of the two channels). Supplicant sends series of polarised photons towards the Authenticator. Authenticator keeps track of all the photons that it received along with the bases it used to measure the photons. [0012] As soon as the photon transmission finishes, the Wireless Channel (WiFi) resumes for the rest of the protocol execution. [0013] In order to obtain the final key, the 4 phases of QKD is implemented in WiFi communication. All these changes to the IEEE 802.11i protocol are done in Physical (PHY) and medium access control (MAC) layers of the OSI model. Some of the existing fields of the packets have been changed to accommodate necessary parameters to obtain the IEEE 802.11 i key hierarchy.
[0014] Figure 5 shows the EAPOL-Key frame with changes made in order to implement QKD. [0015] The fifth field of this EAPOL-Key frame (figure 5) is used to indicate which phase of the QKD process is in progress. In this invention this particular octet as called as "QKD Phase". In IEEE 802.11i, this field is known as "Key Nonce". Possible values of "QKD Phase": - 0000 0001 : Send/Receive bases. Used to indicate when the Supplicant is sending the bases used during the quantum transmission. Both Supplicant and Authenticator set this bit during the exchange of bases. - 0000 0011 : Error estimation. Used to indicate that the EAPOL frame contains set of sample bits for comparison to estimate the errors introduced during the quantum transmission. The "data" field of this frame contains "start bit position" and the respective bits being compared. - 0000 0101 : Reconciliation. Used to indicate the reconciliation phase of QKD is in progress. - 0000 0111 : Privacy Amplification. [oo16] "Key Data" field (of figure 5) will carry parity check information during reconciliation phase (QKD Phase = 0000 0101). During the reconciliation, the raw key is divided into several blocks to perform parity checks. The QKD Phase field is set to 0000 0101. Format of Data field: <Block Number I Sub-Block Level I Parity Check Results>,<>,.... Where: Block Number: Number of the main block. Sub-block Level: If the main block parity check failed, that block will be bisect and perform the parity check again. The "Sub-block Level" field specifies the level of bisection of each main block. If the main block is bisected once, Sub-block Level =2 and so on. Sub-block Partition Number: Whenever a mismatch in parity of block/Sub-block is observed, that particular block/Sub-block is bisected. This Sub-block Partition Number field holds the Sub-block partition number of each of the sub blocks.
4 Parity Check Result: This field holds the results of parity checks of each of the sub blocks. 0: parity result = odd 1: parity result = even [0017] Figure 6 shows the allocation of bytes within the Key Data field. [0018] Figure 7 shows the changes done to "Key Information" field (of figure 5). * New field is known as "Quantum Transmission Re-attempt" (formerly "Key Type" in IEEE 802.11i standard) 0: Default value 1 Restart quantum transmission * "Key Ack" : This bit is set if a response is expected to the message being sent and clear otherwise. e New field is known as "Error Estimation Result" (formerly "Install" in IEEE 802.11 i standard) 0: Error estimation Failure 1 Error estimation Success [0019] The Sifting process (flow 3 of figure 4) removes all the bits which are recorded against incorrect bases used by the Authenticator. During this phase, the "QKD Phase" value is set to 0000 0001 as described in Figure 5. Once this value is set as such, the "Key Data" filed (of Figure 5) carries the bases used by the Supplicant. Once this information is received to Authenticator, it keeps the bits that match the bases it used while discarding the other bits. [0020] The Error Estimation process (flow 4 of figure 4) determines the amount of errors introduced during the transmission. During this phase, the Supplicant chooses a random sample of set of bits from its key to be used for error estimation. It then set the "QKD Phase" to 0000 0011 as shown in Figure 5. It also populates the "Key Data" filed (of Figure 5) to carry the start bit position and the respective bits that chosen for error estimation. At the same time, Supplicant removes those bits revealed from its key. Once this packet is received to Authenticator, it compares that same set of bits in its key and calculates the error. If this error level in within the threshold level (which can be configured in their systems), they moves on to the next stage. Authenticator informs the result of the error estimation to Supplicant with "QKD Phase" still set to 0000 0011 and the "Error Estimation Result" filed holding the result.
[0021] During the next process called Reconciliation (flow 5 of figure 4), the two parties removes all errors that introduced during the transmission. The method of operation of reconciliation protocol is described below. [0022] Both Authenticator and Supplicant partition their keys into blocks of equal length as previously agreed. During the first message containing reconciliation information, the Supplicant constructs the EAPOL frame by populating "block number, Sub-Block Level, Sub-block partition number, parity result of that block" (figure 6) for each of the blocks of the key. When the key is partitioned for the first time, "Sub-Block Level" field is 1. Supplicant calculates the parity of each of the blocks and populates the "Parity Check Result" along with the respective block/Sub-block position of each of the block in the EAPOL frame. The Supplicant then sends the EAPOL frame to the Authenticator. Authenticator in turn compares the parity results of each block. If a parity mismatch is found, the respective block is bisected and the parity is calculated for the new sub blocks. These parity checks are populated in the respective "Parity Check Result" fields. The Authenticator the construct the respective EAPOL message and sends to the Supplicant. This process continues until there are no more parity mismatches is found. Figure 8 and 9 shows how each field of this protocol is constructed using the reconciliation algorithm. [0023] For an example, consider block number "B" of the raw key as shown in Figure 9. Let's take this Block B = 6 (i.e. 6 th block of the partitioned key). Assume the parity check of this block resulted in odd parity (0). The corresponding filed carrying the block information in the EAPOL frame is represented by: [6,1,1,0], Where Block No 6, Sub-Block level = 1, Sub-Block partition no = 1, Parity check result = 0. In the EAPOL frame, this information in the "Key Data" field will populate as: [0000 0110 |0000 0001 | 0000 00110] Once this information reached the Authenticator, it compares its respective block data against the ones just received. Assume this block produces even parity at the Authenticator. However, the parity check of the same block in the Supplicant had produced odd parity. Hence the Authenticator seems the parity mismatch and bisects the block B (B 1 and B 2 ) and calculates the parities of the 2 sub blocks. Assume the parity results of B 1 = 1 and B 2 = 1. Thus the respective block (and sub block) data of the "Key Data" of EAPOL frame will represent as: [0000 1010 |0000 0001 10000 00110] [0000 1010 10000 0001 10000 010111 6 Once this frame reaches the Supplicant, it finds out from the increment in Sub-block shows a parity mismatch and locates which sub-block partitions are in error. It bisects the corresponding sub block and compares the parity. In this case, a mismatch occurs in sub-block B2, hence it bisects it into B21 and B2-2. The parity of these two sub blocks are calculated and respective EAPOL frame is sent to the Authenticator. This process continues for all the blocks of the raw key. [0024] In the final process (flow 6 of figure 4), known as Privacy Amplification, they eliminate some bits by applying a hash function just to eliminate the risk of any known bits to possible eavesdroppers. [0025] At the end of this process, both Supplicant and Authenticator hold a unique common key which is unconditionally secure in term of quantum cryptography. In this invention, this key is called as Quantum Key (Q-Key). [0026] Due to the errors introduced during the quantum transmission, the length of the final key cannot be known in advance. This means the final key derived after the QKD process will be of varying length. It is essential that lengths of both Q-Key and PTK are equal. [0027] To achieve this, the quantum transmission should ensure to send sufficient number of photons (in Quantum Channel) in order to recover Q-Key at least equal or greater than the PMK. For Counter-mode/CBC-MAC Protocol (CCMP), PTK is 256 bits, while Temporal Key Integrity Protocol (TKIP) occupies 384 bits for PMK. Therefore, at this stage, any extra bits of Q-Key will be trimmed so that it will have same length as PTK. This stripped Q-Key is treated as the PTK. [0028] Once PTK is available, the key hierarchy can be retrieved as shown in Figure 1. From PTK, KEK, KCK and TK can be derived. While from KCK, Message Integrity Code (MIC) can be calculated. This MIC is used in the subsequent protocol messages to implement mutual authentication. [0029] At this stage, Supplicant performs XOR operation with the MIC and the first set of bits of equal length in PMK. In this invention, the resulted MIC called as Quantum MIC (Q-MIC). [0030] Q-MIC = (MIC) XOR (first bits of PMK equivalent to the length of MIC) [0031] Supplicant then sends Q-MIC to Authenticator as shown in flow 7 of Figure 4. Upon receiving Q-MIC, Authenticator verifies the Q-MIC. Since the Authenticator is in possession of all the key hierarchy, it can calculate its own Q-MIC and compares with the one came from the Supplicant. If they match, the Supplicant is authenticated. [0032] Authenticator then sends Success message along with Q-MIC to Supplicant as shown in flow 8 of Figure 4. Supplicant verifies the Q-MIC to authenticate the Authenticator, thus achieving the mutual authentication. From now on, both parties use TK to encrypt the data and start secure communication and also use the Group Temporal Key (GTK) for multicast applications if needed. [0033] The QKD based WiFi design ends at this point. The rest of the IEEE 802.111 communication process continues from here onwards without any changes.