1. Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs)
Submission Title: [NTRU Security Tutorial]
Date Submitted: [June 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 /D14]
Abstract: [This presentation gives a tutorial overview of a proposed security solution for the draft standard.]
Purpose: [To familiarize the working group with the security architecture.]
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. Agenda New fields in MCPS-Data.indication Access Control List
Processing Secured Packets
Security Suites

3. MCPS-Data.indication MCPS-DATA.indication ( SrcPANId, SrcAddr,
DstPANId,
DstAddr,
msduLength,
msdu,
mpduLinkQuality,
SecurityUse, new!
ACLEntry new! )

4. SecurityUse field Tells you if a security suite was applied to a frame
implying the data payload was encrypted, integrity-protected, or both
Receiving this indication with SecurityUse = TRUE means the MAC successfully performed cryptographic processing on the frame
…but how?

5. ACLEntry field Tells you if the sending device is in the MAC’s ACL
…but what’s that?

6. Agenda New fields in MCPS-Data.indication Access Control List
Processing Secured Packets
Security Suites

7. What is an ACL? An Access Control List It’s key storage and more!
It’s part of the MAC PIB
DME stores the security-relevant details about another device
MAC gets all security data it needs from the ACL
PAN ID
Local Address
Device Address
Security Suite
Payload Key
Frame Counter
Key use Counter
2 bytes
1 byte
8 bytes
16 bytes
4 bytes

8. How Does the MAC use the ACL?
In ACL mode (actually ACL-only mode), the MAC simply
checks if the sender’s address appears in its ACL
sets the ACLEntry bit appropriately
In secured mode, the MAC uses the key and counter to provide security (encrypt/decrypt/integrity code) on transmitted or received frames
Sender can turn security on/off on a frame by frame basis
If security is on and security checks fail, frame is dropped
Otherwise, frame is decrypted and SecurityUse bit set to TRUE.

9. How Does the DME use the ACL?
In ACL mode (actually ACL-only mode), the DME simply
adds the addresses of trusted devices
all other fields empty!
In secured mode, the DME
adds addresses, keys, and counters for trusted devices
Maintains the list!

10. Agenda New fields in MCPS-Data.indication Access Control List
Processing Secured Packets
Security Suites

11. How Does This Work? Let’s walk through receipt of a secured packet
Step 1: Frame received with SEC bit set
Step 2: MAC looks up the source address, if present, in the ACL
If not present, MAC assumes it’s from the controller and looks in a specially-designated entry
Step 3: MAC obtains the cryptographic key and counters
If not present, drop the frame and send MLME-SECURITY-ERROR.indication with ReasonCode UNAVAILABLE-KEY

12. How Does This Work?
Step 4: MAC hands off the frame, keys, and counters to the security suite
Step 5: The security suite implementation decrypts frame payload, checks integrity code
Step 6: The security suite implementation returns results to the MAC
Step 7: If successful, the MAC forms an MCPS-Data.indication with ACLEntry and SecurityUse set to TRUE
Otherwise, drop the frame

13. In Summary
The security mechanism in 02/217 can answer the following questions about a received frame:
Did it come from someone in my ACL?
Was it really her? (by checking the integrity code)
Was it modified by anyone else? (by checking the integrity code)
It encrypts and decrypts, too

14. Agenda New fields in MCPS-Data.indication Access Control List
Processing Secured Packets
Security Suites

15. Which algorithm is used?
The Advanced Encryption Standard (AES)
U.S. Federal Information Processing Standard 197
Adopted in November, 2001
A block cipher with a 128-bit key and 128-bit block size
It takes 128 bits of plaintext, 128 bits of key, and produces 128 bits of ciphertext
IP in AES granted free to the world

16. 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

17. Electronic Codebook

18. 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

19. Cipher-Block Chaining

20. 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
Uses same algorithm as encryption!

21. Why Do We Care? Without integrity, an attacker can:
Send frames (even encrypted!) purporting to be someone she’s not
Intercept, modify, and retransmit frames
Issue commands like Disassociate to a device
and then pretend to be that device
802.1x attacked this way
What does it cost?
Four security suites defined in the draft
0/4/8/16 bytes
More bytes give more security. 4’s pretty marginal, but 8’s plenty

22. 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

23. Electronic Codebook Again

24. Counter Mode Why would you do that?? Any drawbacks?
Lower bandwidth overhead
In CBC encryption, you need to send an extra bytes
CTR encryption needs only 4 extra 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 a 4-byte counter value with the frame.

25. Nonces In CTR encryption, the counter value is called a nonce.
We need to make sure it doesn’t get reused
The nonce itself is 16 bytes composed of:
To minimize bandwidth overhead, store most fields in the ACL alongside the key, infer the others
Transmit only the key-use counter per frame
Flags
Device Address
Frame Counter
Key Use Counter
Block Counter
1 byte
8 bytes
4 bytes
2 bytes

26. Freshness for 5 Bytes of RAM
Since we’re all talking over a radio, anyone can replay any message – even encrypted
Since we’re incidentally constructing a unique frame number as the nonce…
The device can store the 4 unique bytes
Next frame received must have a frame number greater than the stored value
Otherwise we assume it’s replayed and we drop the packet
If the attacker replays with an updated counter, the integrity code won’t verify
This isn’t currently in the draft, but it sounds like cool optional functionality

27. 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 security suite operations with just AES encryption
Same algorithm chosen by TG3
Same algorithm expected to be chosen by Tgi

28. Conclusion Devices that need security get just what they need
On a frame-by-frame basis
Secured devices have maximum latitude in delicate cost/power/bandwidth tradeoffs
Text is available in 02/217r1