March 2002 doc IEEE 802 15 02000 r

March, 2002 doc. : IEEE 802. 15 -02/000 r 0 Project: IEEE P 802. 15 Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [MAC Distributed Security Proposal] Date Submitted: [10 March, 2002] Source: [Rene Struik] Company [Certicom Corp. ] Address [5520 Explorer Drive, 4 th Floor, Mississauga, ON Canada L 4 W 5 L 1] Voice: [+1 (905) 501 -6083], FAX: [+1 (905) 507 -4230], E-Mail: [rstruik@certicom. com] Re: [] Abstract: [This document describes elements of the security architectural framework for the 802. 15. 3 Wireless Personal Area Network, based on the characteristics of this network and its intended operational usage. ] Purpose: [Highlight issues that need to be solved to ensure the success of the 802. 15. 3 WPAN security. ] Notice: This document has been prepared to assist the IEEE P 802. 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 P 802. 15. Submission 1 Rene Struik, Certicom Corp.

March, 2002 doc. : IEEE 802. 15 -02/000 r 0 MAC Distributed Security Proposal Gregg Rasor, Motorola René Struik, Certicom Research Scott Vanstone, Certicom Research Submission 2 Rene Struik, Certicom Corp.

March, 2002 Basic Security Services doc. : IEEE 802. 15 -02/000 r 0 • Authenticity Evidence as to the true source of information or the true identity of entities: - Message authentication. Evidence regarding the true source of information: (1) No undetectable modifications, deletions, and injections of messages by external parties (data integrity); (2) No confusion about who originated the message (source authenticity). - Entity authentication. Evidence regarding the true identity of entities and on their active involvement: (1) No confusion about whom an entity is really communicating with (authenticity); (2) Proof that entity is actively participating in communications (i. e. , is ‘alive’). • Secrecy Prevention of external parties from learning the contents of information exchanges: (1) Logical separation of information between parties that may have access to info and those that do not. (2) No confusion about whom those privileged parties are (authenticity). Submission 3 Rene Struik, Certicom Corp.

March, 2002 doc. : IEEE 802. 15 -02/000 r 0 Cryptographic Building Blocks - Authentication (1) • Message authentication Evidence regarding the true source of information: (1) No undetectable modifications, deletions, and injections of messages by external parties (data integrity); (2) No confusion about who originated the message (source authenticity). Realizations: - Keyed hash function (or Message Authentication Code (MAC)). Mapping of arbitrary messages (of any length) to compact representative image hereof, using a secret key. (1) Data integrity, since difficult to find distinct messages with same MAC value. (2) Source authentication, since only parties that share the secret key can produce MAC-value (assuming there is no confusion about who has access to this key). - Un-keyed hash function. Mapping of arbitrary messages (of any length) to compact representative image hereof (digital fingerprint, or message digest), without secret key. (1) Data integrity, since difficult to find distinct messages with same hash value. (2) Source authentication, only if message digest is communicated authentically. Submission 4 Rene Struik, Certicom Corp.

March, 2002 doc. : IEEE 802. 15 -02/000 r 0 Cryptographic Building Blocks - Authentication (2) • Entity authentication Evidence regarding the true identity of entities and on their active involvement: (1) No confusion about whom an entity is really communicating with (authenticity); (2) Proof that entity is actively participating in communications (i. e. , is ‘alive’). Realizations: - Entity authentication protocol (challenge response protocol). (1) Source authentication, since only parties that share the secret key can produce proper responses to unpredictable challenges (assuming there is no confusion about who has access to this key). (2) Aliveness, since challenge messages are unpredictable and never repeated. (Hence, replaying previously recorded protocol messages does not leak info. ) Submission 5 Rene Struik, Certicom Corp.

March, 2002 doc. : IEEE 802. 15 -02/000 r 0 Cryptographic Building Blocks - Secrecy • Secrecy Prevention of external parties from learning the contents of information exchanges: (1) Logical separation of messages between parties that may have access to info and those that do not. (2) No confusion about whom those privileged parties are (authenticity). Realizations: - Symmetric key algorithm. (1) Logical separation of information, since only parties that share the secret key can learn the contents hereof (assuming there is no confusion about who has access to this key). - Public key algorithm. (1) Logical separation of information, since only parties that share the private decryption key can learn the content of encrypted messages (assuming there is no confusion about who has access to this private key). Submission 6 Rene Struik, Certicom Corp.

March, 2002 doc. : IEEE 802. 15 -02/000 r 0 Cryptographic building blocks – Authenticity and Secrecy (1) • Symmetric key cryptography Security services based on exchange of secret and authentic keys: (1) Logical separation of messages, by exchanging secret keys between privileged parties only; (2) Authenticity of privileged parties by checking credentials of each party, by non-cryptographic means (certified mail, courier, face-to-face, etc. ) • Public key cryptography Security services based on exchange of authentic public keys: (1) Logical separation of messages, by restricting access to each private key to the privileged party only (in practice, there is only 1 privileged entity); (2) Authenticity of privileged parties, by checking credentials of each party by non-cryptographic means and (if successful) by subsequently binding the public key to this party (certification of public keys). Certification is done by a so-called Trusted Third Party, who vouches for the authenticity of the binding between an entity and its public key. Submission 7 Rene Struik, Certicom Corp.

