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

11

April, 2002 doc:.: 802.15-02/207r1

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: [Overview of Security Architecture]Date Submitted: [April 26, 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.4/D14]

Abstract: [This presentation gives an overview of security architecture issues for the 802.15.4 draft standard.]

Purpose: [To familiarize the working group with the security architecture.]

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

April, 2002 doc:.: 802.15-02/207r1


Agenda

• Background on Cryptography and Network Security

• The 802.15.3 Security Architecture


• Applications

33

April, 2002 doc:.: 802.15-02/207r1


• Directly protects network traffic• Encrypts and decrypts data with a single key shared by both

sender and receiver• Symmetric-key algorithms like KEELOQ, RC4, DES, AES

– Based on simple bit-manipulation operations like XOR, AND, lookup tables

• Strong security provided by Triple-DES (TDES) can be implemented in 3.5 – 6K gates, depending on requirements

• Small security provided by KEELOQ • How do the sender and receiver share a key?

– Manual techniques or…

Symmetric-Key Cryptography

44

April, 2002 doc:.: 802.15-02/207r1


• Used once to establish a key used by a symmetric algorithm– Not to protect network traffic!

• One-time cost at network setup time• Public-key algorithms like RSA, ECC, NTRUEncrypt

– Based on number-theoretic operations

– NTRUEncrypt uses only adds on 7-bit integers

Public-Key Cryptography

55

April, 2002 doc:.: 802.15-02/207r1


• We use these tools to provide security services• Authentication and Access Control restrict association• Encryption provides privacy on transmitted data • Integrity shows transmitted data wasn’t altered and came from

an authenticated device• Freshness shows transmitted data wasn’t replayed

Network Security

66

April, 2002 doc:.: 802.15-02/207r1


• Needed in situations in which a pre-established (e.g. manual) shared secret is not available

• Use public-key algorithms like RSA, ECC, NTRUEncrypt– Based on number-theoretic operations

– NTRUEncrypt uses only adds on 7-bit integers

• Used once to establish a key used by a symmetric algorithm– Not to protect network traffic!

• One-time cost at network setup time• NTRUEncrypt authentication can be implemented in software

using less than 4K ROM and 256 bytes RAM.

Authentication and Access Control

77

April, 2002 doc:.: 802.15-02/207r1


• Only needed when data is confidential• Symmetric-key algorithms like KEELOQ, RC4, DES, AES

– Based on simple bit-manipulation operations like XOR, AND, lookup tables

• Directly protects confidentiality of network traffic• Encrypts and decrypts data with a single key shared by both

sender and receiver• Small security provided by KEELOQ can be implemented in 100

bytes of ROM

• Overhead for TDES encryption is 8-15 bytes per packet

Encryption

88

April, 2002 doc:.: 802.15-02/207r1


• Shows data came from a particular DEV and wasn’t altered in transit

• Provided by symmetric-key algorithms like KEELOQ, RC4, DES, AES– Based on simple bit-manipulation operations like XOR, AND, lookup

tables• Integrity protected with a single key shared by both sender and

receiver• A block cipher provides integrity for the same gates used for

encryption

• Overhead for integrity is 4 bytes per frame

Integrity

99

April, 2002 doc:.: 802.15-02/207r1


• Needed when integrity and timeliness are both required• Prevents insertion of old messages

• Each device stores a counter that is included in the integrity protected messages

• Best left to the application

• Overhead is 4 bytes per frame (or 0 if maintaining synchronized states)

Freshness

1010

April, 2002 doc:.: 802.15-02/207r1


Selecting Security Services

• A Security suite is selected for each relationship– Security suite is a collection of cryptographic algorithms

– Determines which services are provided

– SEC bit in frame control field indicates if frame is secured

• Only provide security services that you need for your device

1111

April, 2002 doc:.: 802.15-02/207r1


Agenda

• Background on Cryptography and Network Security



• Applications

1212

April, 2002 doc:.: 802.15-02/207r1


• 802.15.3 security provides all of these services• …and has a focus on providing network-wide security

– Goal there is to protect content distribution

• Piconet-wide security requires coordination among all devices– Bandwidth is plentiful in 802.15.3

• Key update, distribution, freshness all cost bandwidth• Architecture also provides for peer-to-peer security

– Much easier to coordinate with only two nodes involved

• This architecture works for 802.15.4, but we need to make some modifications . . .

The 802.15.3 Security Architecture

1313

April, 2002 doc:.: 802.15-02/207r1


• 802.15.4 is more sensitive to bandwidth and power consumption costs than 802.15.3 . . . to say the least.

802.15.3 vs. 802.15.4

1414

April, 2002 doc:.: 802.15-02/207r1


• Security-related bandwidth overhead in .3 mainly to support piconet-wide security– The master-slave topology of .4 doesn’t need piconet-wide security

– So we save bandwidth by aiming for peer to peer security instead

• No need to broadcast the SSID (key set number), since a master and slave will only share one key set at a time

