1 march, 2002 doc:.: 802.15-02/132r1 daniel v. bailey, ari singer, ntru 1 project: ieee p802.15...

11

March, 2002 doc:.: 802.15-02/132r1

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: [NTRU Security Suite Proposal Highlights]Date Submitted: [March 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/D09, P802.15-02-074r1 802.15.3 Call For Proposals for a Security Suite]

Abstract: [This presentation presents highlights of NTRU’s proposal for security suite for the 802.15.3 draft standard.]

Purpose: [To familiarize the working group with the NTRU proposed security suite.]

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

March, 2002 doc:.: 802.15-02/132r1


• 802.15.3 is a high data-rate, personal-range MAC and PHY• One use case is directed connectivity for consumer rich

media devices• 55 Mbps (and up!) per second is needed by things that

stream…– DVD players– HDTVs, wireless projectors– Digital camcorders

• …and things that “check in/out” content– Digital cameras– Personal MP3 players

• The things using 1394 and USB today!

Directed Connectivity

Use Cases

33

March, 2002 doc:.: 802.15-02/132r1


• Consumer multimedia devices• Small form factor• User interface varies from a PC to a receiver to a digital camera to

a speaker• Setup has to be simpler than cables!!!

– Today consumers are fatigued by the effort needed to set up the average home entertainment center

– Does your VCR flash 12:00?

• Operate in ad-hoc mode today– Plug your digital camera in where/when you need it– No Internet/backend connectivity can be assumed

• Severe cost/power constraints– How much extra power does a camcorder have?

What About These Devices?

Use Cases

44

March, 2002 doc:.: 802.15-02/132r1


• Today, security is a non-issue for the consumer– Just plug it in!– No threats against the consumer– Threats addressed by 5C and DVB are against content owners, not

consumers – DRM belongs outside the MAC/PHY

• 1394 asks one question of its user: Is THIS the device I want in MY network NOW?

• Plugging in answers “yes.”• So the user is trusted to make this decision

Security and Cables

Use Cases

55

March, 2002 doc:.: 802.15-02/132r1


• What does that buy me in terms of security?• Everything I need!• Security Goal #1: Only devices I want can join my network/Is this

the device I want in my network now?• Security Goal #2: Only devices I want can read my data• Security Goal #3: Only devices I want can send data my devices

will accept

• How do we reach these goals in 802.15.3?

Security in 802.15.3

Use Cases

66

March, 2002 doc:.: 802.15-02/132r1


• Let’s say you’ve got a DVD player that can associate to one of two TVs.

• One TV is in the parents’ room, one in the kids’• Both TVs are legitimate devices• How does the DVD player know to which one it should

associate?

Two TVs in Range

Use Cases

77

March, 2002 doc:.: 802.15-02/132r1


• Another use case: Starbucks!• For 99 cents, I can join the local piconet• For another 99 cents, I can watch transient video on demand

– News, weather, sports. No DRM!– Two fixed devices in the ceiling are the PNC and video server– I place my tablet on the cash register, pay, and they exchange public

keys via low-power radio transmission– Cash register forwards tablet’s public key to PNC and video server– My tablet gets public keys of PNC and video server

• Tablet associates with hot spot• Now to view my content, tablet establishes a secure peer-to-

peer stream with video server

Portable LCD Tablet/Hot Spot

Use Cases

88

March, 2002 doc:.: 802.15-02/132r1


• Another use case: Battlefield information system

• A soldier has a backpack with devices that feed a heads-up display

• For classified applications, the military uses its own, classified crypto methods

• We can’t speculate about the actual needs of their application, so we simply try and be flexible

• Our architecture gives them the flexibility they need to:– Use their own cipher suite (PNC broadcasts an OID in the beacon)– Use their own trust establishment method

• Do they use certificates?

• If so, what format? There’s lots of different kinds (X.509, SPKI, WTLS, various proprietary “short” or “implicit” certs)

• If we pick a format, how do we know we picked the right one?

21st Century Soldier

Use Cases

99

March, 2002 doc:.: 802.15-02/132r1


• The KISSS Principle: Keep it Simple and Secure, Stupid!– Complexity in security is BAD. It’s more stuff to get wrong in

implementation.

– 1394’s security is Real Simple, but plenty for the application.

– Complexity is expensive.

• Let’s start with unsecured 802.15.3 and add the security features we need

