1 May, 2002 doc:.: 802.15-02/215r0 Daniel V. Bailey, Ari Singer, NTRU 1 Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs)

11

May, 2002 doc:.: 802.15-02/215r0

Daniel V. Bailey, Ari Singer, NTRU

Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs)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.

22

May, 2002 doc:.: 802.15-02/215r0


Agenda

• Goals of symmetric components

• Algorithms and modes

• Options

33

May, 2002 doc:.: 802.15-02/215r0


• 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?

Symmetric Algorithm Goals

44

May, 2002 doc:.: 802.15-02/215r0


Agenda



• Options

55

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

66

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 23-27,000 gates?

• Other secure networking standards (IPSec, 802.11i) are choosing to use AES for both encryption and integrity

• What are the alternatives?

77

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

88

May, 2002 doc:.: 802.15-02/215r0


Electronic Codebook

99

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

1010

May, 2002 doc:.: 802.15-02/215r0


Cipher-Block Chaining

1111

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

1212

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

1313

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.

1414

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

1515

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 AES-CCM.

• When does it begin to matter?

1616

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

1717

May, 2002 doc:.: 802.15-02/215r0


Agenda



• Options

1818

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

1919

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

2020

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

2121

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

2222

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

2323

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

Documents

1 May, 2002 doc:.: 802.15-02/215r0 Daniel V. Bailey, Ari Singer, NTRU 1 Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs)