Efficient Public Key Cryptosystem for WPANs

1
Project IEEE P802.15 Working Group for Wireless
Personal Area Networks (WPANs) Submission Title
Efficient Public Key Cryptosystem fo WPANs Date
Submitted 12 March, 2002 Source Gregg
Rasor Company Motorola Address 1500 Gateway
Blvd., Boynton Beach, Florida 33426 Voice
561-739-2952, FAX [phone], E-Mail
gregg.rasor_at_motorola.com Re P802.15.3 Security
Suite Selection Abstract This presentation
highlights the advantages of the distributed
security trust architectural model and the
advantages of ECC based public key cryptosystems
for WPAN devices. Purpose For information and
guidance to 802.15.3 prior to the Security Suite
selection. 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
Efficient Public Key Cryptosystemfor WPANs

• Gregg Rasor,
• Distinguished Member of the Technical Staff
• Motorola Labs
• Rene Struik
• Certicom Research

3
ECC Cryptosystems

• ECC is fully accepted by the cryptographic
  community.
• Commercially adopted in applications like those
  contemplated for 802.15.3 WPAN.
• Full PKCS (Public Key Crypto System)
  implementation, including certification.
• Adopted by all major standards bodies.
• Basic elliptic curve cryptography is in the
  public domain (no patents).
• Certicom and others have patents on efficient ECC
  implementations and cryptographic protocols.
• Independent, non-infringing designs are possible!

4
NTRU NTRUEncrypt

• A novel, but cryptographically immature, lattice
  based public key cryptosystem.
• Secure Lattice based public key schemes are
  notoriously hard to construct.
• Presently, no tested digital signature scheme.
• Current attempt replaces several prior schemes
  that were broken most recently at AsiaCrypt,
  December, 2001.
• No digital certification is possible without a
  secure digital signature scheme.
• Completely untested in commercial applications.
• Open problem known possible zero runs in
  decrypted data, (no decryption possible).
• Ref Cryptanalysis of NTRU, Alexander May,
  1999.

5
NTRU NTRUEncrypt

• Patents
• 6,298,137 Ring-based public key cryptosystem
  method
• 6,081,597 Public key cryptosystem method and
  apparatus
• No design around possible, completely
  proprietary!
• Royalties

6
Distributed Trust Architecture

• Why do we need a distributed security trust
  model?
• The distributed security model presented in 114r4
  accommodates the central security model.
• The D09 central security model (as adopted by
  NTRU) CANNOT establish independent trust
  relationships at the DEV level. Thus,
  distributed security (DEV to DEV authentic
  channels) is impossible.
• Consequence a less secure system.

7
Distributed Trust Architecture

• In a distributed security trust model, a hacker
  must breach each DEV to compromise network
  security.
• In a centralized architecture, if the PNC or ANY
  DEVs key is compromised, the whole privacy model
  fails!
• WEP is an example of a failure in a centralized,
  shared secret architecture.

8
Distributed Trust Architecture

• In the centralized security trust model, the
  re-keying cost at a security event is higher (all
  DEVs must re-key for payload protection).
• In a distributed security trust model, only those
  DEVs that communicate data with the PNC must
  re-key.
• Re-keying requirement for commands is identical
  in both architectures.

9
Distributed Trust Architecture

• The best reason for using this distributed
  architecture is that the complexity of the DEV
  does not increase, and it provides increased
  overall security.
• All cryptographic functions needed to implement a
  distributed trust architecture are already there,
  in both proposals! except for certification

10
Identity Bindings

• This proposal cryptographically establishes a
  DEVs identity, others dont.
• Results in automatic, user independent
  configuration.
• Dumb devices are accommodated.
• DEV cloning can be avoided in networked systems
  using a simple security policy.
• Challenge and response ID binding cannot prevent
  DEV cloning by itself.

11
Identity Bindings

• Manufacturer ID can be communicated securely, and
  verified.
• Hierarchical security structure is supported
  (via trust establishment).
• DEV ID confirmation is supported.
• Important customer requirement!

12
Security Strength and Architecture

• For 80 bit effective security strength, the ECC
  public key size is 163 bits. A hardware
  implementation based on this contains 3,260
  gates.
• For 128 bit effective security strength, the ECC
  public key size is 283 bits. A hardware
  implementation based on this contains 5,660
  gates.
