Doc.: IEEE 802.11-02/318r0 Submission May 2002 Martin Lefkowitz, Texas InstrumentsSlide 1 Implicit...

May 2002

Martin Lefkowitz, Texas Instruments

Slide 1

doc.: IEEE 802.11-02/318r0

Submission

Implicit Initialization Vectors

Martin Lefkowitz,

Texas Instruments

May 2002


Slide 2

doc.: IEEE 802.11-02/318r0

Submission

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

May 2002


Slide 3

doc.: IEEE 802.11-02/318r0

Submission

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.

May 2002


Slide 4

doc.: IEEE 802.11-02/318r0

Submission

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.

May 2002


Slide 5

doc.: IEEE 802.11-02/318r0

Submission

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.

May 2002


Slide 6

doc.: IEEE 802.11-02/318r0

Submission

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.

May 2002


Slide 7

doc.: IEEE 802.11-02/318r0

Submission

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

May 2002


Slide 8

doc.: IEEE 802.11-02/318r0

Submission

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

May 2002


Slide 9

doc.: IEEE 802.11-02/318r0

Submission

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

May 2002


Slide 10

doc.: IEEE 802.11-02/318r0

Submission

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

May 2002


Slide 11

doc.: IEEE 802.11-02/318r0

Submission

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 %

May 2002


Slide 12

doc.: IEEE 802.11-02/318r0

Submission

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.

May 2002


Slide 13

doc.: IEEE 802.11-02/318r0

Submission

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.

May 2002


Slide 14

doc.: IEEE 802.11-02/318r0

Submission

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.

May 2002


Slide 15

doc.: IEEE 802.11-02/318r0

Submission

WEP

TKIP

AES/OCB

May 2002


Slide 16

doc.: IEEE 802.11-02/318r0

Submission

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 – 0FFFF 0

10000 – 1FFFF 1

20000-2FFFF 0

May 2002


Slide 17

doc.: IEEE 802.11-02/318r0

Submission

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.

May 2002


Slide 18

doc.: IEEE 802.11-02/318r0

Submission

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.

May 2002


Slide 19

doc.: IEEE 802.11-02/318r0

Submission

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.

May 2002


Slide 20

doc.: IEEE 802.11-02/318r0

Submission

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.

May 2002


Slide 21

doc.: IEEE 802.11-02/318r0

Submission

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

Doc.: IEEE 802.11-02/318r0 Submission May 2002 Martin Lefkowitz, Texas InstrumentsSlide 1 Implicit...

Documents

Transcript of Doc.: IEEE 802.11-02/318r0 Submission May 2002 Martin Lefkowitz, Texas InstrumentsSlide 1 Implicit...