1. doc.: IEEE 802.11-02/318r0 Submission May 2002 Martin Lefkowitz, Texas InstrumentsSlide 1 Implicit Initialization Vectors Martin Lefkowitz, Texas Instruments

2. doc.: IEEE 802.11-02/318r0 Submission May 2002 Martin Lefkowitz, Texas InstrumentsSlide 2 Presentation Overivew History of the IV in an 802.11 packet Application of the IV in future implementations Issues involved in Changing the IV, or format of a packet. Optimization of 48 bit IV Extension

3. doc.: IEEE 802.11-02/318r0 Submission May 2002 Martin Lefkowitz, Texas InstrumentsSlide 3 1999 WEP Properties 8.2.2 Properties of the WEP algorithm –It is reasonably strong: The security afforded by the algorithm relies on the difficulty of discovering the secret key through a brute-force attack. This in turn is related to the length of the secret key and the frequency of changing keys. WEP allows for the changing of the key (k) and frequent changing of the IV. Hah! –It is self-synchronizing: WEP is self-synchronizing for each message. This property is critical for a data-link level encryption algorithm, where “best effort” delivery is assumed and packet loss rates may be high.. –It is efficient: The WEP algorithm is efficient and may be implemented in either hardware or software.

4. doc.: IEEE 802.11-02/318r0 Submission May 2002 Martin Lefkowitz, Texas InstrumentsSlide 4 1999 WEP Properties — It may be exportable: Every effort has been made to design the WEP system operation so as to maximize the chances of approval, by the U.S. Department of Commerce, of export from the U.S. of products containing a WEP implementation. However, due to the legal and political climate toward cryptography at the time of publication, no guarantee can be made that any specific IEEE 802.11 implementations that use WEP will be exportable from the USA. — It is optional: The implementation and use of WEP is an IEEE 802.11 option.

5. doc.: IEEE 802.11-02/318r0 Submission May 2002 Martin Lefkowitz, Texas InstrumentsSlide 5 History of IV in packet (WEP) 8.2.3 WEP theory of operation –The IV may be changed as frequently as every MPDU and, since it travels with the message, the receiver will always be able to decipher any message. The IV is transmitted in the clear since it does not provide an attacker with any information about the secret key, and since its value must be known by the recipient in order to perform the decryption.

6. doc.: IEEE 802.11-02/318r0 Submission May 2002 Martin Lefkowitz, Texas InstrumentsSlide 6 IV Problems Described in 1999 8.2.3 WEP theory of operation –When choosing how often to change IV values, implementors should consider that the contents of some fields in higher-layer protocol headers, as well as certain other higher-layer information, is constant or highly predictable. When such information is transmitted while encrypting with a particular key and IV, an eavesdropper can readily determine portions of the key sequence generated by that (key, IV) pair. If the same (key, IV) pair is used for successive MPDUs, this effect may substantially reduce the degree of privacy conferred by the WEP algorithm, allowing an eavesdropper to recover a subset of the user data without any knowledge of the secret key. Changing the IV after each MPDU is a simple method of preserving the effectiveness of WEP in this situation.

7. doc.: IEEE 802.11-02/318r0 Submission May 2002 Martin Lefkowitz, Texas InstrumentsSlide 7 Application of IV for Future Implementations While there is no properties section in the current draft, in general, the WEP properties (goals) are valid for future forms of encryption. –It is reasonably strong This is a moving target. –It is self-synchronizing This is now true not only for packet loss, but for the QOS property of packets coming out of order. –It is efficient While it is an advantage to be able to do this in software, even Hardware implementations, and the protocol can benefit from efficiency. –Efficiency = performance. –It may be exportable No longer an issue –It is optional

8. doc.: IEEE 802.11-02/318r0 Submission May 2002 Martin Lefkowitz, Texas InstrumentsSlide 8 Solution to IV Issues Enforce IV change for every packet –Introduce sequential count Enforce that IV never be reused with the same key. –Three possible solutions: Rapid Rekeying: Change Key before IV runs out. Extend the IV: 48 bit Both

9. doc.: IEEE 802.11-02/318r0 Submission May 2002 Martin Lefkowitz, Texas InstrumentsSlide 9 Issues With Rapid Rekey Disadvantage –Making sure Queues are flushed when packets can come out of order, and may be stalled makes it hard to know when exactly to change over. Very complicated. Hard to get right. Advantage –Key changing happens automatically The user/IT administrator need not know exactly when the key changes

10. doc.: IEEE 802.11-02/318r0 Submission May 2002 Martin Lefkowitz, Texas InstrumentsSlide 10 Need for Rekeying At the given rates the a single key can last > 100 years there is no reason to rekey, other than human issues. –The longer a key is used the longer someone may find it through other means than cracking –Disgruntled Employee. Group Key Rekey –Too many people may have the means to decode the key, therefore it would be a good idea to rekey eariler

11. doc.: IEEE 802.11-02/318r0 Submission May 2002 Martin Lefkowitz, Texas InstrumentsSlide 11 48 Bit IV Expansion Issues Adding 4 more bytes to the packet –Certain legacy hardware implementations take advantage of the frame format, and require the IV to be in that place, for TKIP. This can be overcome by reordering the IV fields to make keymixing more streamlined. More Overhead for packet. –Regardless of size, we are adding 40,000 extra bytes per 10,000 packet. Depending upon the size of the packet this decreases throughput from.02-6 %

12. doc.: IEEE 802.11-02/318r0 Submission May 2002 Martin Lefkowitz, Texas InstrumentsSlide 12 Issues with Both 48bit IV and Rekeying Can be the worst or best of both solutions. –We could be having the complication of rapid rekeying, as well as adding 4 bytes to each packet. –We could use 48 bits to simplify, or eliminate the need for rekeying. This must be done for all cases, or we get the worst of both solutions.

13. doc.: IEEE 802.11-02/318r0 Submission May 2002 Martin Lefkowitz, Texas InstrumentsSlide 13 Issues With Extending/Changing the IV Format Interoperability with Legacy Stations –These Stations will be using TKIP, not WEP. Existing Hardware can be made to conform to a stronger encryption scheme. –Uses the same general frame format. –Enforces a count in the IV. –Mixed Network with OCB. OCB is new Hardware, but uses the same general frame format.

14. doc.: IEEE 802.11-02/318r0 Submission May 2002 Martin Lefkowitz, Texas InstrumentsSlide 14 Advantage of 48 Bit IV More Secure (Obviously) Makes Rekeying Easier –No need to worry about Key Exhaustion if a STA always begins to use the newest key. Send Pong key over when a key change needs to occur. There is no need to reuse the ping key. A queue flush must occur during the life of the session. –There is a MSDU lifetime usually set to about ½ second.

15. doc.: IEEE 802.11-02/318r0 Submission May 2002 Martin Lefkowitz, Texas InstrumentsSlide 15 WEP TKIP AES/OCB

16. doc.: IEEE 802.11-02/318r0 Submission May 2002 Martin Lefkowitz, Texas InstrumentsSlide 16 Optimization of 48 bit IV Extension Use 1 IV padding bit as a “Edge Sensitive” toggle when overflow occurs during the counting of the IV. –TKIP example –Key must start at zero –And So on… IV Lower Count (hex)Implicit Upper Count 00000 – 0FFFF0 10000 – 1FFFF1 20000-2FFFF0

17. doc.: IEEE 802.11-02/318r0 Submission May 2002 Martin Lefkowitz, Texas InstrumentsSlide 17 Optimization of 48 bit IV Extension (continued) Incrementing the upper count. –The upper count can not be “officially” incremented until after the replay window expires from the packet that contained the last pre-rollover count. For the OCB mode since each Traffic Class has a different IV space this is not an issue.

18. doc.: IEEE 802.11-02/318r0 Submission May 2002 Martin Lefkowitz, Texas InstrumentsSlide 18 Implicit IV Group Key Solution Beacon/Probe Response contains the current upper, and lower IV count –Unambiguous for powersave –IBSS STA can get initialized. –Lower IV count sent to avoid race condition Association Response contains current upper, and lower IV count for initialization for infrastucture situation.

19. doc.: IEEE 802.11-02/318r0 Submission May 2002 Martin Lefkowitz, Texas InstrumentsSlide 19 Why Implicit Upper IV works It is self-synchronizing: –With each packet, and the maintance of the upper IV in the it’s memory, the STA has the ability to unambiguously determine the IV for that packet. Works with dropped packets, or out of order packet Unambiguous –You can not miss 655536 packets and still care about whether you are associated, or receiving correct data. If you do you should be able the overhead of reassociating.

20. doc.: IEEE 802.11-02/318r0 Submission May 2002 Martin Lefkowitz, Texas InstrumentsSlide 20 Why Impicit Upper IV is Better We can use a 16 counter for AES/OCB reduces the amount of overhead required for the IV in AES/OCB mode. –Either eliminate 14 bits, or have 14 bits of padding/other information. We can use 48 bit IV space for TKIP without transmitting an extra 4 bytes per packet.

21. doc.: IEEE 802.11-02/318r0 Submission May 2002 Martin Lefkowitz, Texas InstrumentsSlide 21 Conclusion Having a 48 bit IV does simplify Rekeying. Designing in the implicit Upper IV does not decrease the over the air performance. Best of both worlds