Broadcast Management Frame Protection Month Year doc.: IEEE 802.11-yy/xxxxr0 September 2005 Broadcast Management Frame Protection Date: November 14, 2005 Authors: Notice: This document has been prepared to assist IEEE 802.11. It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein. Release: The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution, and any modifications thereof, in the creation of an IEEE Standards publication; to copyright in the IEEE’s name any IEEE Standards publication even though it may include portions of this contribution; and at the IEEE’s sole discretion to permit others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and accepts that this contribution may be made public by IEEE 802.11. Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures <http:// ieee802.org/guides/bylaws/sb-bylaws.pdf>, including the statement "IEEE standards may include the known use of patent(s), including patent applications, provided the IEEE receives assurance from the patent holder or applicant with respect to patents essential for compliance with both mandatory and optional portions of the standard." Early disclosure to the Working Group of patent information that might be relevant to the standard is essential to reduce the possibility for delays in the development process and increase the likelihood that the draft publication will be approved for publication. Please notify the Chair <stuart.kerry@philips.com> as early as possible, in written or electronic form, if patented technology (or technology under patent application) might be incorporated into a draft standard being developed within the IEEE 802.11 Working Group. If you have questions, contact the IEEE Patent Committee Administrator at <patcom@ieee.org>. S. Bezzateev, A. Fomin, M. Wong John Doe, Some Company

Broadcast Forgery Protection September 2005 Broadcast Forgery Protection Broadcast forgery protection in 802.11i Frame sequence number and message integrity code protected by GTK Disadvantages Nodes can not identify real source of the broadcast frame Nodes only can detect that frame came within the group Mgmt frames are more important for functioning of the network => stronger protection should be used Scheme should be flexible to extend beyond current set of broadcast management frames S. Bezzateev, A. Fomin, M. Wong

M  M || j || Kj–1 || MIC(Kj, j || Kj–1 || M) Month Year doc.: IEEE 802.11-yy/xxxxr0 September 2005 TESLA Keys Kj-1=H(Kj) K0 – public key K0 Kj-1 Kj t 1 j-1 j Broadcast source sends M  M || j || Kj–1 || MIC(Kj, j || Kj–1 || M) for all messages during period j Broadcast destinations Cache all the frames received during period j Verify that Kj–2=H(Kj-1) Use Kj–1 to validate the MICs of all frames received during the previous period j–1 S. Bezzateev, A. Fomin, M. Wong John Doe, Some Company

Modification of TESLA One-hop Broadcast Protection (1) Month Year doc.: IEEE 802.11-yy/xxxxr0 September 2005 Modification of TESLA One-hop Broadcast Protection (1) All broadcast sinks receive message into the same time No delay is needed => We can put the key into the same packet Broadcast source sends where j – frame sequence number Broadcast sinks Verify that Kj–1=H(Kj) Use Kj to validate the MIC K0 can be initialized to GTK, or IGTK (IGTK is proposed by BUMP) When initialized to IGTK, it can be updated whenever IGTK gets updated M  M || j || Kj || MIC(Kj, j || Kj || M) S. Bezzateev, A. Fomin, M. Wong John Doe, Some Company

Modification of TESLA One-hop Broadcast Protection (2) Month Year doc.: IEEE 802.11-yy/xxxxr0 September 2005 Modification of TESLA One-hop Broadcast Protection (2) Add GTK to exclude external attackers M  M || Enc(GTK, j || Kj || MIC(Kj, j || Kj || M)) Attack is still possible but only from inside attacker, who knows GTK Attack is made much more difficult to carry out and can be easily detected by neighboring nodes S. Bezzateev, A. Fomin, M. Wong John Doe, Some Company

Possible Attack September 2005 Month Year doc.: IEEE 802.11-yy/xxxxr0 GTK Our approach Attack time and fake information propagation Attacker could broadcast fake information on behalf of another node in any moment just after receiving appropriate GTK key. This fake information will be accepted by all nodes. Attacker could broadcast fake packet only instead of the packet of the legal node. This fake packet will be accepted only by nodes who did not receive the original packet of the legal node. Attack scenario Attacker only needs one legal device without special equipments. As the attack could be launched only to nodes who did not receive the original packet of the legal node, attacker should prevent receiving of the original packet by some nodes, but in the same moment receive the original packet herself. It is possible only if Attacker uses directed antenna for noising the channel to prevent receiving the original packet by some nodes Attacker uses two devices. The first device is used to receive the original packet and the second device is used for noising the channel to prevent receiving the original packet by some nodes. S. Bezzateev, A. Fomin, M. Wong John Doe, Some Company

Possible Attack September 2005 Month Year doc.: IEEE 802.11-yy/xxxxr0 detection This attack could be detected only by the node on behalf of which the attacker sent the fake packet. However attacker could easily avoid this situation. Attack could be detected by the nodes which receive as the original packet as the fake packet. Attacker 1 is noising the channel during the original packet transmission. Attacker 2 receives the original packet and transmits the fake packet after that. S. Bezzateev, A. Fomin, M. Wong John Doe, Some Company

Multi Hop Broadcast Protection Month Year doc.: IEEE 802.11-yy/xxxxr0 September 2005 Multi Hop Broadcast Protection Re-encryption/re-signing on each hop for mesh application Hop-by-hop protection proposed by SEE-Mesh alliance in 802.11s Alliance members include Samsung, Intel, Cisco, Nokia, TI, Enc(GTKu, M || j || Kju || MIC(Kju, j || Kju || M)) Enc(GTKv, M || i || Kiv || MIC(Kiv, i || Kiv || M)) Node U Node V Node W K0U,GTKu K0V,GTKv … K0V,GTKv K0U,GTKu K0W,GTKw … K0W,GTKw K0V,GTKv … S. Bezzateev, A. Fomin, M. Wong John Doe, Some Company

M  M || Enc(GTK, j || Kj || MIC(Kj, j || Kj || M)) Month Year doc.: IEEE 802.11-yy/xxxxr0 September 2005 Summarize One hop broadcast Without message encryption (e.g. beacon) M  M || Enc(GTK, j || Kj || MIC(Kj, j || Kj || M)) With message encryption M  Enc(GTK, M || j || Kj || MIC(Kj, j || Kj || M)) Multi hop broadcast Re-encryption and re-signing on each hop S. Bezzateev, A. Fomin, M. Wong John Doe, Some Company