Presentation on theme: "Submission Title: [AES Modes] Date Submitted: [May 10, 2002]"— Presentation transcript:
1Project: 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) ], FAX: [(781) ],Re: [Draft P /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 with a focus on AES.]Purpose: [Provide information to the working group to allow the group to make the best decision for symmetric security for ]Notice: This document has been prepared to assist the IEEE P 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 P
2AgendaGoals of symmetric componentsAlgorithms and modesOptions
3Symmetric Algorithm Goals EncryptionMust be able to encrypt 55 Mbps at modest gate count and clock rateIntegrityMust be able to process 55 Mbps at modest gate count and clock rateDraft D10 specifies different algorithms for encryption and integrityBut it’s possible to use a block cipher for both encryption and integrityThis is what i is doing…should we do the same?
4AgendaGoals of symmetric componentsAlgorithms and modesOptions
5SHA-256 HMAC SHA-256 is a new algorithm In a draft NIST FIPS standardLimited implementation reportsVendors selling SHA-256 cores quote 23-27,000 gates for implementationNIST FIPS 198 describes generic HMAC constructionCurrently in draft for data integrityNo IP issuesNIST algorithms are traditionally royalty-free to the world
6SHA-256 HMAC Combined with AES, appears very secure Known attacks on variable length CBC encryption do not apply when integrity protection is providedIt’s a reasonable choice, but do we need to spend another 23-27,000 gates?Other secure networking standards (IPSec, i) are choosing to use AES for both encryption and integrityWhat are the alternatives?
7AES Modes of OperationAt first glance, a block cipher is a pretty simple beastIt takes plaintext and a key and outputs ciphertextMost naïve mode called Electronic Codebook (ECB)Diagrams here from NIST FIPS 81
9Cipher-Block Chaining Each ECB block is encrypted independentlyAttackers can mount dictionary attacks on a block by block basisWe’d prefer that a plaintext block never encrypt to the same ciphetext block twice…And so CBC came to beThe last output block depends on each preceding output block
11CBC-MACWe can use the error-detection properties with or without sending encrypted dataUse CBC encryption on the data streamOutput only the last block, which is now a fancy keyed CRCThe last block is the Integrity CodeSame net effect as using SHA-256 HMAC, but uses same hardware as encryption
12Counter Mode (CTR) Yet another encryption mode Introduced by Diffie and Hellman in 1979Standardized in NIST SP800-38AIt actually uses ECB mode to make a keystream which you XOR with your plaintextKeystream is the ciphertext blocks computed by encrypting a counterWhy would you do that??Allows pipelined hardware.Slightly lower bandwidth overhead: in CBC, you need to send an extra bytesModest gate count savings: There’s no need to implement AES decryption!Any drawbacks?You can’t reuse counter values with any keyWith CBC, you send a random Initialization Vector with the frame to start the chainingWith CTR, you send the first counter value with the frame
13AES-CCM (CTR with CBC-MAC) This is just using Counter Mode for encryption and CBC-MAC for integrityUsing one key instead of twoAllows you to do all your data-rate dependent operations with just AES encryptionEliminates need for high-speed SHA-256 hardwareEliminates need for AES decryption hardwareUnpatented according to /634r0Fully described in /001r0Text for adoption by i in /144r1Has a majority of support in iBut not enough to unseat the mode in the i called AES-OCB.
14AES-OCB (Offset Codebook) Using AES-CCM requires two AES encryptions on each block of dataOne for the AES-CTR encryptionOne for the AES-CBC-MAC integrity codeAES-OCB is an integrated mode that needs only one AES encryption/decryption for both data encryption and integrityAllows pipelined hardware like AES-CCMAlso eliminates need for high-speed SHA-256 hardwareFull details in /378r2More online atDiagram available atIt’s patented according to /378r2
15Quick Performance Comparison Since they’re both based on AES, they need roughly the same areaAES-CCM’s a bit smaller since it doesn’t use AES decryptionAES-OCB always requires about half the encryptions for AES-CCM.When does it begin to matter?
16Quick Performance Comparison /634r0 observes the following:Typical AES encryption implementation in 20k gates.10 cycles for a 128-bit encryptionAt 40 MHz, that’s 4 million AES blocks/secOr max throughput of 512 MbpsAt 55 Mbps, it doesn’t matterNor at 100 Mbps.But at 400 Mbps, AES-OCB needs only a 40 MHz clock, while AES-CCM needs a 65 MHz clock
17AgendaGoals of symmetric componentsAlgorithms and modesOptions
18Option 1: AES-CBC with SHA-256 HMAC Pros:This combination is currently in the draftNeither algorithm is patentedHighly secureKnown attacks on variable length CBC encryption do not apply when integrity protection is providedCons: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 rateWill not match i
19Option 2: AES-CCMPros:This combination of modes has received a majority support in i (it is not in the current draft)Being proposed by RSA Security and othersAES Decryption not neededModest gate count savingsSHA-256 no longer has to meet the data rateNot patentedText is available in /144r1May align with i
20Option 2: AES-CCM Cons: Possible issues with provable security MAC-then-encrypt not provably secure in generic caseUse of only one key for two different AES modes, so it is not strictly generic composition of two algorithmsA proof is evidently in process but not yet publishedIncreased security with use of 2 keys (if selected) would require additional gates to store both keysWill require some tweaks to the draft to ensure unique IV and support MAC-then-encrypt paradigm
21Option 3: AES OCB Mode Pros: Cons: Currently in 802.1x draft Has security proofsOriginal paper only covered situation where entire data was both encrypted and integrity protectedNewer paper covers a cleartext header (needed for and )SHA-256 no longer has to meet the data rateCons:PatentedArguments made that number of ciphertexts before security degrades is limited, but this is not a problem in practice
22Option 4: Do whatever 802.11i does! Pros:It’s Someone Else’s ProblemCons:They’re not expecting a standard anytime soonStrict compatibility doesn’t appear possible
23Summary Hardware Security Patents Compatibility with 802.11i AES-CBC with SHA-256 HMAC will cost the mostCCM and OCB are close in hardware cost (depending on implementation and throughput needed)SecurityAES-CBC with SHA-256 and OCB seem to provide the best known securityGood reason to believe that CCM is secure as wellPatentsOCB is patented, the other two options are notCompatibility with iCompatibility may be difficult even if we choose the same algorithm