March, 2002 doc. : IEEE 802. 15 -02/000 r 0 Cryptographic building blocks – Authenticity and Secrecy (2) • Public key cryptography (cont’d) Certification of public keys depends on appropriately checking the credentials of a party and constitutes the following: (1) Check, by cryptographic means, that the entity A that claims to have access to the public key PA, has access to the corresponding private key SA; (2) Check, by non-cryptographic means, the claimed identity Id. A of A. Certification is done by a so-called trusted third party: - Digital certificates (cryptographic binding). (1) Authenticity of binding, via signature over the pair (Id. A, PA) by trusted party; (2) Verification of authenticity of public keys by any party, by verifying signature of trusted party in the digital certificate (assuming the authentic storage of trusted party’s signature verification string on each verifying device); (3) Unrestricted transfer of certificates possible (hence, off-line certification possible). - Manual ‘certificates’(non-cryptographic: pushing button, low power mode, etc. ). (1) No cryptographic verification of the authenticity of public keys possible. (2) No transfer of certificates possible (hence, on-line ‘certification’ only). Submission 8 Rene Struik, Certicom Corp.

Use Cases March, 2002 doc. : IEEE 802. 15 -02/000 r 0 Securing DEVs in an Isolated 802. 15. 3 Piconet (1) • Problem: an isolated 802. 15. 3 piconet has no connectivity to the internet, thus no access to a trusted third party. • Solution: Manual certification - “push” a button! • A low-cost DEV (speaker) needs to join a home theater piconet, so we do the following: – Turn the home theater on and enter an Access Control List (ACL) creation mode. – Push the button on the speaker(s). This clears the ACL in the DEV and generates associate and authenticate requests to the PNC. – DEVs sends their uncertified public key to the PNC. – PNC receives and certifies each DEV’s public key, returning the corresponding certified public key to each DEV, and the PNC adds each certified DEV to its ACL. – DEV receives and stores its newly certified public key and adds PNC to its ACL. We are done! Submission 9 Rene Struik, Certicom Corp.

Use Cases March, 2002 doc. : IEEE 802. 15 -02/000 r 0 Securing DEVs in an Isolated 802. 15. 3 Piconet (2) • What if I turn the home theater off (or the PNC “goes away”)? – Each DEV authenticated in this manner is “locked” to the certifying PNC, thus another PNC cannot steal the DEV from your transient piconet without permission from the certifying PNC. • What if I turn the home theater’s power off then on? – The PNC maintains each DEV’s authentic ID in its ACL. – The PNC automatically admits each DEV based on its certified public key and the DEV being in the PNC’s ACL. • What if I want to add a new DEV? – Perform the Manual certification procedure for the DEV. • What if the PNC dies, or a new PNC replaces it and no handoff is possible? – Perform the Manual certification procedure for all DEVs. Submission 10 Rene Struik, Certicom Corp.

Use Cases March, 2002 doc. : IEEE 802. 15 -02/000 r 0 Securing DEVs in an Isolated 802. 15. 3 Piconet (3) • What happens at a PNC change (handover)? – The certifying PNC authentically notifies each DEV in its ACL of the new PNC’s identity. – In response, the new PNC certifies each DEV’s public key before changing the PNC, without user intervention. Additionally, any necessary key updates are performed to insure a seamless PNC handover. Optionally, certification and key updates can take place after changing the PNC. – Note that the trust model is not violated since each DEV effectively re-authenticates with the new PNC based on a third party trust between the active PNC and the new PNC (assuming that the identity of the new PNC shall be cryptographically verified by the active PNC before any PNC handoff occurs). Submission 11 Rene Struik, Certicom Corp.

Use Cases March, 2002 doc. : IEEE 802. 15 -02/000 r 0 Digital Certification and Signatures • Digital certification is: – an application in which a certification authority “signs” a special message m containing the name of some user, say “Alice, ” and her public key in such a way that anyone can "verify" that the message was signed by no one other than the certification authority and thereby develop trust in Alice's public key. Submission 12 Rene Struik, Certicom Corp.

Use Cases March, 2002 doc. : IEEE 802. 15 -02/000 r 0 Digital Certification and Signatures • Digital certification typically uses a signature algorithm to sign a special message. – Alice sends a “certification request” containing her name and her public key to a certification authority. – The certification authority forms a special message m from Alice's request and signs the special message m under its private key, obtaining a signature s. The certification authority returns the message m and the signature s to Alice; the two parts together form a certificate. – Alice sends the certificate to Bob to convey trust in her public key. – Bob verifies the signature s under the certification authority's public key. If the signature verifies, he accepts Alice's public key. • As with an ordinary digital signature, anyone can verify at any time that the certificate was signed by the certification authority, without access to any secret information. Submission 13 Rene Struik, Certicom Corp.

Use Cases March, 2002 doc. : IEEE 802. 15 -02/000 r 0 Why Use Digital Certificates? (1) • Because they: – Are the cryptographic method of choice to unequivocally confirm the identity of an entity. • Banks use them to secure your monetary transactions. • E-commerce is based on certificate authentication for credit transactions. • Microsoft et al. uses them to verify the authenticity of their software updates. – Allow automatic, cryptographically verified identity establishment. – Can answer the relevant question: Is THIS the device I want in MY network NOW or ever? Submission 14 Rene Struik, Certicom Corp.

Use Cases March, 2002 doc. : IEEE 802. 15 -02/000 r 0 Why Use Digital Certificates? (2) • Because they: – Do not require sophisticated user intervention in order to be secure. • A trusted third party can map a certificate to a device. • A user can easily map a certificate to a device (see preceding slides). – Are easy to issue and manage. – Are practically cost-free. – Represent the only tested, standards based solution that can be quickly and accurately implemented. Submission 15 Rene Struik, Certicom Corp.

Use Cases March, 2002 doc. : IEEE 802. 15 -02/000 r 0 Device Identity Establishment • Without digital certification and signature capability, the cryptographically verified identity of ANY device cannot be automatically established. • Challenge and response protocols ONLY establish the fact that each device has an operational public – private key pair. – The result of a challenge and response protocol is NOT useful for proving that the device you are admitting to your piconet is the device you expect. – Another element is needed that binds the device’s identity to its public – private key pair. Submission 16 Rene Struik, Certicom Corp.