Doing Security in 802.15.3

Use Cases

1010

March, 2002 doc:.: 802.15-02/132r1


• An 802.15.3 piconet has a star topology– One device, the PNC, allocates bandwidth

– So it decides who can associate

• Security Goal #1: Only devices I want can join the network• The PNC makes this decision in an unsecure piconet• Applying the KISSS principle, it will do so in a secure piconet,

too.• How can the PNC decide?

Securing an 802.15.3 Piconet

Use Cases

1111

March, 2002 doc:.: 802.15-02/132r1


• Devices or device manufacturers can’t answer this question for a user

• So let the user tell us!– Like Logitech wireless mice and base stations, which have “Connect”

buttons

• Conceptually, the DME maintains an Access Control List of devices the MAC is to trust– The DME uses the method most appropriate for the device to maintain

the list

• But wait!• How do I know the device isn’t lying about who it is?

Is This the Device I Want in My Network Now?

Use Cases

1212

March, 2002 doc:.: 802.15-02/132r1


• Because they:– Don’t answer the relevant question: Is THIS the device I want in MY

network NOW?

– Require sophisticated user intervention in order to be secure• My device got a certificate from device xx-xx-xx-xx-xx-xx.• Is that the right device?• Is this certificate still valid? (Is that really its Device ID, or was it cloned?)

– Without timely revocation, compromise of one device compromises all devices!

– Are complicated to issue and manage

– Add cost to manufacturers

– Add complexity: Complex systems offer more avenues of attack

Why Not Require Digital Certificates?

Use Cases

1313

March, 2002 doc:.: 802.15-02/132r1


• There’s a proliferation of different incompatible certificate formats like X.509, SPKI, WTLS and proprietary “short” or “implicit” certificates.

• Certificates have their uses – but in the general ad-hoc case of 802.15.3, they just get in the way.

• Our architecture supports, but does not require, digital certificates

Why Not Require Digital Certificates?

Use Cases

1414

March, 2002 doc:.: 802.15-02/132r1


• The real question is: Is the PNC hearing over the radio from the same device I’m trying to add to my network?

• Actual identity of a device isn’t needed.– With 1394, I just know it’s “this one.”

• How do we get the user to point and say “this one?”• Best way depends on the device, so it’s best handled by the

DME– Bring them close together and they can whisper

– PNC asks the user to confirm some information the device sent

– PNC asks the user to confirm the distance between the devices

– Device presents the PNC with a digital certificate

Is the PNC Talking to the Right Device?

Use Cases

1515

March, 2002 doc:.: 802.15-02/132r1


• While we’re at it, how does the device know the PNC is the right one?

• All the same ways, it turns out…

Is the Device Talking to the Right PNC?

Use Cases

1616

March, 2002 doc:.: 802.15-02/132r1


• Once the user points and says “this one,” it’d be nice for the devices to be able to prove to each other they really are “this one.”

• How do we do that?• How about if I send you a secret only you can read and you

prove to me you could read it?• That’s the essence of a Challenge-Response Protocol• Alice sends Bob a challenge only he can read. • Bob responds showing he could read it

Device Confirmation

Use Cases

1717

March, 2002 doc:.: 802.15-02/132r1


• One type of authentication protocol• Often uses public-key cryptography• They’re well-studied

– You find them in textbooks, web browsers, …

• Applying the KISSS Principle, let’s pick one off the shelf and gently modify it to suit our needs– We picked the TLS (aka SSL) Handshake, found in every web browser

• Let’s also pick the most-efficient public-key algorithm to hold down costs– We picked NTRUEncrypt, cause it’s highly secure, very fast, least

expensive to implement

Challenge-Response Protocols

Use Cases

1818

March, 2002 doc:.: 802.15-02/132r1


• When combining the two secrets, TLS uses two different hash functions– We use only one for simplicity

• TLS requires certificates to verify ID/Public Key binding– We allow other methods better suited for a WPAN

• The basic TLS Handshake doesn’t offer cryptographic mutual authentication– At amazon.com, the server provides its certificate, you provide a

password

• TLS offers optional compression– We don’t need to support users over modems

Comparing Our Protocol with TLS Handshake

Use Cases

1919

March, 2002 doc:.: 802.15-02/132r1


• PNC and device have now shown they talked to each other.• But as time goes on, how do I know they’re still talking to each

