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: [MAC Distributed Security Proposal] Date Submitted: [22 February, 2002] Source: [Rene Struik] Company [Certicom Corp.] Address [5520 Explorer Drive, 4th Floor, Mississauga, ON Canada L4W 5L1] 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 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. Rene Struik, Certicom Corp.

2. MAC Distributed Security Proposal Gregg Rasor, Motorola René Struik, Certicom Research Scott Vanstone, Certicom Research Rene Struik, Certicom Corp.

3. 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 Rene Struik, Certicom Corp.

4. 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. Rene Struik, Certicom Corp.

5. 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 (QoS); • - 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. Rene Struik, Certicom Corp.

6. 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). Rene Struik, Certicom Corp.

7. Devices and their Roles (1) • 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. Rene Struik, Certicom Corp.

8. Devices and their Roles (2) • 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). Rene Struik, Certicom Corp.

9. Devices and their Roles (3) • ‘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 0x00. Rene Struik, Certicom Corp.

10. Devices and their Roles (4) 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 D09) The Draft D09 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. Rene Struik, Certicom Corp.

11. Security Policy (1) 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. 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). Rene Struik, Certicom Corp.

12. Security Policy (2) 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. Rene Struik, Certicom Corp.

13. Security Policy (3) 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). Rene Struik, Certicom Corp.

14. 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 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). Rene Struik, Certicom Corp.

15. Access Control to the Piconet (2) • Corollary (Effect of improper device list in broadcast scenario - the scenario of Draft D09) • 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. Rene Struik, Certicom Corp.

16. Intended behavior: to A, PNC Actual behavior: to A, B, PNC PNC list Global Id Local Id A 0x314159 0x01 B 0x271739 0x02 C 0x456123 0x03 Global Id Local Id A 0x314159 0x01 C 0x456123 0x03 0 1 3 2 C wants to broadcast info based on his local address book 0 1 3 C’s local list PNC A C PNC A C B Access Control to the Piconet (2a) • Corollary (Effect of improper device list in broadcast scenario - the scenario of Draft D09) • 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. Rene Struik, Certicom Corp.

17. Intended behavior: to A Actual behavior: to B PNC list Global Id Local Id A 0x314159 0x01 B 0x271739 0x02 C 0x456123 0x03 Global Id Local Id A 0x314159 0x02 B 0x271739 0x01 C 0x456123 0x03 0 1 3 2 C wants to send info to A, based on his local address book 0 1 3 2 PNC A C B C’s local list PNC A C B Access Control to the Piconet (2b) • Corollary (Effect of improper device list in broadcast scenario - the scenario of Draft D09) • 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. Rene Struik, Certicom Corp.

18. 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 D09). • 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 D09 is therefore completely flawed for general scenarios. Rene Struik, Certicom Corp.

19. The Need for a Distributed Security Model The centralized security model from Draft D09 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 D09) • 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 trusteach 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). Rene Struik, Certicom Corp.

20. Encryptkey: encryption function hashkey: keyed hash function Protection of Messages (1) • Unsecured transport: • Initial set-up: none • Message: A  B: msg • Security services: none • Secure transport: • Initial set-up: Establishment of shared data encryption key key between A and B • Message: A  B: Encryptkey (msg) • Security services: Secure transfer of message msg • Authentic transport: • Initial set-up: Establishment of shared data integrity key key between A and B • Message: A  B: msg, hashkey (msg) • Security services: Authentic transfer of message msg • Secure and authentic transport: • Initial set-up: Establishment of shared encryption key key1between A and B • Establishment of shared data integrity key key2between A and B • Message: A  B: msg1 || Encryptkey1 (msg2 || hashkey2 (msg1 || msg2)) • Security services: Authentic transfer of messages msg1 and msg2 • Secure transfer of message msg2 Rene Struik, Certicom Corp.

21. Protection of Messages (2) • Assumptions on capabilities: • Sender A should be able to encrypt messages and to compute keyed hash functions hereover. • Recipient B should be able to decrypt messages and to verify keyed hash values. • 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. • Example 1 (secure and authentic key transfer) • Key originator: A authentic • Key-sharing group: G (this includes A and B) authentic (implicit if peer-to-peer only) • Key Id: 0x314159 authentic • Key usage: data encryption authentic • Key mode: pre-operational authentic • Piconet Id: 0x112358 authentic (sent in ‘beacon’) • Key recipient: B authentic (optional) • Id key encryption key KAB(1)(shared between A and B)authentic • Id key integrity key KAB(2)(shared between A and B) authentic • Key value: k secure and authentic Rene Struik, Certicom Corp.

22. Protection of Messages (3) 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). Rene Struik, Certicom Corp.