March, 2002 doc. : IEEE 802. 15 -02/000 r 0 Elliptic curve cryptosystems (ECC) Standardization • ECC has been widely standardized by accredited standards organizations including: – IEEE (1363 -2000) – ANSI (X 9. 62, X 9. 63) – ISO/IEC (14888 -3, 15496, …) – NIST (FIPS 186 -2) • In particular, FIPS 186 -2 specifies the elliptic curve digital signature algorithm (ECDSA). This specification is compliant with all the other ECC standards, and is recommended for US federal government use. Submission 17 Rene Struik, Certicom Corp.

March, 2002 doc. : IEEE 802. 15 -02/000 r 0 Advantages of ECC • The smaller key sizes for ECC results in: – Faster computations – Bandwidth savings (smaller keys, certificates and signatures) – Lower power consumption • These advantages can be especially advantageous in environments where any of the following are constrained; – Processing power – Bandwidth – Power source • The advantages become even more pronounced as we move to stronger security levels for long-term security. Submission 18 Rene Struik, Certicom Corp.

March, 2002 doc. : IEEE 802. 15 -02/000 r 0 Other Advantages of ECC • All parties share a selected set of domain parameters (an elliptic curve and a generating point G on the curve). Key pair generation simply involves selection of a random integer k and then computation of the point Q=k. G. This is simple and very fast! • ECC performance scales linearly in hardware. • ECC algorithms are parallelizable in hardware. • ECC is and always has been IN THE PUBLIC DOMAIN! Submission 19 Rene Struik, Certicom Corp.

March, 2002 doc. : IEEE 802. 15 -02/000 r 0 Long-Term Security with ECC • Flexible hardware can be build to allow for different key sizes for long-term security. This is especially important as security standards are starting to move towards AES key sizes. Submission 20 Rene Struik, Certicom Corp.

March, 2002 doc. : IEEE 802. 15 -02/000 r 0 ECC-Based Public Key Cryptography (2) Key size comparison Block cipher Bit security ECC size (prime) ECC size (binary) Skipjack 80 192 163 3 DES 112 224 233 AES-small AES-medium 128 192 256 384 283 409 AES-high 256 521 571 Sources: -ANSI X 9. 30 -1997 -FIPS Pub 186 -2, Appendix 6 ECC curve K-283 conforms with ANSI X 9. 62, IEEE P 1363, WAP recommended by ANSI X 9. 63, echeck, IPSec, NIST MQV Key Agreement: ANSI X 9. 63; will become FIPS this year Implicit Certificates: -Rigorous security proofs in random oracle model (Brown, Johnson, Vanstone, Financial Crypto 2001) -Used by Canada Post and US Postal Service (for printing of stamps on envelopes) Numerous deployments of ECC certificates Submission 21 Rene Struik, Certicom Corp.

March, 2002 doc. : IEEE 802. 15 -02/000 r 0 ECC-Based Public Key Cryptography (3) Acceptance by government bodies • Brian Snow, Chief Technical Officer NSA: “ECC will become the ONLY public key algorithm for US Government Use” (during ECC 2001, Waterloo) • Adoption by Canadian Communication Security Establishment (CSE) Submission 22 Rene Struik, Certicom Corp.

March, 2002 doc. : IEEE 802. 15 -02/000 r 0 Outline • IEEE 802. 15. 3 WPAN Technology • IEEE 802. 15. 3 WPAN Security Objectives • Modes of Operation of the Piconet • Devices and their Roles • Security Policy • Access Control to the Piconet • The Need for a Distributed Security Model • Protection of Messages • Mutual Authenticated Key Agreement Protocol • Mutual Symmetric Entity Authentication Protocol • Combined Key Agreement and Entity Authentication Protocol • ECC-Based Public Key Cryptography • The 802. 15. 3 WPAN at Work • Inter-Piconet Communications • Operational Description of the 802. 15. 3 WPAN Submission 23 Rene Struik, Certicom Corp.

March, 2002 doc. : IEEE 802. 15 -02/000 r 0 IEEE 802. 15. 3 WPAN Technology • Communication technology. - Radio transmissions at unlicensed 2. 4 GHz frequency band; - High data rates, up to 55 Mbps; - Short range communication (10 meters) between static and moving devices. • Devices. - Computers, PDAs, handheld PCs, printers; - Digital imaging systems, microphones, speakers, headsets; - Personal & professional video streams (e. g. , set top box, security camera); - Barcode readers, sensors, displays, pagers, mobile and PCS phones. • Personal Area Networks (Piconets). - Network of at most 252 devices, at close mutual distance; - Communication patterns include peer-to-peer and broadcast; - Piconet Controller (PNC), one of most capable devices in piconet. Tasks: (1) admission control; (2) message control; (3) bandwidth allocation. • Interaction with outside world. - child and neighbor piconet. Via common device or PNC of particular piconet; - other networks (e. g. , LANs, WLANs). Via so-called portal, which communicates MAC service data units back and forth. Submission 24 Rene Struik, Certicom Corp.

March, 2002 doc. : IEEE 802. 15 -02/000 r 0 IEEE 802. 15. 3 WPAN Security Objectives • Access control to the piconet. Restriction of access to scarce network resources to authorized devices only, to ensure objectives including the following: - proper bandwidth allocation; - protection of radio-related commands; - quality of service (Qo. S); - power savings. • Control of access to message traffic between piconet devices. Restriction of access to information secured between members of a group of piconet devices to precisely these group members. This includes any of the following objectives: - Confidentiality. Prevent external parties from learning the content of exchanged messages. - Data integrity. Prevent external parties from modifying or injecting messages in undetected way. Submission 25 Rene Struik, Certicom Corp.