other and not an attacker?

My Secure Piconet

Use Cases

2020

March, 2002 doc:.: 802.15-02/132r1


• Once authentication is finished, any device can come along and pretend to be either the PNC or the device

• In authentication, how did the PNC know it was the right device?

• It sent a challenge, which the device proved it knew.• So the device can just go on proving it still knows the

challenge• That’s the essence of a Message Authentication Code (MAC)

– Let’s just call it an Integrity Code (IC) so we don’t get confused

• Applying the KISSS Principle, let’s pick one off the shelf and use it.– We picked Triple-DES cause it’s secure, fast, and inexpensive to

implement

Integrity Protection

Use Cases

2121

March, 2002 doc:.: 802.15-02/132r1


• PNC and device now can tell if they started talking to each other

• Now they can also tell if they’re still talking to each other• All PNC-DEV commands protected with a unique integrity key

only they share• All piconet data protected with a shared integrity key everyone

in the piconet knows• But I don’t want other devices to hear my data traffic

My Secure Piconet

Use Cases

2222

March, 2002 doc:.: 802.15-02/132r1


• Anyone with a radio can hear all my data traffic• How do I keep it secret?• Use a symmetric cipher

– Note: Not public-key! Symmetric ciphers are more efficient once we already share challenges

• Applying the KISSS Principle, let’s pick one off the shelf and use it– We picked Triple-DES cause it’s secure, fast, and inexpensive to

implement

• Hey, wait, haven’t I heard that line before?

Bulk Data Encryption

Use Cases

2323

March, 2002 doc:.: 802.15-02/132r1


• You can use the same gates to implement encryption as well as integrity.– Or you can use different algorithms for encryption and integrity

• The KISSS Principle tells us to do the former, not the latter• Synthesized with LeonardoSpectrum, you’ll need exactly 9796

gates.• Throughput is 2 bits/cycle for both encryption and integrity• To hit 55 Mbps, a 30 MHz clock is fine

Triple-DES

Use Cases

2424

March, 2002 doc:.: 802.15-02/132r1


• PNC and device now can tell if they started talking to the right one.

• They can also tell if they’re still talking to the right one• Now outsiders can’t hear my data traffic• But how do devices get piconet-wide keys?

My Secure Piconet

Use Cases

2525

March, 2002 doc:.: 802.15-02/132r1


• How do devices get piconet-wide keys?• Well, how do they get piconet-wide guaranteed time slots?• The PNC allocates time slots, so applying the KISSS Principle,

let it generate and distribute keys

Piconet-wide Key Distribution

Use Cases

2626

March, 2002 doc:.: 802.15-02/132r1


• Change the piconet keys• But how do I ensure only devices I want get the new keys?• PNC already shares unique keys with each device, so send the

piconet-wide keys to each device encrypted with their unique key

What if a Device Joins or Leaves?

Use Cases

2727

March, 2002 doc:.: 802.15-02/132r1


What About PNC Handover?

• Since this is a PERSONAL Area Networking standard, it’s likely the DEV, the old PNC, and the new PNC will be trusting the same user

• So let the user decide! – If these are all my devices, I don’t care which one is the PNC.

– If not, I’d rather my devices ask before associating to a new PNC.

2828

March, 2002 doc:.: 802.15-02/132r1


What Does a Device Need to Know?

• A device has a public/private key pair, installed at provisioning time.

• An authenticated device shares a unique DEK and DIK with the PNC agreed on during the authentication process

• An authenticated device shares a different DEK and DIK with the rest of the piconet.

2929

March, 2002 doc:.: 802.15-02/132r1



• A device keeps a table (access control list) of the other DEVs with which it has a trust relationship

• A simple device only needs one entry: the PNC!• The public key itself need not be stored• The PNC will need storage for each associated DEV• Put this in EEPROM

– When the electricity goes out, I don’t want to have to reintroduce every device to the PNC

Device ID

Hash of Public Key & ID

DEV or SM

Shared Keys & SSID

Sequence Numbers

3030

March, 2002 doc:.: 802.15-02/132r1



• Each device keeps some data about the current group keys

• If the beacon has the same SSID and a greater time token, the time token is updated and the key is valid for that superframe

• If the PNC ID and the PNC ID in the beacon are different, a new device is now PNC and the device attempts to authenticate to the new PNC

PNC ID SSID Shared Keys

