Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs)

1
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-Maildbailey_at_ntru.com 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 NTRUs
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.
2
Directed Connectivity
Use Cases

• 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!

3
What About These Devices?
Use Cases

• 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 1200?
• 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?

4
Security and Cables
Use Cases

• 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

5
Security in 802.15.3
Use Cases

• 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?

6
Two TVs in Range
Use Cases

• Lets say youve 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?

7
Portable LCD Tablet/Hot Spot
Use Cases

• 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 tablets 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

8
21st Century Soldier
Use Cases

• 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 cant 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? Theres 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?

9
Doing Security in 802.15.3
Use Cases

• The KISSS Principle Keep it Simple and Secure,
  Stupid!
• Complexity in security is BAD. Its more stuff
  to get wrong in implementation.
• 1394s security is Real Simple, but plenty for
  the application.
• Complexity is expensive.
• Lets start with unsecured 802.15.3 and add the
  security features we need

10
Securing an 802.15.3 Piconet
Use Cases

• 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?

11
Is This the Device I Want in My Network Now?
Use Cases

• Devices or device manufacturers cant 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 isnt lying about who it
  is?

12
Why Not Require Digital Certificates?
Use Cases

• Because they
• Dont 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

13
Why Not Require Digital Certificates?
Use Cases

• Theres 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

14
Is the PNC Talking to the Right Device?
Use Cases

• The real question is Is the PNC hearing over the
  radio from the same device Im trying to add to
  my network?
• Actual identity of a device isnt needed.
• With 1394, I just know its this one.
• How do we get the user to point and say this
  one?
• Best way depends on the device, so its 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

15
Is the Device Talking to the Right PNC?
Use Cases

• While were at it, how does the device know the
  PNC is the right one?
• All the same ways, it turns out

16
Device Confirmation
Use Cases

• Once the user points and says this one, itd 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?
• Thats the essence of a Challenge-Response
  Protocol
• Alice sends Bob a challenge only he can read.
• Bob responds showing he could read it

17
Challenge-Response Protocols
Use Cases

• One type of authentication protocol
• Often uses public-key cryptography
• Theyre well-studied
• You find them in textbooks, web browsers,
• Applying the KISSS Principle, lets 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
• Lets also pick the most-efficient public-key
  algorithm to hold down costs
• We picked NTRUEncrypt, cause its highly secure,
  very fast, least expensive to implement

18
Comparing Our Protocol with TLS Handshake
Use Cases

• 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 doesnt offer
  cryptographic mutual authentication
• At amazon.com, the server provides its
  certificate, you provide a password
• TLS offers optional compression
• We dont need to support users over modems

19
My Secure Piconet
Use Cases

• PNC and device have now shown they talked to each
  other.
• But as time goes on, how do I know theyre still
  talking to each other and not an attacker?

20
Integrity Protection
Use Cases

• 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
• Thats the essence of a Message Authentication
  Code (MAC)
• Lets just call it an Integrity Code (IC) so we
  dont get confused
• Applying the KISSS Principle, lets pick one off
  the shelf and use it.
• We picked Triple-DES cause its secure, fast, and
  inexpensive to implement

21
My Secure Piconet
Use Cases

• PNC and device now can tell if they started
  talking to each other
• Now they can also tell if theyre 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 dont want other devices to hear my data
  traffic

22
Bulk Data Encryption
Use Cases

• 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, lets pick one off
  the shelf and use it
• We picked Triple-DES cause its secure, fast, and
  inexpensive to implement
• Hey, wait, havent I heard that line before?

23
Triple-DES
Use Cases

• 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, youll need
  exactly 9796 gates.
• Throughput is 2 bits/cycle for both encryption
  and integrity
• To hit 55 Mbps, a 30 MHz clock is fine

24
My Secure Piconet
Use Cases

• PNC and device now can tell if they started
  talking to the right one.
• They can also tell if theyre still talking to
  the right one
• Now outsiders cant hear my data traffic
• But how do devices get piconet-wide keys?

25
Piconet-wide Key Distribution
Use Cases

• 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

26
What if a Device Joins or Leaves?
Use Cases

• 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

27
What About PNC Handover?

• Since this is a PERSONAL Area Networking
  standard, its 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 dont care which
  one is the PNC.
• If not, Id rather my devices ask before
  associating to a new PNC.

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

29
What Does a Device Need to Know?

• 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 dont 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
30
What Does a Device Need to Know?

• 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
31
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. Its 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
32
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
33
Does the Networks Topology Need to Change?
Use Cases

• Lets look at the two reasons given in 02114r3
  for changing the networks 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 wont
  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.3s star topology is secure

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

35
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)

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

37
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
38
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)

39
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

40
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

41
Performance on a Microcontroller

• Speakers will have an 8051 if theyre lucky
• Microcontrollers vary widely, so heres 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
42
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 groups 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

43
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/(MHzkgates)
• 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
44
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
45
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

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