• So we excise the 8-byte SSID from the beacon, data frames, and commands, leaving the beacon untouched

• No need for key update or distribute key protocols

The 802.15.4 Security Architecture

Standard 802.15.4 Beacon

1515

April, 2002 doc:.: 802.15-02/207r1


• We reduce bandwidth even further by leaving some services to applications

• Like freshness. Eliminate the TimeToken from the beacon, data frames, and command frames

• An application that needs protection from replay can manage its own freshness counter– Simply prepend counter to data before symmetric encryption/integrity

– Or use a rolling code

Saving More Bandwidth

1616

April, 2002 doc:.: 802.15-02/207r1


Still Saving Bandwidth

• Do we need an integrity code field in all frames?• Some applications may want only encryption• So we remove the Integrity Code field from the beacon, data

frames, and command frames leaving the data frame unchanged

• What about applications that need integrity?

Standard 802.15.4 Frame

1717

April, 2002 doc:.: 802.15-02/207r1


Symmetric Algorithm Choice

• An application chooses the symmetric algorithm to be used.• It also chooses the mode: with integrity or without.• The MAC hands off data to the symmetric algorithm routine,

which encrypts and optionally provides integrity.• The recipient knows the algorithm and mode, and knows if

integrity is included• The MAC doesn’t need to know if integrity is in use!

1818

April, 2002 doc:.: 802.15-02/207r1


How do we establish keys?

• Options:– Received from the DME (some out of scope process)

– Peer-to-peer key established with public key exchange

• These are the MLMEs in the draft for challenge and response• Message formats support both symmetric-only key

establishment and public-key transport• These are used to authenticate devices and establish an initial

key that’s later used to protect network data.• Only used if a device chooses to use public-key to establish a

symmetric key

1919

April, 2002 doc:.: 802.15-02/207r1


What have we done?

• Eliminated ALL bandwidth overhead due to security architecture.– Simply enabling security adds NO overhead

• Applications can choose the algorithms and features desired– These will add bandwidth overhead

• We can still support ALL of a full security solution for high-security applications, while not burdening devices

2020

April, 2002 doc:.: 802.15-02/207r1


Application: Light switch• Low security – neighbors turning my lights on/off is a nuisance,

not a major threat• I still want integrity to keep my neighbor’s devices from simply

ordering my lights to turn on/off• But I don’t need freshness: if my neighbor is going to the effort

of eavesdropping on the radio and retransmitting the data, I’m willing to live with that– Meaning it’s not worth it to me to pay more to thwart that attack.

• So I choose a tiny symmetric cipher like KEELOQ with integrity and use it without freshness

Light switchNTRUEncrypt for key exchangeUse simple algorithm - KeeloqKey length 64 bitsBlock size 32 bits Algorithm size 100 Bytes

Intelligent LightNTRUEncrypt for key exchangeUse simple algorithm - KeeloqKey length 64 bitsBlock size 32 bits Algorithm size 100 Bytes

2121

April, 2002 doc:.: 802.15-02/207r1


Application: Security system sensor• Medium security – Avoid record-and-replay and jamming

attacks• Security panel must be able to authenticate sensors that belong

to system• We do need freshness to prevent record-and-replay attack: If a

system panel does not receive valid heartbeat for sensor something is wrong

• So I choose a tiny symmetric cipher like KEELOQ or DES for higher security

SensorNTRUEncrypt for key exchangeUse simple algorithm - KeeloqKey length 64 bitsBlock size 32 bits Algorithm size 100 BytesOR DESKey length 64 bitsBlock size 64 bits Algorithm size 2K Bytes

Security PanelNTRUEncrypt for key exchange for all sensorsUse simple algorithm - KeeloqKey length 64 bitsBlock size 32 bits Algorithm size 100 BytesOR DESKey length 64 bitsBlock size 64 bits Algorithm size 2K Bytes

2222

April, 2002 doc:.: 802.15-02/207r1


Application: Home door lock• Here I really care about security. I wouldn’t give my neighbors the key to my

front door– Either physical or cryptographic!

• In this case, I want a key fob with public-key mutual authentication, encryption, integrity, and freshness.

• Combined with the security architecture, can provide all these services for this application

• Use Triple-DES

Remote controlNTRUEncrypt for key exchangeUse Triple-DESKey length 112 bitsBlock size 64 bits Algorithm size 2K Bytes

Door lockNTRUEncrypt for key exchangeUse Triple-DESKey length 112 bitsBlock size 64 bits Algorithm size 2K Bytes

2323

April, 2002 doc:.: 802.15-02/207r1


Conclusion

• All bandwidth overhead due to the architecture has been eliminated– Bandwidth overhead is determined by application’s choice of services

and algorithms

• Devices that need security get just what they need• Secured devices have maximum latitude in delicate

cost/power/bandwidth tradeoffs• Algorithm-agile architecture – use what works best for your

application• Algorithms can be as small as 100 bytes and with key lengths

of 64 bits• Simple devices can send packets as small as 32 bits with

embedded rolling codes

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

Documents