doc.: ieee 802.11-01/223 submission may 2001 nancy cam-winget, atheros et alslide 1 an analysis of...

May 2001

Nancy Cam-Winget, Atheros et al

Slide 1

doc.: IEEE 802.11-01/223

Submission

An Analysis of AES in OCB Mode

Nancy Cam-Winget, Atheros Communications

Jesse Walker, Intel Corporation

May 2001


Slide 2

doc.: IEEE 802.11-01/223

Submission

Acknowledgements

• Bill Arbaugh – U of Maryland

• Greg Chesson – Atheros Communications

• Phil Rogaway – UC Davis

• Aman Singla – Atheros Communications

May 2001


Slide 3

doc.: IEEE 802.11-01/223

Submission

Agenda

• Background• Discussion of AES• OCB mode• Security Considerations• Acceptance Considerations• Performance Considerations• True Integrity:Using OCB to fix a bug in the Draft• Summary

May 2001


Slide 4

doc.: IEEE 802.11-01/223

Submission

Review of WEP

• WEP attacks– IV can NEVER safely be reused with same key– RC4 unsuitable for 802.11 datagrams– CRC can be used to speed up dictionary attack

• The use of RC4 requires the key schedule to be reinitialized for every packet– Hurts performance– This property is what got WEP in trouble in the first place– RC4 is a fine cipher, but inappropriate as a bulk crypto

mechanism in a datagram environment

May 2001


Slide 5

doc.: IEEE 802.11-01/223

Submission

Concepts• Data privacy

– Protection of data. Prevent unauthorized viewing of the data

• Data integrity– Prevent modification, insertion or deletion of

data (collectively known as “forgery”)– Validation of data: MIC

• Data authenticity– Synonym for data integrity

May 2001


Slide 6

doc.: IEEE 802.11-01/223

Submission

Data (true) Integrity

• Beyond data integrity (no change in plaintext) it also means ensuring received data was actually sent by genuine peer on an established link– The link is immune from forgery

• This is a necessary attribute of any scheme seeking to control access

May 2001


Slide 7

doc.: IEEE 802.11-01/223

Submission

Security Framework Requirements defined in 802.11-00/231

• Clause 4 Extensibility, Compatibility, and Interoperability includes support for:– Authentication algorithm– Privacy algorithm– Data integrity algorithm

May 2001


Slide 8

doc.: IEEE 802.11-01/223

Submission

Why Per-Packet Data Integrity?

• Requirements say so– Ref: doc IEEE 802.11/231 clause 4.2.2

• More important, 802.11 security seeks to provide meaningful access control– Not feasible to control access unless all packets

on authenticated association are also validated– If no per-packet data integrity check, then

association authentication meaningless, i.e., forgery is always possible to an attacker

May 2001


Slide 9

doc.: IEEE 802.11-01/223

Submission

Security Requirements Discussion

• Data privacy– Goal: prevent inadvertent unauthorized

disclosure due to message transfer– Mechanism to achieve goal: encryption

• Data integrity – Goal: prevent data forgery, replay– Mechanism to achieve goal: Message Integrity

Code + sequence number + link protection

May 2001


Slide 10

doc.: IEEE 802.11-01/223

Submission

Security Mechanism Goals

• Meet security requirements

• Work with 802 authentication/key management infrastructure

• Implementation ease (and payload overhead)

• Good performance

May 2001


Slide 11

doc.: IEEE 802.11-01/223

Submission

Agenda


May 2001


Slide 12

doc.: IEEE 802.11-01/223

Submission

AES Cipher

• NIST selection criteria is similar to 802.11’s:– Security– Performance in both software and hardware– Efficiency – Ease of implementation

• NIST selection process took 4 years!– Initiated Jan 1997, decision finalized Feb 2001

May 2001


Slide 13

doc.: IEEE 802.11-01/223

Submission

AES properties

• Symmetric 128bit block cipher– NIST allows 128-, 192- and 256bit keys blocks – 802.11 proposes using 128-bit keys

• Low memory requirements• Good performance across all known hardware and

software platforms– Highly parallelizable– Compact source code– ~ 285 cycles/block on a Pentium Pro

May 2001


Slide 14

doc.: IEEE 802.11-01/223

Submission

AES Strengths (1)

• Exhaustive key search best known attack against AES—and large key size makes exhaustive search computationally infeasible– Key recovery operations O(2127 ) AES

operations on average

• 128-bit block size makes it orders of magnitude more secure than same algorithm with a 64-bit block size

May 2001


Slide 15

doc.: IEEE 802.11-01/223

Submission

AES Strengths (2)

• Performance– Highly parallelizable

– Compact implementations