March, 2002 doc. : IEEE 802. 15 -02/000 r 0 Modes of Operation of the Piconet • No security. No cryptographic security services are provided. - Any device may join the piconet (no evidence regarding the true identity of devices, nor authorization hereof); - Any device may claim scarce resources (no protection of commands); - All message traffic is unsecured (no provisions for confidentiality or data integrity). • Authentication only. - Only authorized devices may join the piconet (evidence regarding the true identity of devices and authorization hereof); - Only admitted devices may claim scarce resources (protection of commands); - All message traffic is unsecured (no provisions for confidentiality or data integrity). • Authentication and encryption. - Only authorized devices may join the piconet (evidence regarding the true identity of devices and authorization hereof); - Only admitted devices may claim scarce resources (protection of commands); - All message traffic is secured (provisions for confidentiality or data integrity). Submission 26 Rene Struik, Certicom Corp.

March, 2002 Devices and their Roles (1) doc. : IEEE 802. 15 -02/000 r 0 Role model • Security Manager. Sole source of local trust management. -Facilitates establishment of keying material between ordinary devices; -Facilitates maintenance of keying relationships; -Enforces security policy. • Ordinary device. Part of piconet or could become part hereof. - Responsible for secure processing and storage of keying material. • Piconet controller (PNC). Sole source of local message control. -Facilitates admission of ordinary devices to the piconet; -Allocates time slots for message exchanges between devices; -No security responsibilities (apart from access control to the piconet). • Portal. Sole source that ensures integration with external networks. -No security responsibilities. • External trusted party. Sole source of global trust management. -Facilitates establishment of public keying material between ordinary devices; -Facilitates maintenance of public keying relationships; -Enforces security policy. Role of portal considered out of scope, since it deals with communications with outside world. Submission 27 Rene Struik, Certicom Corp.

March, 2002 Devices and their Roles (2) doc. : IEEE 802. 15 -02/000 r 0 Motivation role model • Distributed implementation possible, since roles only conceptually centralized. - Allowance for more than 1 PNC (since not fixed in time and place); - Allowance for more than 1 Security Manager or more than 1 External Trusted Party. • Roles independent of actual implementation. - Different roles may be implemented on a single device (e. g, PNC and Security Manager). • Separation of roles and devices that assume these roles - Allowance for dynamic mappings of roles to devices possible (e. g. , changes to PNC and Security Mgr). - Different devices may associate different roles with the same device, depending on their view on the role(s) this device should play (e. g. , device is Security Mgr for one device, ordinary device for another). • PNC need not be fixed in time and place. Hence, not prudent to assign a priori security functionality to it (for otherwise, trust might need to be established over and over again, at each change of PNC). • External Trusted Party is sole source of global trust, since it is external to the network and might have the resources deemed necessary for proper key management, e. g. , secure key generation facilities, proper authentic storage of keying material, availability. Mapping of roles to devices Devices need way to recognize which role(s) other devices play or should play. - Static mapping. Mapping may be defined at initialization. - Dynamic mapping. Mapping must be realized by securely associating roles to devices, allowing dynamic verification (e. g. , via attribute certificates). Submission 28 Rene Struik, Certicom Corp.

March, 2002 Devices and their Roles (3) doc. : IEEE 802. 15 -02/000 r 0 ‘Permanent’ mappings of roles to devices The following mapping of roles to devices are always in effect: • Each device assumes the role of ordinary device (for all devices); • The PNC device assumes the role of PNC (for all devices); • Each device may assume the role of (alternate) PNC (but there is only 1 PNC device at a time); • Each device may assume the role of security manager (for any subset of devices that include itself). The role of the external trusted party includes facilitating the generation of authentic public keying material for each device. As such, it includes - (facilitating) the generation of a public/private key pair for each device, if needed; - generation of certificates for each device’s public key; - (facilitating) the storage of an authentic copy of the trusted party’s own public key signature verification key in each device, prior to its operational deployment. There is (conceptually) only 1 entity that assumes the role of external trusted party (for all devices). (If there is actually more than 1 external trusted party, each device is assumed to have access to the other external trusted party’s ‘root’ key, either directly or via cross-certification techniques. ) The role of the external trusted party is implemented outside the network (CA functionality). Remark The PNC mapping is quasi-static, since the local address of the PNC is always fixed as 0 x 00. Submission 29 Rene Struik, Certicom Corp.

March, 2002 Devices and their Roles (4) doc. : IEEE 802. 15 -02/000 r 0 Other mappings of roles to devices The actual mapping of the PNC role to a device and that of the Security Manager role to a device might change over time. EXAMPLES I. Centralized security model (Mapping of roles to devices as in Draft D 09) The Draft D 09 document uses a quasi-static mapping, where one has the ‘permanent’ mappings and where the PNC device assumes the role of Security Manager (for all devices). There are no other mappings of roles to devices in effect. II. Distributed security model (Our proposed mapping of roles to devices) The distributed security model uses a quasi-static mapping, where one has the ‘permanent’ mappings and where each device assumes the role of Security Manager (for himself only). There are no other mappings of roles to devices in effect. (If desired, one can ‘relax’ this mapping by postulating that each device assumes the role of Security Manager for himself and for all other devices that trust him (‘friendship’ scenario). ). A detailed discussion of properties to follow later. Submission 30 Rene Struik, Certicom Corp.

