12 March 2002 doc.: IEEE 802.15-02/144r0 Gregg Rasor, MotorolaSlide 1Submission Project: IEEE...

12 March 2002 doc.: IEEE 802.15-02/144r0

Gregg Rasor, MotorolaSlide 1Submission

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: Efficient Public Key Cryptosystem fo WPANsDate Submitted: 12 March, 2002Source: Gregg RasorCompany: MotorolaAddress: 1500 Gateway Blvd., Boynton Beach, Florida 33426Voice: 561-739-2952, FAX: 561-739-3715, E-Mail: [email protected]

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.

12 March 2002 doc.: IEEE 802.15-02/144r0


Efficient Public Key Cryptosystemfor WPANs

Gregg Rasor,

Distinguished Member of the Technical Staff

Motorola Labs

Rene Struik

Certicom Research

12 March 2002 doc.: IEEE 802.15-02/144r0


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!

12 March 2002 doc.: IEEE 802.15-02/144r0


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.

12 March 2002 doc.: IEEE 802.15-02/144r0


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 $$$

12 March 2002 doc.: IEEE 802.15-02/144r0


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.

12 March 2002 doc.: IEEE 802.15-02/144r0



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

12 March 2002 doc.: IEEE 802.15-02/144r0



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

12 March 2002 doc.: IEEE 802.15-02/144r0



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

12 March 2002 doc.: IEEE 802.15-02/144r0


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.

12 March 2002 doc.: IEEE 802.15-02/144r0


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 March 2002 doc.: IEEE 802.15-02/144r0


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

12 March 2002 doc.: IEEE 802.15-02/144r0


Mutual Public Key Authenticated Key Agreement Protocol (1)X, CertT(IdA ,WA)

hashB,,Y, CertT(IdB PB)

(1) generate random number x

(2) compute ‘exponent’ X = x P

K= f(GA,RNDB, WA,SB)=sA sB P = f(RNDA,GB, SA, WB)=sB sA PPublic key party A: WA= wAPPublic key party B: WB= wBP

(1) generate random number y

(2) compute ‘exponent’ Y = y P

(4) compute hash over the string (Y || X || IdA) using keyed hash function hK with key key2, to yield string hashB

(3) compute key K= sAsB P and (key1|| key2)=kdf(K)

(3a) Verify the authenticity of (WA, , IdA) binding

hashA

(1) compute key K=sBsA P and (key1|| key2)=kdf(K)

(2) compute hash over the string (Y || X || IdA) using keyed hash function hK with key key2, to yield string hashverifyB

(3) verify whether hashB=hashverifyB

(3a) Verify the authenticity of (WB , IdB) binding(4) compute hash over the string ( X|| Y|| IdB) using keyed hash function hK with key key2, to yield string hashA

(1) compute hash over the string (X || Y ||IdB) using keyed hash function hK with key key2, to yield string hashverifyA

(2) verify whether hashA=hashverifyA

LOCAL ADDRESSING DELETED

12 March 2002 doc.: IEEE 802.15-02/144r0


Mutual Public Key Authenticated Key Agreement Protocol (2)• Implicit CertificatesPublic 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: WA=g(IdA,DA,WT)= DA - rWT, where r=hash(IdA||DA)

• MQV Implicit Key AgreementK= 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

12 March 2002 doc.: IEEE 802.15-02/144r0


Mutual Public Key Authenticated Key Agreement Protocol (3)

• Communicated messagesStep 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

12 March 2002 doc.: IEEE 802.15-02/144r0


Mutual Public Key Authenticated Key Agreement Protocol (4)• (80-bit security) Computational cost for device A (similar for B):

30 MHz 2.66 MHzStep 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 msCritical 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 msPublic key reconstruction: 7 ms 79 msMQV key with implicit certificates:14 ms 158 msKey derivation function: <1 ms 8 msSHA-1 computation: < 1 ms 8 ms

12 March 2002 doc.: IEEE 802.15-02/144r0


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 msCritical 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 msPublic key reconstruction: 21 ms 237 msMQV key with implicit certificates: 42 ms 474 msKey derivation function: <1 ms 8 msSHA-1 computation: < 1 ms 8 ms

12 March 2002 doc.: IEEE 802.15-02/144r0


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!

12 March 2002 doc.: IEEE 802.15-02/144r0 Gregg Rasor, MotorolaSlide 1Submission Project: IEEE...

Documents

Transcript of 12 March 2002 doc.: IEEE 802.15-02/144r0 Gregg Rasor, MotorolaSlide 1Submission Project: IEEE...