– Efficient key schedule computation

• Platform neutrality– Efficient implementation possible on all platforms

• Critical path instructions: 8-bit8-bit S-box, XOR6, XOR5, XOR2, MUX2

– Endian-neutrality

May 2001


Slide 16

doc.: IEEE 802.11-01/223

Submission

Agenda


May 2001


Slide 17

doc.: IEEE 802.11-01/223

Submission

OCB mode of operation

• OCB mode is a block cipher mode of operation

• OCB provides authenticated-encryption: provides both privacy and authenticity– i.e. provides data authenticity at almost no extra

cost over the cost of encryption

May 2001


Slide 18

doc.: IEEE 802.11-01/223

Submission

Why Use a Mode of Operation?

• AES is a block cipher

• Networking produces arbitrary length messages to encipher/decipher

• Naïve use of any block cipher for arbitrary length messages (called Electronic Codebook, or ECB mode) is insecure

May 2001


Slide 19

doc.: IEEE 802.11-01/223

Submission

Example Modes of Operation

Partition message M into blocks

M = M1 M2 … Mm

• ECB Mode: Ci EK(Mi) (insecure if m > 1)• Counter Mode: Ci EK(counter) Mi, counter counter + 1 (secure if counter is never reused with same key K)

• CBC Mode: Ci EK(Ci-1 Mi), C0 EK(IV M0) (secure if IV is random and never reused with same key K)

May 2001


Slide 20

doc.: IEEE 802.11-01/223

Submission

Comparison of Modes

Mode Privacy Integrity CommentsECB Sometimes No Vulnerable to attack. Must

choose a MIC

Counter Yes No Vulnerable if counter is ever reused. Must choose a MIC

CBC Yes No Sound encryption. Must choose a MIC

CBC-MAC No Yes Recent attack on forgery (An, Bellare 1999)

OCB Yes Yes one key and one pass over data gives both privacy and integrity

May 2001


Slide 21

doc.: IEEE 802.11-01/223

Submission

OCB Properties

• Uses nearly the theoretical minimal number of block cipher calls required to accomplish both privacy and integrity: number of blocks + 1

• Smaller IV is sufficient • Single key used for both encryption and MIC• Key setup is minimal • Session state is minimized

May 2001


Slide 22

doc.: IEEE 802.11-01/223

Submission

Agenda


May 2001


Slide 23

doc.: IEEE 802.11-01/223

Submission

OCB Security Strength

• Proven privacy and proven integrity– encryption strength stronger than CBC mode – data integrity strength at least as good as CBC-MAC

• Just like security proofs for CBC and Counter mode and for CBC-MAC, OCB security proof is a reduction:

– If a computationally cheap algorithm exists to break OCB, then same algorithm can be used to cheaply break the underlying block cipher

– This means: If you believe block cipher x is secure, you believe x-OCB is also secure

May 2001


Slide 24

doc.: IEEE 802.11-01/223

Submission

Agenda


May 2001


Slide 25

doc.: IEEE 802.11-01/223

Submission

Why not separate encryption and integrity algorithms?

• Requires more customer sophistication– Must know when to enable one or both– Opens the door to unsound practice of

encryption without data authentication

• Requires more resources– Sender, receiver need state for 2 keys– Encapsulation/decapsulation require two passes

over packet

May 2001


Slide 26

doc.: IEEE 802.11-01/223

Submission

Won’t IP issues make OCB harder to implement?

• Rogaway has filed patent on OCB• OCB based on IAPM, and IBM has filed patent on IAPM• Rogaway has non-discriminatory licensing statement for

