1. doc.: IEEE 802.15-02030r0 Submission December, 2001 Rene Struik, Certicom Corp.Slide 1 Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Security Architectural Issues for the 802.15.3 Wireless Personal Area Network] Date Submitted: [22 January, 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.

2. doc.: IEEE 802.15-02030r0 Submission December, 2001 Rene Struik, Certicom Corp.Slide 2 Security Architectural Issues for the 802.15.3 WPAN René Struik Certicom Research (rstruik@certicom.com)

3. doc.: IEEE 802.15-02030r0 Submission December, 2001 Rene Struik, Certicom Corp.Slide 3 Outline System overview - Refined access control mechanisms Devices and their roles - Review (also for further discussion during the day) Trust in the piconet - Relaxation of trust requirements - Multi-casting [enough for ½ day presentation…]

4. doc.: IEEE 802.15-02030r0 Submission December, 2001 Rene Struik, Certicom Corp.Slide 4 System overview – device level Binding information (device level) Device & device Id: physical tying of device to its identity (to prevent identity theft) Established at manufacturing stage Device Id & public key: cryptographic binding between the public key and the device’s identity (e.g., via a public key or implicit certificate) Established at manufacturing stage or generated internally and registered with trusted third party User & device: binding between device and its user, via authentication techniques (e.g., password, PIN code, biometrics) Established at personalization of the device or prior to operational use (e.g., PIN initialization) Device Id & device attributes: binding between the device Id and personalization attributes (e.g., via attribute certificate) Established at personalization of the device User & user attributes: binding between a user and personalization attributes hereof (e.g., via attribute certificate) Established at personalization of the device or at registration of the user with trusted third party Attribute certificate Public key certificate user A A Id A PAPA attr A password Physical embedding Not in draft D09

5. doc.: IEEE 802.15-02030r0 Submission December, 2001 Rene Struik, Certicom Corp.Slide 5 System overview – piconet level Binding information (piconet level) Basic binding information Device association: via non-cryptographic means Device authentication: evidence as of true device identities via -non-cryptographic techniques (if piconet in ‘no security’ mode) -mutual entity authentication (if piconet in ‘authentication only’ mode) -authenticated key establishment (if piconet in ‘authentication and encryption’ mode) Optionally authenticated key establishment or authenticated key transfer as well Realized via use of, e.g., a public key or implicit certificate Device authorization: additional access control based upon true user/usage of devices via, e.g., attribute certificate and access control lists maintained by each device Realized at personalization of the device or prior to operational use, with dynamic updates AB Entity authentication (optionally key establishment) Public Key directory Access control list A Access control list B Attribute certificates Not in draft D09

6. doc.: IEEE 802.15-02030r0 Submission December, 2001 Rene Struik, Certicom Corp.Slide 6 System overview – piconet level (cont’d) Binding information (piconet level) Derived binding information Key transport: transfer of authentic symmetric keying material (encryption key, integrity key) via key transport using public key or symmetric key techniques in each of the following ways: -broadcast mode -peer-to-peer mode † ( † : Not in draft D09) -multicast mode † Realized via use of, e.g., authentic public keys or via authentic key encryption key Message communication: secure transfer of messages via -no cryptographic techniques (unsecured transport); -confidentiality only (secure transport) -both confidentiality and integrity (secure and authentic transport) Realized via use of data encryption, data integrity, or combined cryptographic primitive Remark (maintenance of access control lists) With user interface: similar to, e.g., an ‘address book’ on a PDA or via a confirm/reject button Without user interface: e.g., at initialization or prior to operational use (the ‘resurrecting Duckling’ (Ross Anderson)).

7. doc.: IEEE 802.15-02030r0 Submission December, 2001 Rene Struik, Certicom Corp.Slide 7 System overview – inter-piconet level Binding information (inter-piconet level) Basic binding information Association: via non-cryptographic means (between piconet, child piconet, neighbor piconet) A B

8. doc.: IEEE 802.15-02030r0 Submission December, 2001 Rene Struik, Certicom Corp.Slide 8 Devices and their roles 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 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

9. doc.: IEEE 802.15-02030r0 Submission December, 2001 Rene Struik, Certicom Corp.Slide 9 Devices and their roles (cont’d) 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, more than 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. Remark (dynamic vs. static mappings) 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).

10. doc.: IEEE 802.15-02030r0 Submission December, 2001 Rene Struik, Certicom Corp.Slide 10 Devices and their roles (cont’d) Mapping of roles to devices Static mapping of roles to devices Draft D09 document uses static mapping (since local address of PNC is fixed as 0x00): PNC assumes the role of Security Manager (for all devices) Each device assumes the role of ordinary device (for all devices) Each device may assume the role of (alternate) PNC There are no other mappings of roles to devices in effect. Remarks (static mapping) The Security Manager is identified with the current PNC for all devices, hence one has Concentration of all trust in one 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 change of Security Manager: - potentially expensive re-establishment of keying relationship between devices and the Security Manager.