March, 2002 Security Policy (1) doc. : IEEE 802. 15 -02/000 r 0 The security policy specifies rules that must be adhered to to keep security properties of system invariant, in the event of security events. Discussions are relative to a specific set of piconet devices (group). Security events 1. Change of group structure. (a) Exclusion of an old group member from the group: - Expiration of group membership. Disassociation due to time-out. - Cancellation of group membership. Disassociation due to cancellation request. - Denial of access. Disassociation due to enforcement of security policy. (b) Introduction of a new group member to the group: - Subscription of the member. Authentication of newly associated device. 2. Change of (security relevant) role. Due to mapping of roles to devices, this refers to PNC hand over only: - Resigning PNC that actively gives up its role, while remaining member. - Assuming PNC. Ordinary device that assumes role of PNC. Simultaneous changes to the group structure and to the security relevant role are conceptually thought of as to occur subsequently (in any order). Submission 31 Rene Struik, Certicom Corp.

March, 2002 Security Policy (2) doc. : IEEE 802. 15 -02/000 r 0 I. Effect of security events - change of group structure Scenario where information shared between group members is secured via a common (symmetric) group key. Security invariant At any given moment of time, access to information shared between members of a group is restricted to precisely these group members. As such, this includes access to integrity information. Security rule Changes to the group structure shall invoke a change to the common group keys. Rationale 1. This prevents a new group member from gaining access to secured information communicated prior to the moment he obtained access to the key-sharing group. 2. This prevents an old group member from gaining access to secured information communicated after the moment he was denied access to the key-sharing group. Submission 32 Rene Struik, Certicom Corp.

March, 2002 Security Policy (3) doc. : IEEE 802. 15 -02/000 r 0 I. Effect of security events - change of group structure (cont’d) Key storage invariant At any given moment of time, devices maintain symmetric keying relationships with groups to which they belong only. Key storage rule Changes to the group structure shall invoke the secure destruction of the old group key(s) and the secure and authentic storage of the new group key(s). Rationale This limits the impact of the potential compromise of symmetric keying material to exposure of information to which the device already has access as a legitimate group member. II. Effect of security events - change of security relevant role Scenario where information shared between group members is secured via a common (symmetric) group key. Changes between a group member’s role as PNC and as ordinary device have no impact on the group structure, hence these do not impact the group key(s). Submission 33 Rene Struik, Certicom Corp.

March, 2002 doc. : IEEE 802. 15 -02/000 r 0 Access Control to the Piconet (1) The access control policy specifies how devices shall communicate in a piconet. Discussions are relative to a particular piconet and do assume the piconet to operate in one of its secure modes (‘authentication only’, respectively ‘authentication and encryption’). I. Admission to the piconet is based on the outcome of the following protocols between the prospective joining device and the PNC of the piconet (in order): 1. Mutual entity authentication protocol. The device and the PNC engage in a mutual entity authentication protocol based on public key techniques. This protocol provides evidence regarding the true device identity of both the joining device and the PNC, based on authentic public keys. 2. (optional) Authorization techniques between both devices, based on, e. g. , access control lists (ACLs). If devices have been positively authenticated and have been authorized, these are admitted to the piconet. Addressing these devices within the piconet takes place using a local Id (of 8 bits), rather than their global Id (IEEE MAC Address of 48 bits). For this an unused local Id is assigned to the joining device. Remark Devices in the piconet fully depend on information provided by the PNC regarding which devices have been admitted to the piconet (since admission is based on communication between the PNC and a joining device only). Submission 34 Rene Struik, Certicom Corp.

March, 2002 doc. : IEEE 802. 15 -02/000 r 0 Access Control to the Piconet (2) Corollary (Effect of improper device list in broadcast scenario - the scenario of Draft D 09) Assume the following scenario: • All devices in the piconet share a common broadcast key; • The list of admitted devices to the piconet is L: ={(local 8 -bit device Id, global 48 -bit device Id)}. Then failure to obtain the complete and authentic list of admitted devices has the following consequences: • ‘Fly on the wall’. If a device obtains an incomplete list L’ L (L’ L) of admitted devices, all devices in the complementary set L L’ are ‘invisible’ to the device. Hence, the device might mistakenly think to share secured information only with devices from the list L’, whereas actually it is with other devices of the set L as well, and unknowingly so. This obviously violates sound security practice. • ‘Switchboard problem’. If the binding between the local device Id and the global device Id is incorrectly received (e. g. , 2 entries are interchanged) a device might direct information to the improper device and so compromise the intended security. Remark (generalization of threat scenario) This property also holds in other settings where a key-generating party does not share complete and authentic information on the composition of the key-sharing group itself with the other members of this group. Submission 35 Rene Struik, Certicom Corp.

March, 2002 doc. : IEEE 802. 15 -02/000 r 0 Access Control to the Piconet (2 a) Corollary (Effect of improper device list in broadcast scenario - the scenario of Draft D 09) Assume the following scenario: • All devices in the piconet share a common broadcast key; • The list of admitted devices to the piconet is L: ={(local 8 -bit device Id, global 48 -bit device Id)}. Then failure to obtain the complete and authentic list of admitted devices has the following consequences: • ‘Fly on the wall’. If a device obtains an incomplete list L’ L (L’ L) of admitted devices, all devices in the complementary set L L’ are ‘invisible’ to the device. Hence, the device might mistakenly think to share secured information only with devices from the list L’, whereas actually it is with other devices of the set L as well, and unknowingly so. This obviously violates sound security practice. Intended behavior: to A, PNC 0 1 C wants to broadcast info based on his local address book 3 PNC C Submission A Actual behavior: to A, B, PNC list Global Id Local Id 0 1 A 0 x 314159 0 x 01 B 0 x 271739 0 x 02 C 0 x 456123 0 x 03 3 2 C’s local list PNC A Global Id Local Id A 0 x 314159 0 x 01 C B C 0 x 456123 36 0 x 03 Rene Struik, Certicom Corp.