23. authentic channel PA A B PB A B KAB 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 • SAand SB private to Party A, resp. Party B • Public keys PAand PB valid and authentic during execution of protocol • Security Services • 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 secret and authentic channel Rene Struik, Certicom Corp.

24. GA (1) compute key K=f(RNDA,,GBSA,PB) (3) compute key K=f(GA,RNDB, PA,SB) (1) generate random number RNDA (2) compute ‘exponent’ GA= FA (RNDA) (1) generate random number RNDB (2) compute ‘exponent’ GB= FB (RNDB) hashB, IdA, GB (4) compute hash over the string (GA||GB||IdB) using keyed hash function hK withkey K, to yield string hashA (4) compute hash over the string (GB ||GA ||IdA) using keyed hash function hK withkey K, to yield string hashB (2) compute hash over the string (GB||GA||IdA) using keyed hash function hK withkey K, to yield string hashverifyB (3) verify whether hashB=hashverifyB Mutual Public Key Authenticated Key Agreement Protocol (2) 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 (1) compute hash over the string (GA ||GB||IdB) using keyed hash function hK withkey K, to yield string hashverifyA (2) verify whether hashA=hashverifyA hashA, IdB Rene Struik, Certicom Corp.

25. A B KAB authentic channel IdA A B IdB secret and authentic channel Mutual Symmetric Key Entity Authentication Protocol (1) • Initial Set-up • Publication of keyed hash function hk • Establishment of shared symmetric key KABbetween A and B • Constraints • RNDA and RNDB random • KAB secret to Party A, resp. Party B • Security Services • Mutual entity authentication of A and B Rene Struik, Certicom Corp.

26. GA (1) [retrieve shared key K] (3) [retrieve shared key K] (1) (2) generate random ‘exponent’ GA (1) (2) generate random ‘exponent’ GB hashB, IdA, GB (4) compute hash over the string (GA||GB||IdB) using keyed hash function hK withkey K, to yield string hashA (4) compute hash over the string (GB ||GA ||IdA) using keyed hash function hK withkey K, to yield string hashB (2) compute hash over the string (GB||GA||IdA) using keyed hash function hK withkey K, to yield string hashverifyB (3) verify whether hashB=hashverifyB Mutual Symmetric Key Entity Authentication Protocol (2) (1) compute hash over the string (GA ||GB||IdB) using keyed hash function hK withkey K, to yield string hashverifyA (2) verify whether hashA=hashverifyA hashA, IdB Rene Struik, Certicom Corp.

27. 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 Rene Struik, Certicom Corp.

28. ECC-Based Public Key Cryptography (1) • Cipher suite selection criteria • Security • Sufficient scrutiny by the cryptographic community and acceptance hereby • Quantification of security level provided • Endorsement by standardization bodies and government agencies • Performance metrics on constrained devices • Speed • Footprint • Battery drain Rene Struik, Certicom Corp.

29. ECC-Based Public Key Cryptography (2) • Key size comparison • Block cipher Skipjack 3DES AES-small AES-medium AES-high • Bit security 80 112 128 192 256 • ECC size (prime) 192 224 256 384 521 • ECC size (binary) 163 233 283 409 571 • Sources: • -ANSI X9.30-1997 • -FIPS Pub 186-2, Appendix 6 • ECC curve K-283 conforms with ANSI X9.62, IEEE P1363, WAP • recommended by ANSI X9.63, echeck, IPSec, NIST • MQV Key Agreement: 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 • Numerous deployments of ECC certificates Rene Struik, Certicom Corp.

30. 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) Rene Struik, Certicom Corp.

31. The 802.15.3 WPAN at Work (2) • DeviceSet :={A,B,C,D,E,F,G,H} • TrustSet(A):=Universe (since A is an altruistic device) {Centralized model} • TrustSet(D):={D} (since D is an egocentric device) {Decentralized model} • Groups in which A participates: • A B C D E F G H A D • Group1’ x x x Key source: C encryption/decryption • Group2’ x x x Key Source: G encryption/decryption decrypt • Group3’ x x Key Source: E decrypt • Fig 1. Group structures as seen by A and D • Consequences: • A uses all group keys for encryption/decryption (since A is an altruistic device) • D uses group keys for decryption purposes only (since B did not generate these himself) • A B C D E F G H A D • Group1 x x x Key source: C encryption/decryption • Group2 x x$ x Key Source: G wrong view of group! does not matter(*) • Group3’ x x Key Source: E does not matter(*) • Fig 2. Group structures, as actually realized • $: hidden node (‘fly on the wall’) • (*) provided device D regularly polls the members of the group whether these are still alive (heartbeat) Rene Struik, Certicom Corp.

32. 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 device:P - 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 Rene Struik, Certicom Corp.