doc.: ieee 802.11-01/223 submission may 2001 nancy cam-winget, atheros et alslide 1 an analysis of...
TRANSCRIPT
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
Nancy Cam-Winget, Atheros et al
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
Nancy Cam-Winget, Atheros et al
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
Nancy Cam-Winget, Atheros et al
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
Nancy Cam-Winget, Atheros et al
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
Nancy Cam-Winget, Atheros et al
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
Nancy Cam-Winget, Atheros et al
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
Nancy Cam-Winget, Atheros et al
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
Nancy Cam-Winget, Atheros et al
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
Nancy Cam-Winget, Atheros et al
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
Nancy Cam-Winget, Atheros et al
Slide 11
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
Nancy Cam-Winget, Atheros et al
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
Nancy Cam-Winget, Atheros et al
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
Nancy Cam-Winget, Atheros et al
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
Nancy Cam-Winget, Atheros et al
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
Nancy Cam-Winget, Atheros et al
Slide 16
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
Nancy Cam-Winget, Atheros et al
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
Nancy Cam-Winget, Atheros et al
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
Nancy Cam-Winget, Atheros et al
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
Nancy Cam-Winget, Atheros et al
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
Nancy Cam-Winget, Atheros et al
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
Nancy Cam-Winget, Atheros et al
Slide 22
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
Nancy Cam-Winget, Atheros et al
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
Nancy Cam-Winget, Atheros et al
Slide 24
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
Nancy Cam-Winget, Atheros et al
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
Nancy Cam-Winget, Atheros et al
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
Nancy Cam-Winget, Atheros et al
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
Nancy Cam-Winget, Atheros et al
Slide 28
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
Nancy Cam-Winget, Atheros et al
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
Nancy Cam-Winget, Atheros et al
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
Nancy Cam-Winget, Atheros et al
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
Nancy Cam-Winget, Atheros et al
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
Nancy Cam-Winget, Atheros et al
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
Nancy Cam-Winget, Atheros et al
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
Nancy Cam-Winget, Atheros et al
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
Nancy Cam-Winget, Atheros et al
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
Nancy Cam-Winget, Atheros et al
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
Nancy Cam-Winget, Atheros et al
Slide 38
doc.: IEEE 802.11-01/223
Submission
Feedback?
May 2001
Nancy Cam-Winget, Atheros et al
Slide 39
doc.: IEEE 802.11-01/223
Submission
Backup
May 2001
Nancy Cam-Winget, Atheros et al
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
Nancy Cam-Winget, Atheros et al
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)