March, 2002 doc. : IEEE 802. 15 -02/000 r 0 Access Control to the Piconet (2 b) Corollary (Effect of improper device list in broadcast scenario - the scenario of Draft D 09) Assume the following scenario: • All devices in the piconet share a common broadcast key; • The list of admitted devices to the piconet is L: ={(local 8 -bit device Id, global 48 -bit device Id)}. Then failure to obtain the complete and authentic list of admitted devices has the following consequences: • ‘Switchboard problem’. If the binding between the local device Id and the global device Id is incorrectly received (e. g. , 2 entries are interchanged) a device might direct information to the improper device and so compromise the intended security. Intended behavior: to A C wants to send info to A, based on his local address book Submission Actual behavior: to B 0 1 3 2 PNC A C B 3 37 2 PNC list Global Id Local Id A 0 x 314159 0 x 01 B 0 x 271739 0 x 02 C 0 x 456123 0 x 03 C’s local list Global Id Local Id A 0 x 314159 0 x 02 B 0 x 271739 0 x 01 C 0 x 456123 0 x 03 Rene Struik, Certicom Corp.

March, 2002 doc. : IEEE 802. 15 -02/000 r 0 Access Control to the Piconet (3) Consequences (Effect of improper device lists on security policy) According to the security policy, “changes to the group structure shall invoke a change to the common group keys. ” This rule can only be enforced if each device takes one of the following two stands: • Completely rely on the PNC and on all key generating devices for key-sharing groups to which he belongs, to provide up-to-date and authentic information on the current group composition. This requires a complete dependency on the key generating devices and on the PNC. • Maintain up-to-date and authentic information on ‘aliveness’ of devices with whom the device shares keying material himself. This requires no reliance on the key generating devices, nor on the PNC. It does, however, require regular re-authentication of all key-sharing devices (similar to the ‘heartbeat’ scenario the devices and the PNC have to perform to verify each other’s ‘aliveness’, as specified in Draft D 09). Solution Since complete trust in a moving PNC is not realistic in all usage scenarios, this threat can only be diverted properly as follows: • Each device generates its own keys for its intended audience; • Each device regularly performs a ‘heartbeat’ function, to obtain semi-continuous authentication information. The centralized security model from Draft D 09 is therefore completely flawed for general scenarios. Submission 38 Rene Struik, Certicom Corp.

March, 2002 doc. : IEEE 802. 15 -02/000 r 0 The Need for a Distributed Security Model The centralized security model from Draft D 09 is completely unacceptable from a security perspective, even in the ‘authentic’ mode of operation. I. Centralized security model (Mapping of roles to devices as in Draft D 09) The Security Manager role is identified with the current PNC for all devices, hence one has the following: • Concentration of all trust in 1 device: - each device must trust the same Security Manager (PNC); - each device must trust each subsequent Security Manager (PNC). • Change of PNC invokes by definition a change of Security Manager: - potentially expensive re-establishment of keying relationship between devices and the Security Manager. • At any given moment in time, the PNC must provide each piconet device with complete and authentic information on the current composition of the piconet membership (in reality: at regular time intervals). II. Distributed security model (Our proposed mapping of roles to devices) The Security Manager role is identified with each individual device, hence one has the following: • No reliance on other devices for trust functionality: - each device need only trust himself as Security Manager. • Change of PNC does not invoke any change of Security Manager. • At any given moment in time, each device must re-authenticate with each of its key sharing parties, to obtain ‘aliveness’ guarantees (in reality: at regular time intervals). Submission 39 Rene Struik, Certicom Corp.

March, 2002 Protection of Messages (1) doc. : IEEE 802. 15 -02/000 r 0 Unsecured transport: 1. Initial set-up: 2. Message: 3. Security services: none A B: msg none Secure transport: 1. Initial set-up: 2. Message: 3. Security services: Establishment of shared data encryption key between A and B A B: Encryptkey (msg) Secure transfer of message msg Authentic transport: 1. Initial set-up: 2. Message: 3. Security services: Establishment of shared data integrity key between A and B A B: msg, hashkey (msg) Authentic transfer of message msg Secure and authentic transport: 1. Initial set-up: 2. 3. Message: Security services: Submission Encryptkey: encryption function hashkey: keyed hash function Establishment of shared encryption key 1 between A and B Establishment of shared data integrity key 2 between A and B A B: msg 1 || Encryptkey 1 (msg 2 || hashkey 2 (msg 1 || msg 2)) Authentic transfer of messages msg 1 and msg 2 Secure transfer of message msg 2 40 Rene Struik, Certicom Corp.

March, 2002 Protection of Messages (2) doc. : IEEE 802. 15 -02/000 r 0 Assumptions on capabilities: 1. Sender A should be able to encrypt messages and to compute keyed hash functions hereover. 2. Recipient B should be able to decrypt messages and to verify keyed hash values. 3. 4. 5. 6. 7. Header info can be bound to message to be authenticated if needed, e. g. , Algorithm Ids: specifies the particular cryptographic primitives used; Key Ids: prevents use of improper data keys; Sequence No. : prevents undetected reordering (or replay) of message frames; Message length: prevents misalignment in decryption and verification process. 8. Example 1 (secure and authentic key transfer from A to group G) Key originator: A authentic Key-sharing group: G (this includes A and B) authentic (implicit if peer-to-peer only) Group Id: 0 x 123456 authentic (implicit if peer-to-peer only) Key Id: 0 x 314159 authentic Key usage: data encryption authentic Piconet Id: 0 x 112358 authentic (sent in ‘beacon’) Algorithm Ids: 0 x (e. g. , AES 128 -CBC; HMAC-256) authentic (sent in ‘beacon’) Key recipient: B authentic (optional) Id key encryption key 1 (shared between A and B) authentic Id key integrity key 2 (shared between A and B) authentic Key value: k secure and authentic Submission 41 Rene Struik, Certicom Corp.

