1. Broadcast Management Frame Protection
Month Year
doc.: IEEE yy/xxxxr0
September 2005
Broadcast Management Frame Protection
Date: November 14, 2005
Authors:
Notice: This document has been prepared to assist IEEE 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
Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures < 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 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 Working Group. If you have questions, contact the IEEE Patent Committee Administrator at
S. Bezzateev, A. Fomin, M. Wong
John Doe, Some Company

2. Broadcast Forgery Protection
September 2005
Broadcast Forgery Protection
Broadcast forgery protection in i
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

3. M  M || j || Kj–1 || MIC(Kj, j || Kj–1 || M)
Month Year
doc.: IEEE yy/xxxxr0
September 2005
TESLA
Keys
Kj-1=H(Kj)
K0 – public key K0
Kj-1 Kj t 1
j 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

4. Modification of TESLA One-hop Broadcast Protection (1)
Month Year
doc.: IEEE 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

5. Modification of TESLA One-hop Broadcast Protection (2)
Month Year
doc.: IEEE 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

6. 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

7. 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

8. Multi Hop Broadcast Protection
Month Year
doc.: IEEE 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 s
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

9. M  M || Enc(GTK, j || Kj || MIC(Kj, j || Kj || M))
Month Year
doc.: IEEE 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