• Reference Area-Efficient VLSI Implementation
  of Arithmetic Operations in Binary Finite Fields,
  Johann Grosschadl, Graz University, 2001

13
Mutual Public Key Authenticated Key Agreement
Protocol (1)
X, CertT(IdA ,WA)
LOCAL ADDRESSING DELETED
K f(GA,RNDB, WA,SB)sA sB P f(RNDA,GB, SA,
WB)sB sA P Public key party A WA wAP Public
key party B WB wBP
hashA
14
Mutual Public Key Authenticated Key Agreement
Protocol (2)

• Implicit Certificates
• Public key derived from publicly available
  information, i.e.,
• - Reconstruction data DA of party A involved
• - Identity IdA of the device A
• - Authentic public key WT of trusted party (who
  issued implicit certificate).
• Formula WAg(IdA,DA,WT) DA - rWT, where
  rhash(IdADA)
• MQV Implicit Key Agreement
• K sA sB P
• (x a map(X)) (y b map(Y))P
• (x a map(X)) (Y b map(Y)WB)
• (y b map(Y)) (X a map(X)WA)
• System-wide parameters
• P is a fixed point on the shared elliptic curve
  E
• map converts an elliptic curve point to an
  integer

15
Mutual Public Key Authenticated Key Agreement
Protocol (3)

• Communicated messages
• Step 1 (A?? B) X CertT(IdA ,WA)
• Step 2 (A?? B) hashB Y CertT(IdB ,WB)
• Step 3 (A?? B) hashA
• Communications bandwidth
• Binary NIST-curve K-163 (80-bit security)
  Hash RND Cert Total
• ECC Point 21 bytes Step 1
  21 33 54
• Certificate 21 12 33 bytes
  Step 2 20 21 33 74
• Hash string 20 bytes Step 3 20
  20
• total bytes 148
• Binary NIST-curve K-283 (128-bit security)
• ECC Point 37 bytes
  Step 1 37 49 86
• Certificate 37 12 49 bytes
  Step 2 32 37 49 118
• Hash string 32 bytes
  Step 3 32 32
• total bytes 236

16
Mutual Public Key Authenticated Key Agreement
Protocol (4)

• (80-bit security) Computational cost for device
  A (similar for B)
• 30 MHz 2.66 MHz
• Step 1 (A?? B) B 19.5 ms 16 ms B
  214 ms 174 ms
• Step 2 (A?? B) A 20.5 ms 17ms A 222
  ms 182 ms
• Step 3 (A?? B) B 1 ms
  B 8 ms
• Critical path 6 superframes 12 10
  superframes
• (each superframe 65 ms)
• (Without parallel hardware) MQV using
  implicit certificates
• Computational cost
• Binary NIST-curve K-163 (80-bit security) 30MHz
  2.66MHz
• Point multiplication 7 ms 79
  ms
• MQV key computation 10.5 ms 119 ms
• Public key reconstruction 7 ms 79
  ms
• MQV key with implicit certificates 14 ms
  158 ms
• Key derivation function lt1 ms 8 ms
• SHA-1 computation lt 1 ms
  8 ms

17
Mutual Public Key Authenticated Key Agreement
Protocol (5)

• (128-bit security) Computational cost for device
  A (similar for B)
• 30 MHz 2.66 MHz
• Step 1 (A?? B) B 54.5 ms 44 ms B
  610 ms 490 ms
• Step 2 (A?? B) A 55.5 ms 45ms A 618
  ms 498 ms
• Step 3 (A?? B) B 1 ms
  B 8 ms
• Critical path 6 superframes 24 20
  superframes
• (each superframe 65 ms)
• (Without parallel hardware) MQV using
  implicit certificates
• Computational cost
• Binary NIST-curve K-283 (128-bit security)30MHz
  2.66MHz
• Point multiplication 21 ms 237
  ms
• MQV key computation 31.5 ms 357 ms
• Public key reconstruction 21 ms 237 ms
• MQV key with implicit certificates 42 ms
  474 ms
• Key derivation function lt1 ms 8 ms
• SHA-1 computation lt 1 ms
  8 ms

18
Conclusion

• Absolutely NO current security system (except
  WEP) uses a centralized security model.
• Why? Too much unacceptable risk
• Distributed architecture is the most robust
  architecture, and used in ALL state of the art
  security systems.
• Why? Reduced risk of liability and it fits the
  model that all business and people use in
  transactions.
• ECC is the only way to go!