March, 2002 doc. : IEEE 802. 15 -02/000 r 0 Protection of Messages (2 a) Example 1 (secure and authentic key transfer from A to group G) Define HDR= Key originator: A Key-sharing group: G {wrap with ‘Multicast’ field (since more Group Id: 0 x 123456 than one recipient possible)} Key Id: 0 x 314159 Key usage: data encryption Piconet Id: 0 x 112358 (sent in ‘beacon’) Algorithm Ids: 0 x (e. g. , AES 128 -CBC; HMAC-256) (sent in ‘beacon’) Define for each recipient B contained in group G MSG 1(B)= Key recipient: B Id key encryption key 1 (shared between A and B) Id key integrity key 2 (shared between A and B) MSG 2(B)= Key value: k KEY UPDATE COMMAND STRUCTURE= HDR MSG 1(B) || Encryptkey 1(AB) (MSG 2(B) || hashkey 2(AB) (HDR || MSG 1(B)|| MSG 2(B)) | | MSG 1(C) || Encryptkey 1(AC) (MSG 2(C) || hashkey 2(AC) (HDR || MSG 1(C)|| MSG 2(C)) || etc. Submission 42 Rene Struik, Certicom Corp.

March, 2002 Protection of Messages (3) doc. : IEEE 802. 15 -02/000 r 0 Example 2 (command transfer between ordinary device and PNC) Unsecured transfer: -Association/disassociation commands; -Cryptographic protocol messages (including entity authentication, authenticated key agreement, key transfer, and challenge response protocols); -The election process of a new PNC. Authentic transfer: All other commands that affect the allocation of scarce resources in the piconet (if piconet is operating in one of the secure modes of operation). Submission 43 Rene Struik, Certicom Corp.

March, 2002 doc. : IEEE 802. 15 -02/000 r 0 Mutual Public Key Authenticated Key Agreement Protocol (1) Initial Set-up • Publication of system parameters of public key systems A and B • Publication of keyed hash function hk • Distribution of authentic public keys PA and PB Constraints • RNDA and RNDB random • SA and SB private to Party A, resp. Party B • Public keys PA and PB valid and authentic during execution of protocol authentic channel PA A PB B Security Services (see 2 a) • Key agreement on the shared key K • Mutual entity authentication of A and B • Mutual explicit key authentication (if hk is secure) • Known-key resilience • Perfect forward secrecy • No key control by either party A Submission secret and authentic channel KAB 44 B Rene Struik, Certicom Corp.

March, 2002 doc. : IEEE 802. 15 -02/000 r 0 Mutual Public Key Authenticated Key Agreement Protocol (2) (1) generate random number RNDA GA, [Id. A, Cert. T(Id. A , PA)] (1) generate random number RNDB (2) compute ‘exponent’ GB= FB (RNDB) (2) compute ‘exponent’ GA= FA (RNDA) (3) compute key K=f(GA, RNDB, PA, SB) (3 a) Verify the authenticity of (PA, , Id. A) binding LOCAL ADDRESSING DELETED (1) compute key K=f(RNDA, , GB SA, PB) hash. B, , GB, , [Id. B, , Cert. T(Id. B PB)] (2) compute hash over the string (GB||GA ||Id. A) using keyed hash function h. K with key K, to yield string hashverify. B K= f(GA, RNDB, PA, SB) = f(RNDA, GB, SA, PB) Public-private key pair A: (PA, SA) Public-private key pair B: (PB, SB) FA, FB: (trapdoor) one-way functions of A, resp. B (3) verify whether hash. B=hashverify. B (3 a) Verify the authenticity of (PB , Id. B) binding (4) compute hash over the string (GA||GB ||Id. B) using keyed hash function h. K with key K, to yield string hash. A Submission (4) compute hash over the string (GB ||GA ||Id. A) using keyed hash function h. K with key K, to yield string hash. B hash. A (1) compute hash over the string (GA ||GB ||Id. B) using keyed hash function h. K with key K, to yield string hashverify. A (2) verify whether hash. A=hashverify. A 45 Rene Struik, Certicom Corp.

March, 2002 doc. : IEEE 802. 15 -02/000 r 0 Mutual Symmetric Key Entity Authentication Protocol (1) Initial Set-up • Publication of keyed hash function hk • Establishment of shared symmetric key KAB between A and B Constraints • RNDA and RNDB random • KAB secret to Party A, resp. Party B secret and authentic channel KAB A B Security Services (see 2 a) • Mutual entity authentication of A and B authentic channel Id. A A Submission Id. B 46 B Rene Struik, Certicom Corp.

March, 2002 doc. : IEEE 802. 15 -02/000 r 0 Mutual Symmetric Key Entity Authentication Protocol (2) (1) GA (2) generate random ‘exponent’ GA (1) (2) generate random ‘exponent’ GB (3) [retrieve shared key K] LOCAL ADDRESSING DELETED (1) [retrieve shared key K] hash. B, , GB (2) compute hash over the string (GB||GA ||Id. A) using keyed hash function h. K with key K, to yield string hashverify. B (4) compute hash over the string (GB ||GA ||Id. A) using keyed hash function h. K with key K, to yield string hash. B (3) verify whether hash. B=hashverify. B (4) compute hash over the string (GA||GB ||Id. B) using keyed hash function h. K with key K, to yield string hash. A Submission hash. A (1) compute hash over the string (GA ||GB ||Id. B) using keyed hash function h. K with key K, to yield string hashverify. A (2) verify whether hash. A=hashverify. A 47 Rene Struik, Certicom Corp.

March, 2002 doc. : IEEE 802. 15 -02/000 r 0 Combined Key Agreement and Entity Authentication Protocol Implementation issues • Efficient implementation possible (for public key system) • No usage constraints • Channel should be simplex channel both ways Flexibility • No restrictions between cryptographic building blocks (in particular, good fit for ECC) • Full scalability (PKI-like) • Survivability, since no status information maintained Alternative uses using same implementation • Mutual Public Key Authenticated Key Agreement Protocol • Unilateral Public Key Authenticated Key Agreement Protocol • One-Pass Public Key Authenticated Key Agreement Protocol (in DL Scenario) • Mutual Symmetric Key Entity Authentication Protocol • Unilateral Symmetric Key Entity Authentication Protocol Example (uses of protocols in WPAN setting) • Authenticated association: Mutual Public Key Authenticated Key Agreement Protocol • ‘Heartbeat’ functionality: Unilateral or Mutual Symmetric Key Entity Authentication Protocol Submission 48 Rene Struik, Certicom Corp.

March, 2002 doc. : IEEE 802. 15 -02/000 r 0 Operational Description - Informational Elements (1) Informational elements (provided by device itself) (1) Global device Ids. Each device has own static global device Id (48 -bit IEEE MAC address). (2) Public keys. Each device has its own public/private key pair (PA, SA). {The public key PA need not to be stored on the device itself. } (3) Trust. Sets. Each device has own set of devices it trusts to assume the role of security manager. (4) Access control lists (ACLs). Each device has own set of devices it may establish a secure peer-to-peer link with. Informational elements (provided by other devices) (1) Global device Ids. Each device may have access to static global device Ids (48 -bit IEEE MAC Address) of other devices. (2) Public keys. Each device may have access to public keys of other devices. Submission 49 Rene Struik, Certicom Corp.

March, 2002 doc. : IEEE 802. 15 -02/000 r 0 Operational Description - Informational Elements (2) Informational elements (provided by piconet in which device partakes) (1) Local device Ids. Each device has dynamic local device Id (8 -bit local piconet address); assigned by piconet (controller), upon admittance to piconet. (2) Piconet Id. Each device has access to a piconet Id (48 -bit random PNID); assigned by piconet (controller). (3) Piconet Device. List. Each device has set of admitted devices to the piconet (obtained from PNC). Device. List: ={(local 8 -bit device Id, global 48 -bit device Id)}. Informational elements (provided by trusted party of device) (1) Public key certificates. Each device may have access to certificates, provided by a trusted third party T: (a) Digital certificates. Certificate Cert. T(Id. B, PB), together with signature verification key PT. {Two choices: ordinary certificate, implicit certificate. } (b) Manual certificates. Certificate User. T(Id. B, PB), together with info on way binding was established. {pushing button, low power mode, etc. }. Submission 50 Rene Struik, Certicom Corp.

March, 2002 doc. : IEEE 802. 15 -02/000 r 0 The 802. 15. 3 WPAN at Work (1) Device. List : ={A, B, C, D, E, F, G, H} Trust. Set(A): ={A, B, C} Groups in which A participates: A B C D E F G H Group 1’ x x x Key source: C encryption/decryption Group 2’ x x Key Source: D decryption Fig 1. Group structures as seen by A Key Usage Rules: (1) A accepts all keys transferred to him by others, for decryption purposes: (2) A only accepts keys transferred to him by devices DEV Trust. Set(A), for encryption purposes Consequences: (1) A uses Group 1’ group key for encryption/decryption; Group 2’ group key for decryption only. (2) If A wants to communicate to Group 2’ members, he should generate a new group key and distribute these to the members of Group 2’: {ED(key) || Ekey(msg)} Group 1 Group 2 Group 3 Submission A B C D E F G H x x x Key source: C encryption/decryption x x $ Key Source: D decryption x x Key source: A encryption/decryption Fig 2. Group structures, as actually realized 51 Rene Struik, Certicom Corp.

March, 2002 doc. : IEEE 802. 15 -02/000 r 0 The 802. 15. 3 WPAN at Work (2) Device. List : ={A, B, C, D, E, F, G, H} Trust. Set(A): =Universe (since A is an altruistic device) Trust. Set(D): ={D} (since D is an egocentric device) {Centralized model} {Decentralized model} Groups in which A participates: A B C D E F G H A D Group 1’ x x x Key source: C encryption/decryption Group 2’ x x x Key Source: G encryption/decryption decrypt Group 3’ x x Key Source: E decrypt Fig 1. Group structures as seen by A and D Consequences: (1) A uses all group keys for encryption/decryption (since A is an altruistic device) (2) D uses group keys for decryption purposes only (since B did not generate these himself) Group 1 Group 2 Group 3’ A B C D E F G H A x x x Key source: C encryption/decryption x x $ x Key Source: G wrong view of group! x x Key Source: E Fig 2. Group structures, as actually realized D does not matter $: hidden node (‘fly on the wall’) Submission 52 Rene Struik, Certicom Corp.

March, 2002 doc. : IEEE 802. 15 -02/000 r 0 The 802. 15. 3 WPAN at Work (3) Distributed Security Model (1) Admission to the piconet. PNC regulates access of device to the piconet, based on - proper device Id; - other info (e. g. , from access control list). (2) Access to actual information. Security manager regulates access of group of devices to information, based on - proper device Id; - other info (e. g. , from access control list). User scenario (Starbucks): 1. Admission to the piconet based on charging airtime/bandwidth fee (similar to that for cell phones). 2. Admission to information based on charging for content: a. Fixed PNC in ceiling: - multicast to subscribing devices only; - logical separation of content in different subscription packages. b. Devices to devices: - up to local devices. Note: separation of the role of PNC and that of security manager allows charging models that differentiate between airtime/bandwidth cost & content/subscription cost. These charging models might be operated by different entities. Similar: piconet in fitness club, movie theatre, casino Submission 53 Rene Struik, Certicom Corp.