Last Trusted Time Token

Valid in this super-frame?

PNC ID in Beacon

3131

March, 2002 doc:.: 802.15-02/132r1


How Do We Protect the Beacon?

• The beacon includes a Security Session ID (SSID) so devices know which piconet-wide key is in use

• Beacon also includes a Time Token. It’s really a beacon counter to be used in all messages to prevent replay of messages in future superframes.

• The integrity code prevents an outside attacker from modifying data in the beacon.

Beacon Header

Current SSID

Time Token

Integrity Code

3232

March, 2002 doc:.: 802.15-02/132r1


How Do We Protect Commands?

• 802.1x was broken due to failure to protect commands!• Commands include the current SSID and time token that were

sent in the protected beacon for group related commands.• Commands also include the counter from the peer relationship

for key management commands.

Command Header

Current SSID

Time Token

Counter IV Encrypted Command Data

Integrity Code

3333

March, 2002 doc:.: 802.15-02/132r1


• Let’s look at the two reasons given in 02114r3 for changing the network’s topology

• The “fly on the wall” attack assumes the PNC is lying in response to a PNC info request command– Commands are integrity protected, so it won’t happen by accident– A first-party attacker has far easier attacks on a device!

• Like decrypting your data and sending it over another channel

• The “switchboard” attack assumes the PNC is lying about the local ID-Device ID mapping– …and thus a device could direct frames to the wrong device– But any authenticated device could just be in “promiscuous” mode,

listening anyway

• Conclusion: 802.15.3’s star topology is secure

Does the Network’s Topology Need to Change?

Use Cases

3434

March, 2002 doc:.: 802.15-02/132r1


Summary of Our Proposed Architecture

• Fulfills the requirements set out:– Security Goal #1: Only devices I want can join my network

– Security Goal #2: Only devices I want can read my data

– Security Goal #3: Only devices I want can send data my devices will accept

• Respects network design principles• Keeps to the KISSS Principle• Reduces cost for manufacturers• Reduces complexity for implementers• Enables deployment of the widest range of devices• Is simple, complete and secure.

3535

March, 2002 doc:.: 802.15-02/132r1


The NTRU Hard Problem

The hard problem underlying NTRU is the

Shortest Vector Problem

in lattices of high dimension

System Hard Problem Best Solution Method

NTRU Short vector problem LLL lattice reduction

RSA Integer factorization Number field sieve

ECC Elliptic curve discrete log Pollard rho

DH Discrete logarithm Index calculus

Best Known Methods to Break:• NTRU and ECC are exponential (very slow)• RSA and DH are subexponential (faster)

3636

March, 2002 doc:.: 802.15-02/132r1


Brief History of Lattice Problems

• Lattices, the SVP, and the CVP have been extensively studied for more than 100 years (Hermite 1870s, Minkowski 1890s,…).

• Best computational tool was developed by Lenstra, Lenstra, and Lovasz (LLL algorithm) in early 1980s.

• Improvements to LLL are due to Schnorr, Euchner, Horner, Koy, and others.

• Algorithms to find small vectors in lattices have been extensively studied because they have applications to many areas outside of cryptography, including physics, combinatorics, number theory, computer algebra,….

• Contrast this with integer factorization (RSA) and elliptic curve discrete logarithms (ECC), where the only applications are to cryptography.

3737

March, 2002 doc:.: 802.15-02/132r1


NTRU Security

Cryptographic System Key/Block Size (Bits)

Processing Time

(MIPS-Years)

RSA 512 1 X 104

NTRU 834 (N = 139) 1 x 104

DES 56 5 x 105

RSA 1024 8 x 109

NTRU 1757 (N = 251) 5 x 1010

ECC ~163 (p = 163) 7 x 1011

RSA 2048 1 x 1020

NTRU 2429 (N = 347) 2 x 1021

AES 128 2 x 1027

NOTE: 4 x 103 MIPS-Years = c. 1 year on a 450 MHz Pentium

3838

March, 2002 doc:.: 802.15-02/132r1


Scrutiny

• NTRUEncrypt has been widely studied since it was first announced in 1996– Papers on NTRU techniques appear at every major cryptography

conference

– Nguyen and Stern (CaLC-2001): “this makes NTRU the leading candidate among knapsack-based and lattice-based cryptosystems, and allows high dimension lattices.”

