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: [Summary of WPAN Security Proposal] Date Submitted: [22 February, 2002] Source: [Dr. Matthew Welborn] Company [XtremeSpectrum, Inc.] Address [8133 Leesburg Pike, Ste. 700, Vienna, VA, 22180] Voice:[(703) 269-3052], FAX: [(703) 269-3092], E-Mail:[mwelborn@xtremespectrum.com] Re: [In response to the Call for Proposals for a Security Suite, IEEE doc# P802.15-02-074r1] Abstract: [This document summarizes a proposed security framework and “cipher suite” that are appropriate for WPAN environment and that provide strong authentication and data privacy.] Purpose: [To promote further discussion of security models and cipher suites for the 802.15.3 MAC ] 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. Dr Matthew Welborn, XtremeSpectrum

2. Summary of WPAN Security Proposal Dr Matthew Welborn, XtremeSpectrum

3. Establishing Trust • The security model for 15.3 piconets is based on protection of data privacy using a secret key shared by all members • This shared key is distributed to authenticated DEVs only • Authentication is the process whereby the initial trust is established between all of the members of the piconet • Models for other systems (the Internet, 802.11, etc.) rely on a trusted third party to establish initial trust between members of the local network through digital certificates or other techniques But, … Dr Matthew Welborn, XtremeSpectrum

4. Establishing Trust But, … • The WPAN space will contain low-complexity devices with potentially limited user interfaces and no Internet access • WPANs are USER-CENTRIC, unlike WLANs which are primarily used to provide a wireless extension of a wired network infrastructure and all of its associated services • Instead, WPANs are oriented around the [potentially ad hoc] connection of heterogeneous, multimedia-rich devices in the personal space of a user • Therefore, it is more appropriate for a WPAN to give the INDIVIDUAL USER much more control over access to the piconet through the use of simple mechanisms to establish piconet trust Dr Matthew Welborn, XtremeSpectrum

5. User Established Trust in the WPAN • We therefore propose that authentication NOT REQUIRE the use of digital certificates or a certificate authority (CA)—although this could be an option for some applications • Effective techniques can be devised to allow the user to exert positive control over the trust establishment process during authentication, examples include: • User verification of device ID numbers (I.e. effectively a non-RF “out-of-band” verification channel) • Pre-loaded access control lists for component systems • User-initiated positive action (e.g. “Push the button now”) • Enforced proximity during authentication of devices through ranging/low power transmission • Pre-selecting some or all of these solution is beyond the scope of the 802.15.3 MAC standard: just provide the hooks Dr Matthew Welborn, XtremeSpectrum

6. WPAN Security Modes • This proposal provides levels of piconet security: • No security at all: • No authentication or encryption. The PNC policy to allow DEVs to associate is unspecified • Authentication and command integrity: • The PNC access control policy is unspecified • The security manager (SM) verifies that the DEV has a valid public-private key pair for key distribution • Certain commands are protected by a secure message digest to ensure command authenticity • Piconet privacy: in addition to level (2) protection, • All data traffic is encrypted using a shared key Dr Matthew Welborn, XtremeSpectrum

7. Unpacking “Authentication” • Definition: Authorized: describes a a condition where a specific DEV has the right to associate with the piconet as granted by some cognizant authority (the PNC owner, user, manufacturer, etc). A specification of which DEVs are authorized to join a piconet will be referred to as an “access control list”. (It could be specified by a list of specific DEVs, a general class of DEVs, or even “ALL DEVs”.) • Goal of Authentication: The SM must verify the public key provided by a DEV is valid for some authorized DEV so that the shared data encryption key can be safely transmitted using that public key. • Now that we know the goal, we can describe the essential steps of the authentication process: Dr Matthew Welborn, XtremeSpectrum

8. Unpacking “Authentication” Authentication: • A DEV makes a claim about its identity to the SM and presents a public key so the SM can pass it the TEK • The SM needs to ensure: • The public key is half of a valid public/private key pair, and • The message containing the public key came from a device that is authorized to join the piconet. This implies that the SM must determine: • Exactly which DEV sent the public key, and • That DEV is on its “access control list” • The DEV may also need to symmetrically verify the identity of the SM and ensure the SM is on its own access control list Step 2(b) can be accomplished using many different mechanisms (including digital certificates, user interaction, etc.) and the particular technique is BEYOND THE SCOPE Dr Matthew Welborn, XtremeSpectrum

9. DEV DEV SM Authentication • Exchange takes place only between each DEV and the SM • A DEV requests to join and authenticate and sends its public key to the SM • The SM verifies that the public key is valid by encrypting a unique AK with the DEV’s public key and sending it (this is the challenge) • The DEV decrypts and returns the AK to the SM using the public key of the SM –AK must match • The SM determines if the DEV is authorized to join the piconet (mechanism is OUT OF SCOPE) • If not authorized or challenge fails, then the authentication is REJECTED • Otherwise, authentication is complete • (optional) SM authenticates to DEV • DEV requests shared key to be used for data privacy (encrypted using key derived from AK) Dr Matthew Welborn, XtremeSpectrum

10. DEV DEV SM Command Integrity • This function allows members to identify control messages sent by un-authenticated DEVs • DEVs use keys derived from their AK to “authenticate” specific messages identified as sensitive • Each DEV has its own AK from the SM (accomplished in authentication) • DEV derives a command integrity key (CIK) from its own AK • Source (DEV/SM) computes a keyed message digest of payload for traffic that requires authentication • Message digest appended to traffic • Destination computes keyed digest to verify authenticity of message Control Message Data Traffic Dr Matthew Welborn, XtremeSpectrum

11. DEV DEV SM Data Privacy • Shared data encryption key (DEK) used to encrypt all traffic • Each DEV gets the shared DEK from the SM after authentication • Source (DEV/SM) encrypts payload using specified cipher and DEK • Destination decrypts payload using the same shared symmetric DEK Dr Matthew Welborn, XtremeSpectrum

12. DEV DEV SM Re-Key After a Dissociation • Shared TEK is now compromised by the dissociated DEV • SM announces that DEK will be changed at specific time, schedules distribution of new key for each DEV • Each DEV gets the new shared DEK that is encrypted using its own AK • Entire piconet shifts to use of new DEK at the specified time • Any authenticated DEV that did not receive the new DEK can specifically request the new key from the SM New DEK DEV Dissociated Dr Matthew Welborn, XtremeSpectrum

13. New SM DEV DEV SM Change of Security Manager • New SM must be given AKs for all authenticated DEVs • Outgoing SM passes AK for each of the authenticated DEVs to new SM using the AK of the new SM • New SM assumes duties and can now use the AK for each DEV to distribute new keys in the future • DEK is unaffected, unless outgoing SM also dissociates, in which case the piconet to shifts to a new DEK AKs for all DEVs Dr Matthew Welborn, XtremeSpectrum

14. DEV DEV DEV SM Subset-SM Optional: Peer-to-Peer Privacy • A subset of DEVs in a piconet can choose to keep their own traffic exchanges private using existing security mechanisms Subset private traffic Normal piconet traffic • One of a subset of DEVs in piconet is chosen to be subset-SM • DEVs in subset authenticate with subset-SM and keys (AKs and DEK) are distributed to subset members • Original piconet can be operating with no security, with authentication, or with piconet-wide privacy • Child piconet privacy is similar, but only subset-SM (child-SM) is a member of parent piconet Dr Matthew Welborn, XtremeSpectrum

15. Specific Algorithms (the “Cipher Suite”) • Public Key algorithm: Use RSA • Key exchange: Use 3-DES with two keys • Command Integrity: Use HMAC [RFC-2104] and SHA-1 hash algorithm [FIPS-180-1] • Data encryption: use two-key 3-DES [FIPS-81] Dr Matthew Welborn, XtremeSpectrum

16. Public Key for Authentication • Public Key algorithm: Use RSA Authorization keys in Authorization Reply messages shall be RSA public-key encrypted, using the DEV’s public key. The protocol uses 65537 (0x010001) as its public exponent and a modulus length of 1024 bits. The PKM protocol employs the RSAES-OAEP encryption scheme specified in version 2.0 of the PKCS#1 standard [RSA]. RSAES-OAEP requires the selection of a hash function, a mask-generation function, and an encoding parameter string. The default selections specified in [RSA] shall be used when encrypting the authorization key. These default selections are SHA-1 for the hash function, MGF1 with SHA-1 for the mask-generation function, and the empty string for the encoding parameter string. Dr Matthew Welborn, XtremeSpectrum

17. Command Integrity Keying • Command Integrity: Use HMAC [RFC-2104] and SHA-1 hash algorithm [FIPS-180-1] The HMAC authentication keys are derived as follows: HMAC_KEY=SHA(H_PAD|AK) H_PAD=0x3A repeated 64 times Dr Matthew Welborn, XtremeSpectrum

18. Key and Data Encryption Truncate(x,n) denotes the result of truncating x to its left-most n bits. SHA(x|y) denotes the result of applying the SHA-1 function to the concatenated bit strings x and y. The keying material of 3-DES consists of two distinct DES keys. • Key encryption: Use 3-DES with two keys: KEK=Truncate(SHA(K_PAD_KEK | AK),128) K_PAD_KEK=0x53 repeated 64 times, i.e., a 512 bit string. The 64 most significant bits of the KEK shall be used in the encrypt operation. The 64 least significant bits shall be used in the decrypt operation. • Data encryption: Use 3-DES with two keys: The 64 most significant bits of the DEK shall be used in the encrypt operation. The 64 least significant bits shall be used in the decrypt operation. Dr Matthew Welborn, XtremeSpectrum