May, 2002
doc:.: 802.15-02/215r0
Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs)
Submission Title: [AES Modes]
Date Submitted: [May 10, 2002]
Source: [Daniel V. Bailey, Product Manager for Wireless Networks and Ari Singer, Principal Engineer]
Company [NTRU]
Address [5 Burlington Woods, Burlington, MA 01803]
Voice:[(781) 418-2500], FAX: [(781) 418-2507], E-Mail:[[email protected]]
Re: [Draft P802.15.3/D0A]
Abstract: [This presentation gives a summary of the pros and cons for the selection of the symmetric
algorithm portion of the security suites for 802.15.3 with a focus on AES.]
Purpose: [Provide information to the 802.15.3 working group to allow the group to make the best decision
for symmetric security for 802.15.3.]
Notice: This document has been prepared to assist the IEEE P802.15. 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 acknowledges and accepts that this contribution becomes the property of IEEE
and may be made publicly available by P802.15.
Daniel V. Bailey, Ari Singer, NTRU
1
May, 2002
doc:.: 802.15-02/215r0
Agenda
• Goals of symmetric components
• Algorithms and modes
• Options
Daniel V. Bailey, Ari Singer, NTRU
2
May, 2002
doc:.: 802.15-02/215r0
Symmetric Algorithm Goals
•
Encryption
– Must be able to encrypt 55 Mbps at modest gate count and clock
rate
•
Integrity
– Must be able to process 55 Mbps at modest gate count and clock
rate
•
•
Draft D10 specifies different algorithms for encryption and
integrity
But it’s possible to use a block cipher for both encryption
and integrity
– This is what 802.11i is doing…should we do the same?
Daniel V. Bailey, Ari Singer, NTRU
3
May, 2002
doc:.: 802.15-02/215r0
Agenda
• Goals of symmetric components
• Algorithms and modes
• Options
Daniel V. Bailey, Ari Singer, NTRU
4
May, 2002
doc:.: 802.15-02/215r0
SHA-256 HMAC
• SHA-256 is a new algorithm
– In a draft NIST FIPS standard
– Limited implementation reports
– Vendors selling SHA-256 cores quote 23-27,000 gates for
implementation
• NIST FIPS 198 describes generic HMAC construction
• Currently in 802.15.3 draft for data integrity
• No IP issues
– NIST algorithms are traditionally royalty-free to the world
Daniel V. Bailey, Ari Singer, NTRU
5
May, 2002
doc:.: 802.15-02/215r0
SHA-256 HMAC
• Combined with AES, appears very secure
– Known attacks on variable length CBC encryption do not apply when
integrity protection is provided
• It’s a reasonable choice, but do we need to spend another 2327,000 gates?
• Other secure networking standards (IPSec, 802.11i) are
choosing to use AES for both encryption and integrity
• What are the alternatives?
Daniel V. Bailey, Ari Singer, NTRU
6
May, 2002
doc:.: 802.15-02/215r0
AES Modes of Operation
•
•
•
•
At first glance, a block cipher is a pretty simple beast
It takes plaintext and a key and outputs ciphertext
Most naïve mode called Electronic Codebook (ECB)
Diagrams here from NIST FIPS 81
Daniel V. Bailey, Ari Singer, NTRU
7
May, 2002
doc:.: 802.15-02/215r0
Electronic Codebook
Daniel V. Bailey, Ari Singer, NTRU
8
May, 2002
doc:.: 802.15-02/215r0
Cipher-Block Chaining
• Each ECB block is encrypted independently
– Attackers can mount dictionary attacks on a block by block basis
• We’d prefer that a plaintext block never encrypt to the same
ciphetext block twice
• …And so CBC came to be
• The last output block depends on each preceding output block
Daniel V. Bailey, Ari Singer, NTRU
9
May, 2002
doc:.: 802.15-02/215r0
Cipher-Block Chaining
Daniel V. Bailey, Ari Singer, NTRU
10
May, 2002
doc:.: 802.15-02/215r0
CBC-MAC
• We can use the error-detection properties with or without
sending encrypted data
– Use CBC encryption on the data stream
– Output only the last block, which is now a fancy keyed CRC
– The last block is the Integrity Code
• Same net effect as using SHA-256 HMAC, but uses same
hardware as encryption
Daniel V. Bailey, Ari Singer, NTRU
11
May, 2002
doc:.: 802.15-02/215r0
Counter Mode (CTR)
•
•
Yet another encryption mode
Introduced by Diffie and Hellman in 1979
– Standardized in NIST SP800-38A
•
It actually uses ECB mode to make a keystream which you XOR with
your plaintext
– Keystream is the ciphertext blocks computed by encrypting a counter
•
Why would you do that??
– Allows pipelined hardware.
– Slightly lower bandwidth overhead: in CBC, you need to send an extra 13-28
bytes
– Modest gate count savings: There’s no need to implement AES decryption!
•
Any drawbacks?
– You can’t reuse counter values with any key
• With CBC, you send a random Initialization Vector with the frame to start the chaining
• With CTR, you send the first counter value with the frame
Daniel V. Bailey, Ari Singer, NTRU
12
May, 2002
doc:.: 802.15-02/215r0
AES-CCM (CTR with CBC-MAC)
• This is just using Counter Mode for encryption and CBC-MAC
for integrity
– Using one key instead of two
• Allows you to do all your data-rate dependent operations with
just AES encryption
• Eliminates need for high-speed SHA-256 hardware
• Eliminates need for AES decryption hardware
• Unpatented according to 802.11-01/634r0
• Fully described in 802.11-02/001r0
• Text for adoption by 802.11i in 802.11-02/144r1
• Has a majority of support in 802.11i
– But not enough to unseat the mode in the 802.11i called AES-OCB.
Daniel V. Bailey, Ari Singer, NTRU
13
May, 2002
doc:.: 802.15-02/215r0
AES-OCB (Offset Codebook)
• Using AES-CCM requires two AES encryptions on each block of
data
– One for the AES-CTR encryption
– One for the AES-CBC-MAC integrity code
• AES-OCB is an integrated mode that needs only one AES
encryption/decryption for both data encryption and integrity
• Allows pipelined hardware like AES-CCM
• Also eliminates need for high-speed SHA-256 hardware
• Full details in 802.11-01/378r2
• More online at http://www.cs.ucdavis.edu/~rogaway/ocb/
• Diagram available at
http://www.cs.ucdavis.edu/~rogaway/ocb/ocb.gif
• It’s patented according to 802.11-01/378r2
Daniel V. Bailey, Ari Singer, NTRU
14
May, 2002
doc:.: 802.15-02/215r0
Quick Performance Comparison
• Since they’re both based on AES, they need roughly the same
area
– AES-CCM’s a bit smaller since it doesn’t use AES decryption
• AES-OCB always requires about half the encryptions for AESCCM.
• When does it begin to matter?
Daniel V. Bailey, Ari Singer, NTRU
15
May, 2002
doc:.: 802.15-02/215r0
Quick Performance Comparison
•
•
•
•
•
802.11-01/634r0 observes the following:
Typical AES encryption implementation in 20k gates.
10 cycles for a 128-bit encryption
At 40 MHz, that’s 4 million AES blocks/sec
Or max throughput of 512 Mbps
• At 55 Mbps, it doesn’t matter
• Nor at 100 Mbps.
• But at 400 Mbps, AES-OCB needs only a 40 MHz clock, while
AES-CCM needs a 65 MHz clock
Daniel V. Bailey, Ari Singer, NTRU
16
May, 2002
doc:.: 802.15-02/215r0
Agenda
• Goals of symmetric components
• Algorithms and modes
• Options
Daniel V. Bailey, Ari Singer, NTRU
17
May, 2002
doc:.: 802.15-02/215r0
Option 1: AES-CBC with SHA-256
HMAC
• Pros:
– This combination is currently in the draft
– Neither algorithm is patented
– Highly secure
• Known attacks on variable length CBC encryption do not apply when integrity
protection is provided
• Cons:
– SHA-256 may be costly to implement in hardware at high speeds –
estimated at 23-27K gates (may be less costly)
– This must be implemented in hardware along with AES encryption to hit
the data rate
– Will not match 802.11i
Daniel V. Bailey, Ari Singer, NTRU
18
May, 2002
doc:.: 802.15-02/215r0
Option 2: AES-CCM
• Pros:
– This combination of modes has received a majority support in 802.11i (it
is not in the current draft)
• Being proposed by RSA Security and others
– AES Decryption not needed
• Modest gate count savings
–
–
–
–
SHA-256 no longer has to meet the data rate
Not patented
Text is available in 802.11-02/144r1
May align with 802.11i
Daniel V. Bailey, Ari Singer, NTRU
19
May, 2002
doc:.: 802.15-02/215r0
Option 2: AES-CCM
• Cons:
– Possible issues with provable security
• MAC-then-encrypt not provably secure in generic case
• Use of only one key for two different AES modes, so it is not strictly generic
composition of two algorithms
• A proof is evidently in process but not yet published
– Increased security with use of 2 keys (if selected) would require
additional gates to store both keys
– Will require some tweaks to the draft to ensure unique IV and support
MAC-then-encrypt paradigm
Daniel V. Bailey, Ari Singer, NTRU
20
May, 2002
doc:.: 802.15-02/215r0
Option 3: AES OCB Mode
• Pros:
– Currently in 802.1x draft
– Has security proofs
• Original paper only covered situation where entire data was both encrypted
and integrity protected
• Newer paper covers a cleartext header (needed for 802.11 and 802.15.3)
– SHA-256 no longer has to meet the data rate
• Cons:
– Patented
– Arguments made that number of ciphertexts before security degrades is
limited, but this is not a problem in practice
Daniel V. Bailey, Ari Singer, NTRU
21
May, 2002
doc:.: 802.15-02/215r0
Option 4: Do whatever 802.11i does!
• Pros:
– It’s Someone Else’s Problem
• Cons:
– It’s Someone Else’s Problem
• They’re not expecting a standard anytime soon
– Strict compatibility doesn’t appear possible
Daniel V. Bailey, Ari Singer, NTRU
22
May, 2002
doc:.: 802.15-02/215r0
Summary
• Hardware
– AES-CBC with SHA-256 HMAC will cost the most
– CCM and OCB are close in hardware cost (depending on
implementation and throughput needed)
• Security
– AES-CBC with SHA-256 and OCB seem to provide the best known
security
• Good reason to believe that CCM is secure as well
• Patents
– OCB is patented, the other two options are not
• Compatibility with 802.11i
– Compatibility may be difficult even if we choose the same algorithm
Daniel V. Bailey, Ari Singer, NTRU
23
Descargar

02215r0P802-15_TG3-AES-Modes - IEEE-SA