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: 561-739-3715, E-Mail: gregg.rasor@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 DEV’s 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 DEV’s identity, other’s don’t. • 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. (1) compute key K=sBsA P and (key1|| key2)=kdf(K) (3) compute key K= sAsB P and (key1|| key2)=kdf(K) (3a) Verify the authenticity of (WA, , IdA) binding (1) generate random number x (2) compute ‘exponent’ X = x P (1) generate random number y (2) compute ‘exponent’ Y = y P hashB,,Y, CertT(IdB PB) (4) compute hash over the string ( X|| Y|| IdB) using keyed hash function hK withkey key2, to yield string hashA (4) compute hash over the string (Y || X || IdA) using keyed hash function hK withkey key2, to yield string hashB (2) compute hash over the string (Y || X|| IdA) using keyed hash function hK withkey key2, to yield string hashverifyB (3) verify whether hashB=hashverifyB (3a) Verify the authenticity of (WB , IdB) binding (1) compute hash over the string (X|| Y||IdB) using keyed hash function hK withkey key2, to yield string hashverifyA (2) verify whether hashA=hashverifyA 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 DAof party A involved; • - Identity IdAof the device A; • - Authentic public key WTof trusted party (who issued implicit certificate). • Formula: WA=g(IdA,DA,WT)= DA - rWT, where r=hash(IdA||DA) • 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 msB: 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: <1 ms 8 ms • SHA-1 computation: < 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 msB: 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: <1 ms 8 ms • SHA-1 computation: < 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!