Presentation is loading. Please wait.

Presentation is loading. Please wait.

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

Similar presentations


Presentation on theme: "1 November, 2002 doc:.: 802.15-02/480r0 Daniel V. Bailey, Ari Singer, NTRU 1 Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs)"— Presentation transcript:

1 1 November, 2002 doc:.: /480r0 Daniel V. Bailey, Ari Singer, NTRU 1 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Why do we send five bytes] Date Submitted: [November 14, 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 /D17] Abstract:[This presentation gives an implementation of security without sending the five byte counter overhead Purpose:[To familiarize the working group with a possible alternative implementation.] 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

2 2 November, 2002 doc:.: /480r0 Daniel V. Bailey, Ari Singer, NTRU 2 The CCM Nonce AES-CCM and AES-CTR use a key and a nonce for their encryption A nonce is just a counter. 13 bytes in this case. It’s Real Important that a nonce is never reused with the same key. Doing so lets an attacker read the data. In , the nonce is the destination’s 64-bit extended IEEE MAC address plus 5 bytes of counter that changes on a frame by frame basis. The current draft sends these 5 bytes in every frame. How can we avoid this overhead?

3 3 November, 2002 doc:.: /480r0 Daniel V. Bailey, Ari Singer, NTRU 3 All the failure cases must be handled Including frame nonreception, ACK nonreception, and other security errors There’s no argument that if things never failed, the overhead wouldn’t be needed It’s handling errors that’s messy Failure Cases

4 4 November, 2002 doc:.: /480r0 Daniel V. Bailey, Ari Singer, NTRU 4 Fundamentally, it’s the meaning of an ACK to the MAC An ACK means a frame was received, not that the integrity code passed. Looking at the failure cases will make this clear. In each case, DEV A will be sending a secured frame to DEV B. DEV B will ACK back to DEV A. Either of these or subsequent frames can get lost. What Changes?

5 5 November, 2002 doc:.: /480r0 Daniel V. Bailey, Ari Singer, NTRU 5 DEV A sends encrypted frame to DEV B. DEV B ACKs the frame and decrypts But DEV B’s MAC can’t tell if decryption was successful Any data will always decrypt to some other data. If counters are desynchronized, the DME must detect this and request DEV A to send again. Need a ZigBee ACK, or a ZigBee message failure mechanism Same issues on that ACK/recovery mechanism as when integrity is in use –And hence the MAC can tell if there was a problem AES-CTR: No Integrity Code

6 6 November, 2002 doc:.: /480r0 Daniel V. Bailey, Ari Singer, NTRU 6 DEV A sends encrypted frame to DEV B. DEV B ACKs the frame and checks integrity code, which fails DEV B’s MAC sends a new MAC frame (MLME-COUNTER-REFRESH?) to request the counter. This frame must be sent unprotected (since we don't share a counter!) DEV A replies with the counter, and retransmits the frame. DEV B checks the integrity code and it passes. Observe that retransmission may now be needed even though an ACK was received! DEV A must buffer frames longer (at least as long as it takes for the slowest 15.4 device to check the integrity code and decrypt the longest possible MAC frame.) AES-CCM: With Integrity Code, Desynchronized Counter, No Loss

7 7 November, 2002 doc:.: /480r0 Daniel V. Bailey, Ari Singer, NTRU 7 DEV A sends encrypted frame to DEV B. DEV B ACKs the frame and checks integrity code, which fails DEV B’s MAC sends a new MAC frame (MLME-COUNTER- REFRESH?) to request the counter. DEV A replies with the counter. If DEV B doesn't ACK the counter (or DEV A doesn't get it), DEV A must retransmit the counter until DEV B acks it or it gives up (how many times should it try?) It needs to store the original frame during this time AES-CCM: With Integrity Code, Desynchronized Counter, ACK Loss

8 8 November, 2002 doc:.: /480r0 Daniel V. Bailey, Ari Singer, NTRU 8 DEV A sends encrypted frame to DEV B. DEV B ACKs the frame and checks integrity code, which passes But DEV A doesn't hear the ACK and DEV B has already updated his counter (since DEV A doesn’t ACK an ACK). Now DEV A retransmits. DEV B receives the frame, but has already incremented his counter and so the IC fails. DEV B asks for the counter. But now DEV A sends it an older counter than what DEV B has - in an unprotected frame If we allow that operation, anyone in the network can roll back my counter and hence decrypt anything, not to mention allow replay of old frames. If we don't allow that operation, one must re-encrypt/re-integrity the frame with a new counter so that it's never rolled back. But that requires DEV A's MAC to store not just the frame, but the unencrypted/unintegrity'd frame as well. AES-CCM: With Integrity Code, Desynchronized Counter, ACK Loss 2

9 9 November, 2002 doc:.: /480r0 Daniel V. Bailey, Ari Singer, NTRU 9 This failure can occur in the midst of a retransmission as well. Potentially causes an instability, or infinite retries if you’re really unlucky AES-CCM: With Integrity Code, Desynchronized Counter, ACK Loss 2

10 10 November, 2002 doc:.: /480r0 Daniel V. Bailey, Ari Singer, NTRU 10 DEV A sends encrypted frame to DEV B. DEV B ACKs the frame and checks integrity code, which fails since DEV B has the wrong key DEV B requests the counter DEV A sends, DEV B receives and ACKs. Integrity code still fails! What now? Since we had to re-encrypt/re-integrity, how does the MAC know this frame is a re-encryption of a previously transmitted frame? Could add a new header bit for re-encryption That would allow DEV B to know it’s not the counter. AES-CCM: With Integrity Code, Desynchronized Key

11 11 November, 2002 doc:.: /480r0 Daniel V. Bailey, Ari Singer, NTRU 11 5 bytes per encrypted frame saved More RAM for MACs to buffer encrypted and unencrypted frames Retransmission logic now depends not just on ACK reception but on not getting an MLME-COUNTER-REFRESH frame Retransmission may require re-encryption Retransmission may now infinitely proceed New MAC frame MLME-COUNTER-REFRESH Summary of Changes

12 12 November, 2002 doc:.: /480r0 Daniel V. Bailey, Ari Singer, NTRU 12 Bit-ordering in security is correct as written And consistent with the rest of the standard Throughout the standard, bits are transmitted with the low- order bit first and the first byte first. They are numbered byte 0 and bit 0. The representation is only for transmission order purposes and has nothing to do with the way the bits/bytes are operated on. The fact that bit 0 is on the left, does not change the fact that it is the low-order bit. On Bit-Ordering

13 13 November, 2002 doc:.: /480r0 Daniel V. Bailey, Ari Singer, NTRU 13 The CCM specification is written to be EXACTLY compatible with the CCM specification defined for The way to interpret the bits within a byte are clarified slightly (NOT changed), so that there is no confusion with what 3-bits represent as an integer. The first byte is most significant and the last byte is least significant. Because of transmission representation, the first bit is least significant within the byte and the eighth is most significant within the byte. This is explained in More clarification needed? On Bit-Ordering


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

Similar presentations


Ads by Google