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: [Protocols in NTRU Security Suite] Date Submitted: [February 22, 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:[dbailey@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 gives an overview of the protocols in NTRU’s security suite proposal for the 802.15.3 draft standard.] Purpose: [To familiarize the working group with protocols in 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.

Agenda • Protocols? • What Are Our Goals for the Authentication Protocol? • Comparison with TLS Authentication Protocol • The Details on the Authentication Protocol • Details on Key Update, Key Request, and Data Protection Protocols

Use Cases Protocols? • A protocol is a sequence of actions two entities use to achieve some security goals. • The most crucial protocol for 802.15.3 is authentication and key establishment • Device authentication is the building block on which all other security services rely • It’s also the most complicated • Other protocols we need: • Key Update • Key Request • Data Transport • Let’s focus first on authentication and key establishment…

Use Cases What Are Our Goals Here? • At the end of this protocol, both parties know the following: • The user approves of their communication • Are you in my access control list? • The identity of the other party • Are you who you say you are? • The public key of the other party • Is this your key? • A payload protection seed shared with only the other party • We’ll use this key between us in the future

Use Cases Binding an Identity and a Public Key • This is a well-studied problem in one instance: PCs connected to the Internet • In that case, a Certifying Authority (CA) makes a statement of the form “At time zzz, only device xxx has key yyy.” This statement is called a certificate. • How do we know the exclusive relationship still holds? • Ask the CA or its proxy using the Online Certificate Status Protocol (OCSP) • Check if this certificate is in a Certificate Revocation List (CRL) and therefore known to be bad • Both devices must trust the same CA (or their CAs must trust each other)

Use Cases Binding an Identity and a Public Key • Certificates are problematic in WPANs: • No common root of trust exists today • Think Sony receiver and Sharp DVD player • Devices can’t check certificate revocation status • If you don’t check…the attacker breaks open one device, extracts its ID and keypair, and could make an unlimited number of trusted clones • PKI adds significant costs • Only solves part of the problem • Can’t answer if this is the device the user wants in her network now. • What if you and your upstairs neighbor both buy the same brand and model DVD player? • Many devices like speakers will not have a reliable time-of-day clock • And thus can’t check that a certificate is still valid • We’re not the only ones to make this observation • See Anderson and Stajano in “The Resurrecting Duckling.”

Use Cases Do I Want You In My Network? • We have to rely on external means to answer this question. • The trusted third party for this question is the user. • Given that’s the case, let’s trust the user to establish key-ID binding as well • Lots of options • Low-power transmission, user confirms devices are nearby • Range, if the PHY supports it • Open enrollment • Analog certificates, user compares ID and hash against that printed on the bottom of the device • … • This is handled outside the authentication protocol • And so outside the scope of the MAC/PHY standard

Use Cases Do You Have the Corresponding Private Key? • Once we have ID/Public Key binding, we need to verify the DEV knows the private key. • So we make the DEV decrypt a challenge message • And respond with proof that it decrypted the challenge successfully

Use Cases Are You Still You? • Once I authenticate you, I need to know you’re still the one I authenticated • Thwarts 802.1x-style session hijacking attacks • I sent you a challenge, so that’s a secret only we share • Since we require mutual authentication, you sent me one as well • We use the combination of these two secrets in all future PNC-DEV correspondence

Use Cases We’re Not the Only Ones With These Goals • It turns out that the TLS handshake protocol offers similar services. • TLS is a well-studied, well-designed protocol • It’s not quite a perfect fit, so what needs to change?

Use Cases Comparison with TLS Handshake • 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

Use Cases The Overall Protocol

Use Cases In the Beginning • The device knows • Its public key object, PKObj_D • Its private key, Pr_D • Its IEEE address, ID_D • The device may have verification data for Pub_SM and ID_SM • The PNC knows • Its public key object, PKObj_SM • Its private key, Pr_SM • Its IEEE address, ID_SM • The object identifier for the current security suite, OID • The PNC may have verification data for Pub_D and ID_D

Use Cases Capabilities • Both devices must be able to • Check that the device’s ID and its public key are in its access control list • Perform public-key encryption • Perform public-key decryption • Perform an integrity code

Use Cases Step 1 • A device requests authentication and sends its identity and public key to the PNC

Use Cases Step 2 • The PNC looks up the device’s ID in its table of trusted ID, Public Key pairs • If present, check the received public key matches and if so, continue • If not present, pass the ID and key to the DME, inform the device that authentication has failed due to inability to verify ID/public key binding. Abort protocol. • Select a unique Secure Session Identifier (SSID_D) • Generate random string C2 • Encrypt C2 with Pub_D • Send SSID_D, OID, ID_SM, PKObj_SM, Enc(C2,Pub_D) to the device

Use Cases Step 3 • The device looks up the PNC’s ID in its table of trusted ID, Public Key pairs • If present, check the received public key matches and if so, continue • If not present, pass the ID and key to the DME, inform the PNC that authentication has failed due to inability to verify ID/public key binding. Abort protocol. • Decrypts C2 using Pr_D • Generates random string C1 • Computes Enc_D = Key(Hash(C1||C2||0x00)) • Computes Int_D = Key(Hash(C1||C2||0x01))

Use Cases Step 3 Continued • Encrypts C1 using Pub_SM • Computes integrity code on entire protocol to this point using Int_D • Sends SymI(Header||ID_D||PKObj_D||CReq||SSID_D||OID||ID_SM||PKObj_SM||Enc(C2, Pub_D)||CRes||Enc(C1, Pub_SM), Int_D) = finished1 to PNC

Use Cases Step 4 • PNC decrypts C1 using Pr_SM • Generates Enc_D and Int_D using the formulas: • Enc_D = Key(H(C1||C2||0x00)) • Int_D = Key(H(C1||C2||0x01)) • Checks message authentication code using Int_D • Generates message authentication code on entire protocol up to the current heading using Int_D • Sets seq_num_SM = 0; Sets seq_num_D = 0 • Sends SymI(Header||ID_D||PKObj_D||CReq||SSID_D||OID||ID_SM||PKObj_SM||Enc(C2, Pub_D)||CRes||Enc(C1, Pub_SM)||finished1||ARes||C2||C1) = finished2 to the device

Use Cases Step 5 • Device checks integrity code • Sets seq_num_SM = 0; Sets seq_num_D = 0

Use Cases At the End • The user approves of their communication • Are you in my access control list? • The identity of the other party • Are you who you say you are? • The public key of the other party • Is this your key? • A payload protection seed shared with only the other party • We’ll use this key between us in the future

Use Cases Key Update Protocol Goal • The goal of this protocol is to distribute a new group seed to an authenticated device

Use Cases In the Beginning • Both devices know: • Enc_D, their shared encryption key • Int_D, their shared integrity key • SSID_D, the security session identifier for the above keys • The current TimeToken from the beacon • Seq_num1, seq_num2 key usage message counters • In addition, the PNC knows: • Seed_G, the group seed

Use Cases Capabilities • Both devices must be able to perform: • Integrity code • The device must be able to perform symmetric decryption • The PNC must be able to perform symmetric encryption

Use Cases Step 1 • Encrypts group seed using Enc_D • Generates message authentication code on message using Int_D • Sends • SSID_G for the new group keys • seq_num_SM • SymE(seed_G, Enc_D) • SymI(Header||SSID_D||TimeToken||KeyPurpose||seq_num_SM||SSID_G||SymE(seed_G, Enc_D), Int_D) • This demonstrates that the key came from the PNC and that it is not an old key update message

Use Cases Step 2 • Checks time token • Decrypts seed_G using Enc_D • Checks message authentication code using Int_D • Checks that received seq_num_SM is greater than stored sec_num_SM and replaces seq_num_SM with received value • Computes Enc_G and Int_G using the formulas: • Enc_G = Key(H(seed_G||0x00)) • Int_G = Key(H(seed_G||0x01)) • Increments seq_num_D • Generates a message authentication code on the response using Int_D

Use Cases Step 2 Continued • Device sends to PNC: • seq_num_D • SymI(Header||SSID_D||TimeToken||KeyPurpose||seq_num_D||SSID_G, Int_D) • This demonstrates that the device successfully received the new key

Use Cases Step 3 • The PNC checks time token • Checks if seq_num_D is greater than stored seq_num_D and replaces seq_num_D with received value • Checks the message authentication code on the message

Use Cases At the End • The device has the new group seed.

Use Cases Key Request Protocol Goal • The goal of this protocol is to send a group seed to an authenticated device • In this protocol, the device requests the key securely and the PNC sends the encrypted seed to the device • The key is requested when the device discovers it doesn’t have the group key (e.g. it missed a key update) • The details are much the same as the Key Update Protocol and so it isn’t discussed further here.

Use Cases Data Protection Protocol Goal • The goal of this protocol is provide encryption, integrity protection, and replay resistance on piconet data • Data can only be replayed within a single superframe

Use Cases In the Beginning • Both devices know: • Enc_G, the group shared encryption key • Int_G, the group shared integrity key • SSID_G, the security session identifier for the above keys • The current TimeToken from the beacon

Use Cases Capabilities • Both devices must be able to perform: • Integrity code • The sender must be able to perform symmetric encryption • The receiver must be able to perform symmetric decryption

Use Cases Protocol • Sender encrypts data using Enc_G and sends to receiver • Sender computes SymI(Header||SSID_G||TimeToken||SymE(data, Enc_G), Int_G) and sends to receiver • Receiver checks integrity code • Receiver decrypts data using Enc_G

Use Cases Conclusion • Protocols here are adapted from accepted industry standards like TLS • These protocols preclude 802.1x-style attacks • Devices each share a unique key with the PNC • Devices all share common group keys • All data and commands are encrypted and integrity protected • Everything here can be done on a peer-to-peer basis with one device playing the role of security manager • Elegantly supports turning security “off” in a stream!

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