OCB (http://www.cs.ucdavis.edu/~rogaway/ocb/ocb-back.htm)• IBM has non-discriminatory license statement for IAPM (

http://csrc.nist.gov/encryption/modes/proposedmodes/iapm/iapm-ip.pdf)• Gligor’s (XCBC) work similar to Jutla’s; VDG has filed

patent• VDG has issued non-discriminatory license statement (http://

csrc.nist.gov/encryption/modes/proposedmodes/xcbc/xcbc-doc.pdf)

May 2001


Slide 27

doc.: IEEE 802.11-01/223

Submission

Won’t OCB Change?

• If it does, so what? We will use the OCB version dated April 1, 2001– A full proof of security available– A final specification available

• Rogaway considers OCB definition final (http://www.cs.ucdavis.edu/~rogaway/ocb/ocb-back.htm)

May 2001


Slide 28

doc.: IEEE 802.11-01/223

Submission

Agenda


May 2001


Slide 29

doc.: IEEE 802.11-01/223

Submission

Some Raw Performance*• Selected MICs:

– HMAC-MD5 35.9 cycles/byte– HMAC-SHA1 58.6 cycles/byte– DES-CBC-MAC 48.1 cycles/byte– AES-CBC-MAC 18.1 cycles/byte

• Selected Ciphers:– RC4** 12 cycles/byte– 3DES 144.8 cycles/byte– AES-CBC 18.1 cycles/byte– AES-OCB 22.7 cycles/byte

*On a Pentium Pro 200 with NT 4.0. HMAC, MD5, SHA-1, DES taken from OpenSSL 0.9.6; AES/OCB from the reference code ** Does not account for resetting or key schedule that is a per packet overhead

May 2001


Slide 30

doc.: IEEE 802.11-01/223

Submission

Line Rate Cycles in Software

0

200000000

400000000

600000000

800000000

1000000000

1200000000

1400000000

1 2 3 4 5 6 7 8 9

Crypto algorithm

Cyc

les

nee

ded

to

ru

n a

t li

ne

rate

54 MHz

11 MHz

2 = HMAC-MD5

3 = HMAC-SHA1

4 = DES-CBC-MAC

5 = AES-CBC-MAC

6 = RC4

7 = 3DES

8 = AES-CBC

9 = AES-OCB

May 2001


Slide 31

doc.: IEEE 802.11-01/223

Submission

Performance Considerations

• Separate privacy and integrity algorithms require– Two passes over packet data

• e.g. AES-CBC + AES-CBC-MAC ~ 36 cycles/byte

– Two keys per half-duplex association– Implementation of separate algorithms

• e.g., 3DES-CBC + HMAC-SHA-1

• OCB– Uses one pass over packet data– 1 key per half-duplex association– Implementation of 1 algorithm only – less code/gates

May 2001


Slide 32

doc.: IEEE 802.11-01/223

Submission

Agenda

• Background• Discussion of AES• OCB mode• Security Considerations• Implementation Considerations• Performance Considerations• True Integrity:Using OCB to fix a bug in the Draft• Summary

May 2001


Slide 33

doc.: IEEE 802.11-01/223

Submission

Another type of attack

STA1 STA2AP

Attacker

Change pkt DAto be Attacker

An authenticated attacker can easily modify the destination’s address from any packet and get a decrypted packet by simply modifying the contents of the Address 3 field!

May 2001


Slide 34

doc.: IEEE 802.11-01/223

Submission

Address is always Addr3

ToDS FromDS Addr3 Comments

0 0 BSSID Common key is used; attack is moot

1 0 SA DA is qualifier sending to SA

0 1 DA SA is qualifier sending to DA

1 1 DA RA is qualifier sending to DA

May 2001


Slide 35

doc.: IEEE 802.11-01/223

Submission

OCB can provide true Integrity

• AES can easily protect addresses by inclusion in the IV:

IV = 02bytes || Addr3(6bytes) || Replay Seq(8bytes)

May 2001


Slide 36

doc.: IEEE 802.11-01/223

Submission

Agenda

• Background

• Discussion of AES

• OCB mode

• Security Considerations

• Implementation Considerations

• Performance Considerations

• Summary

May 2001


Slide 37

doc.: IEEE 802.11-01/223

Submission

Summary• OCB mode security is proven

– Its proof says any weakness can only be in underlying cipher– its mandatory use of data integrity increases chance correct use

• AES-OCB maximizes performance on the widest variety of platforms

• Licensing– Rogaway , IBM and VDG all have non-discriminatory license

statements

• Opportunity to lead – NIST plans to replace DES with AES as the standard cipher this

year

May 2001


Slide 38

doc.: IEEE 802.11-01/223

Submission

Feedback?

May 2001


Slide 39

doc.: IEEE 802.11-01/223

Submission

Backup

May 2001


Slide 40

doc.: IEEE 802.11-01/223

Submission

ComparisonSecurity Goals

WEP WEP2 AES/OCB

privacy Requires rapid key exchange (~10min)

Vulnerable to weak keys

Vulnerable to weak keys

Key strength: O(2127) AES ops to recover key

integrity Vulnerable to probabilistic chosen-plaintext attacks

Vulnerable to probabilistic chosen-plaintext attacks

Probability of forgery is 2-MIC_bit_length

authenticity Not addressed Not addressed Easily addressed

May 2001


Slide 41

doc.: IEEE 802.11-01/223

Submission

Export Considerations

• NIST has taken (worldwide) commercial considerations.

• Collaborative efforts with Canadian Government(http://csrc.nist.gov/encryption/aes/aesfact.html)

doc.: ieee 802.11-01/223 submission may 2001 nancy cam-winget, atheros et alslide 1 an analysis of...

Documents