– Miccancio (IMAP 2002) observed that NTRU lattices are in Hermite Normal Form, the most secure form for a general lattice

• NTRU encourages peer review– Challenge problems

– Support to Crypto community (CaLC conference, etc)

3939

March, 2002 doc:.: 802.15-02/132r1


NTRU Standardization work

• IEEE P1363• Draft of P1363.1 available on IEEE P1363 WG web site with

NTRUEncrypt included• Vote on permanently including NTRUEncrypt passed at May

2001 meeting

• Consortium for Efficient Embedded Security (CEES)• Draft of EESS #1 standardizing NTRUEncrypt currently available

from http://www.ceesstandards.org• Drafts include complete specification, encodings, certificate

formats, etc.

• VHN (Versatile Home Networking)• NTRU included in EIA/CEA-851

4040

March, 2002 doc:.: 802.15-02/132r1


NTRU Standardization work

• IETF• TLS: NTRU ciphersuites proposed May 2001.

• Expected to proceed to Informational RFC.

• PKIX: “Supplemental Algorithms for PKI” Internet Draft• Edited by NTRU, includes NTRUEncrypt

• Also includes new US Government algorithms: DSA2, SHA-256…

• WAP• NTRU active participants in WSG

4141

March, 2002 doc:.: 802.15-02/132r1


Performance on a Microcontroller

• Speakers will have an 8051 if they’re lucky• Microcontrollers vary widely, so here’s three implementations

of NTRUEncrypt:

• According to 02135r0, ECC encryption/decryption take more than 1 second on a 10 MHz 386, 1.5-3 seconds on a Palm VII

Architecture Internal Clock Enc. Time Dec. time RAM

8 bits 2.66 MHz 42.6 ms 60.0 ms 841 bytes

8 bits 3.4 MHz 41.3 ms 65.9 ms 841 bytes

16 bits 1 MHz 65 ms 119 ms 841 bytes

4242

March, 2002 doc:.: 802.15-02/132r1


Authentication on a Microcontroller

• If you put a 2.66 MHz 8-bit microcontroller in your system, NTRUEncrypt encryption takes 43 ms, decryption 60 ms

• The group’s goal is to complete association and authentication in less than 1 second

• Suppose a superframe lasts 65 ms

• Then authentication completes in 10 superframes, or 650 msec including communication time

4343

March, 2002 doc:.: 802.15-02/132r1


Comparison on a Microcontroller

• For comparison, our example microcontroller has a 50,000 gate RSA/ECC coprocessor

• 028r3-TG3-Coding-Criteria.ppt gives the following cost/power guidance:– In 0.18 micron technology, 100,000 gates cost 20 cents– Power is dissipated at a rate of 0.018 mW/(MHz*kgates)

* This is a software implementation of NTRUEncrypt and so requires no additional gates beyond the microcontroller

Algorithm Gate Count Gate Cost Gate Power Time

NTRU * * * 60 msec

RSA 50,000 .10 2.4 mW 420 msec

ECC 50,000 .10 2.4 mW 160 msec

4444

March, 2002 doc:.: 802.15-02/132r1


Comparison in Hardware

• What if you need NTRUEncrypt in hardware?• This is a complete implementation, including SHA-1

Algorithm Gate Count Gate Cost Gate Power Time

NTRU 20,000 .04 0.96 mW 20 msec

RSA 50,000 .10 2.4 mW 420 msec

ECC 50,000 .10 2.4 mW 160 msec

4545

March, 2002 doc:.: 802.15-02/132r1


Summary of Our Cipher Suite

• NTRUEncrypt is highly secure, accepted by the cryptographic community, and extremely efficient

• Triple-DES is highly secure, accepted by the cryptographic community, and extremely efficient

4646

March, 2002 doc:.: 802.15-02/132r1


Summary of Our Proposal

• Fulfills the requirements set out:– Security Goal #1: Only devices I want can join my network

– Security Goal #2: Only devices I want can read my data

– Security Goal #3: Only devices I want can send data my devices will accept

• Respects network design principles• Keeps to the KISSS Principle• Reduces cost for manufacturers• Reduces complexity for implementers• Enables deployment of the widest range of devices• Is simple, complete and secure.

1 march, 2002 doc:.: 802.15-02/132r1 daniel v. bailey, ari singer, ntru 1 project: ieee p802.15...

Documents