11. doc.: IEEE 802.15-02030r0 Submission December, 2001 Rene Struik, Certicom Corp.Slide 11 Trust in the piconet Mapping of roles to devices (implied trust) Static mapping of roles to devices (as in draft D09) PNC Ordinary device A trusts B AB (1)(2) (3) (1)Situation before PNC handover (2)Disappearance of the directed trust graph pointing to the PNC, at handover of tasks (3)Re-establishment of the directed trust graph pointing to the new PNC, after PNC has assumed its tasks Notes Expensive re-keying requirement for the new PNC (once a key change is needed). Unclear whether all devices should trust the new PNC. (NB: Trust from A to B does not imply trust from B to A (trust relationship is non-symmetric!!!))

12. doc.: IEEE 802.15-02030r0 Submission December, 2001 Rene Struik, Certicom Corp.Slide 12 Trust in the piconet (cont’d) Mapping of roles to devices (implied trust) Static mapping of roles to devices (as in draft D09) A1A1 PNC A2A2 A3A3 A4A4 k k k k All devices A 1, …, A 4 trust the PNC in the following sense: The devices trust that the key k distributed by the PNC was generated securely (by PNC or another device); (2)The devices trust that the PNC does not expose key k to any entity outside the group {A 1,…,A 4 }. Hence, the PNC is both a trusted key source and a trusted key distributor. The implied trust is that none of the other devices leaks any information on the key k. AB kGeneralization (1) If B sends A the key k intended for group G, this indicates that B trusts A not to expose the key k to entities outside the group G. (2) B only sends A the key k if A is a member of the group G. (3) If A trusts B, then A accepts the key k communicated by B both as encryption key and as decryption key for group G. (4) If A does not trust B, then A accept the key k communicated by B only for decryption purposes (and does not care about the group G). Note. This generalization is consistent with the hierarchical trust model in draft D09. (here, G is a group of recipients)

13. doc.: IEEE 802.15-02030r0 Submission December, 2001 Rene Struik, Certicom Corp.Slide 13 Trust in the piconet (cont’d) Mapping of roles to devices (implied trust) Dynamic mapping of roles to devices (generalization of draft D09 to the case where there is no common Security Manager) Trust relationships Each device maintains a list of all the devices that it trusts. This list always includes the device itself. Rules 1.Each device trusts the secure storage and processing of all devices. 2.Each device trusts the external third party. 3.Only devices that are instructed to forward a key, shall do so. Whenever a device A wants to send a key to subgroup G of the piconet and does not have such a key yet, it proceeds as follows (we assume A to be contained in group G): 1.A requests a key from one of the devices it trusts, and provides this device, B say, with an authentic indication of the group G the key is intended for. (B must be contained in group G.) 2.B securely generates a key and forwards this, in some secure fashion, to each of the devices in group G individually (with the instruction not to forward this further). 3. Alternatively, B may adopt the procedure in (2), but send the key, in some secure fashion, to a subgroup S of devices in G only and instruct the (nonempty subset of) devices among these in S that he trusts to forward the key to the (remainder of the) group G.

14. doc.: IEEE 802.15-02030r0 Submission December, 2001 Rene Struik, Certicom Corp.Slide 14 Trust in the piconet (cont’d) The presented algorithm describes a way to securely multicast a key k to an arbitrary nonempty group G of devices, provided that each device involved in forwarding the key can unambiguously reconstruct from the group G the true identities of the devices in question. Note. This unambiguous correspondence between the set G and the true identities of these devices is trivial in the broadcast scenario and the peer-to-peer scenario. For the general multicast scenario, it requires each device to maintain an authentic list of local device address/IEEE MAC correspondences. Step (3) of the algorithm allows the key distribution to take place concurrently. Obviously, devices that already obtained the key, can be excluded from the set G. The advantage of distributing the workload of processing keys over more than one processor is that ‘expensive’ public key operations, potentially involved in the algorithm are then also executed in parallel. The expected ‘depth’ of the key distribution algorithm is a few iterations (roughly O(log2(#N)) if each device has a few devices it trusts). The advantage of this approach is that in the event of a PNC hand over, this workload compares very favorable with the expensive re-keying step that would be required in the more rigid scenario described in draft D09. Thus, the piconet security framework becomes more robust. A third advantage of the algorithm presented here is that it does not require devices to compulsory trust a device that somehow becomes PNC.

15. doc.: IEEE 802.15-02030r0 Submission December, 2001 Rene Struik, Certicom Corp.Slide 15