1. IEEE 802.15.3-02/121r1 Submission 27 February 2002 B. Huang, D. Bailey, G. Rasor, R. Struik, M. Welborn Sony, NTRU, Motorola, Certicom, XtremeSpectrum Slide 1 Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs) Submission Title: Security Sub-committee Status Report Date Submitted: 28 Feb, 2002 Source: Bob Huang, Dan Bailey, Gregg Rasor, Rene Struik, Matthew Welborn Company: Sony, NTRU, Motorola, Certicom, XtremeSpectrum Address One Sony Drive TA3-12, Park Ridge, NJ 07656 Voice:201-358-4409, FAX: 201-9306397, E-Mail:robert.huang@am.sony.com Re: P802.15.3, IEEE 802.15.3-02/121r0 Abstract:Reports the agreements that security sub-committee reached during the February 2002 ad hoc meeting in Schaumburg, IL. These agreements were reach considering the three security proposals presented on 25 February 2002. This revision submitted 10 March 2002. Purpose:For information, guidance and endorsement by 802.15.3 prior to considering the Security Suite proposals and complete standards texts at the March plenary meeting of 802.15.3. 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. IEEE 802.15.3-02/121r1 Submission 27 February 2002 B. Huang, D. Bailey, G. Rasor, R. Struik, M. Welborn Sony, NTRU, Motorola, Certicom, XtremeSpectrum Slide 2 Background Ad hoc security sub-committee met with the goal providing the St. Louis Plenary session with information that compares and contrasts the Security Suite proposals –Identify areas of agreement –Identify areas with different approach –Identify impact of different approaches The security sub-committee received guidance from the larger group: security goals at slide 4

3. IEEE 802.15.3-02/121r1 Submission 27 February 2002 B. Huang, D. Bailey, G. Rasor, R. Struik, M. Welborn Sony, NTRU, Motorola, Certicom, XtremeSpectrum Slide 3 Background (cont.) Overviews of three security suite proposals –Were presented at the ad hoc meeting –Provided the base material for sub-committee work The proposals 02106r0P802-15_TG3-Overview-of-NTRU-Security-Suite.ppt 02107r0P802-15_TG3-Protocols-in-NTRU-Security-Suite.ppt 02108r0P802-15_TG3-Performance-and-Security-of-NTRU- Security-Suite.ppt 02111r0P802- 15_TG3_WPAN_Security_Framework_Proposal.doc 02112r0P802- 15_TG3_Summary_of_WPAN_Security_Proposal.ppt 02114r0P802-15_TG3-MAC-Distributed-Security-Proposal.ppt

4. IEEE 802.15.3-02/121r1 Submission 27 February 2002 B. Huang, D. Bailey, G. Rasor, R. Struik, M. Welborn Sony, NTRU, Motorola, Certicom, XtremeSpectrum Slide 4 Security Goals Map similarities of all three proposals Establish key components: –Use cases –Trust Model –Threat models –Public key for authentication –Entity authentication –Symmetric key for data protection –Symmetric key update –Integrity for data protection –Protection of commands Non-goals: limiting the scope Limit the number of options for the whole group to consider

5. IEEE 802.15.3-02/121r1 Submission 27 February 2002 B. Huang, D. Bailey, G. Rasor, R. Struik, M. Welborn Sony, NTRU, Motorola, Certicom, XtremeSpectrum Slide 5 Use Cases Will pulled from Schaumburg presentations, shown in following slides –02106r0P802-15_TG3-Overview-of-NTRU- Security-Suite.ppt –02114r0P802-15_TG3-MAC-Distributed-Security- Proposal.ppt –Others may be added Perhaps in future rev to this doc None received by 10 March 2002

6. IEEE 802.15.3-02/121r1 Submission 27 February 2002 B. Huang, D. Bailey, G. Rasor, R. Struik, M. Welborn Sony, NTRU, Motorola, Certicom, XtremeSpectrum Slide 6 Now I’m taking my projector and laptop on the road I’m away from home, so more wary about other devices –A device with a rich user interface (laptop) becomes PNC –PNC prompts for enrollment mode: open, closed, or prompt –I choose prompt, and set my laptop’s “require intervention” switch –Projector has an “open acceptance/require intervention” switch. I choose require intervention Projector attempts secure association with Laptop –Both Projector and Laptop display both of their 48-bit MAC addresses and hashes of their public keys –I see that they match and press Accept on both I close enrollment on the PNC –Any device can still associate, but no new devices can authenticate Confidentiality, integrity, and access control needed Wireless Portable Projector/Laptop Use case: 02106r0P802-15_TG3-Overview-of-NTRU-Security-Suite Use Cases

7. IEEE 802.15.3-02/121r1 Submission 27 February 2002 B. Huang, D. Bailey, G. Rasor, R. Struik, M. Welborn Sony, NTRU, Motorola, Certicom, XtremeSpectrum Slide 7 Now I’m taking my Tablet PC to Starbucks For only 99 cents, I can watch transient video on demand –News, weather, sports. No DRM! –A fixed device in the ceiling is the PNC –PNC is in closed mode: only its DME can add trusted devices –I place my tablet on the cash register, pay, and they exchange public keys via low-power radio transmission –Cash register forwards ID/pub key to PNC’s DME Tablet attempts secure association with hot spot –If I paid, PNC’s DME added my tablet to its trusted list –My tablet displays PNC’s ID, hash of public key, and range. I accept. Confidentiality, integrity, and access control needed Portable LCD Tablet/Hot Spot Use case: 02106r0P802-15_TG3-Overview-of-NTRU-Security-Suite Use Cases

8. IEEE 802.15.3-02/121r1 Submission 27 February 2002 B. Huang, D. Bailey, G. Rasor, R. Struik, M. Welborn Sony, NTRU, Motorola, Certicom, XtremeSpectrum Slide 8 WLAN/WPAN Market Opportunities Use case: 02114r2P802-15_TG3-MAC-Distributed-Security-Proposal

9. IEEE 802.15.3-02/121r1 Submission 27 February 2002 B. Huang, D. Bailey, G. Rasor, R. Struik, M. Welborn Sony, NTRU, Motorola, Certicom, XtremeSpectrum Slide 9 Three identical cars, each with an active 802.15.3 piconet –Based on their security model, they don’t associate with each other. Owners use interface on their PDA to unlock their car and provide access to information while in their car. Passenger in a car may also have their own PDA in a friends car that they can use to set environmental controls or provide entertainment. PNC in vehicle must be able to authenticate devices for different purposes: –Owner access provides full control –Friend access provides limited access When all three owners pull out their PDAs to unlock their car, all cars respond quickly to only their owners. When a friend gets in a car he does not own, the owner allows him limited access so they can listen to the friends MP3 files on the PDA. Automotive Use Case (1) Use case: 02114r2P802- 15_TG3-MAC-Distributed- Security-Proposal

10. IEEE 802.15.3-02/121r1 Submission 27 February 2002 B. Huang, D. Bailey, G. Rasor, R. Struik, M. Welborn Sony, NTRU, Motorola, Certicom, XtremeSpectrum Slide 10 Three identical cars, each with an active 802.15.3 piconet –Based on their security model, they don’t associate with each other. When car drives into a gas station, the PNC in the car associates with the gas station PNC as a child piconet to allow limited information content to flow between the gas station and the vehicle. –Gas station piconet looks different than another car piconet? –Operator may need to select which pump from his PDA or dash. When car drives into owner’s garage, the PNC in the car associates with the home PNC as a child piconet with the ability to have full access to home systems in order to check security status of home for owner. –Car and garage must have some mutual authentication information. –Car may assume owner (driver) authentication from owner’s PDA. –Owner may have multiple cars which are in garage at same time. –There may be multiple owners of a car (husband, wife, children) Automotive Use Case (2) Use case: 02114r2P802- 15_TG3-MAC-Distributed- Security-Proposal

11. IEEE 802.15.3-02/121r1 Submission 27 February 2002 B. Huang, D. Bailey, G. Rasor, R. Struik, M. Welborn Sony, NTRU, Motorola, Certicom, XtremeSpectrum Slide 11 Three identical cars, each with an active 802.15.3 piconet –Based on their security model, they don’t associate with each other. When car drives into dealer service facility, the car’s piconet associates as a child piconet with the dealer’s system or employees –Employees have device that allows them to operate vehicle while in the care of the dealer. –Dealer diagnostic systems have access to vehicle information that may not be available to the car owner. –Owner private information and resources in the car not available to dealer. When car is dropped off with valet parking, the valet can be given a token that allows the car to be parked, secured, and located later. –Token may be transferred from owners PDA –Limited services available in the car while under control of valet –Owner can retrieve history of car operation while under control of the valet. –Valet token unique to each car in the parking facility. Automotive Use Case (3) Use case: 02114r2P802- 15_TG3-MAC-Distributed- Security-Proposal

12. IEEE 802.15.3-02/121r1 Submission 27 February 2002 B. Huang, D. Bailey, G. Rasor, R. Struik, M. Welborn Sony, NTRU, Motorola, Certicom, XtremeSpectrum Slide 12 Trust Model There is some trusted third party required –Disagree on what the form/extent of this is, but a single message framework has be agreed to –Two forms: Digital certificates User control mechanisms Topology –Central and distributed SM models can implement each other –Peer-to-peer security is implemented by all proposals –By parameterizing the number of keys that a device will support, both approaches can be supported by the MAC DEV trusts DME to maintain access control list

13. IEEE 802.15.3-02/121r1 Submission 27 February 2002 B. Huang, D. Bailey, G. Rasor, R. Struik, M. Welborn Sony, NTRU, Motorola, Certicom, XtremeSpectrum Slide 13 Trust Model Two forms: - Digital certificates - User control mechanisms Key Characteristics

14. IEEE 802.15.3-02/121r1 Submission 27 February 2002 B. Huang, D. Bailey, G. Rasor, R. Struik, M. Welborn Sony, NTRU, Motorola, Certicom, XtremeSpectrum Slide 14 Threat Models Agree on protections required against external threats (outside the piconet) Pull common points from presentations The things we most care about are: –Identity-based attacks –Third-party passive attacks –Third-party active attacks One other point: Potential threat from “fly-on-the-wall” inside the piconet (first party)- Rene will provide concise description of attacks Another point: Potential threat non-expiring authentications (first party)- Rene will provide concise description of attacks

15. IEEE 802.15.3-02/121r1 Submission 27 February 2002 B. Huang, D. Bailey, G. Rasor, R. Struik, M. Welborn Sony, NTRU, Motorola, Certicom, XtremeSpectrum Slide 15 Public key for authentication Need to create an authentic channel using Public Key based techniques Mutual authentication is agreed Need an algorithm –Three proposed: RSA, ECC, NTRUencrypt Agree that minimum level of security should be specified Need a protocol, agree on goals: –To establish the identity (challenge) of the other party (DEV) –To validate the public key (binding) of the other party (DEV) –The user approves of their communication –A payload protection seed shared with only the other party Different protocols proposed to meet these goals for each algorithm

16. IEEE 802.15.3-02/121r1 Submission 27 February 2002 B. Huang, D. Bailey, G. Rasor, R. Struik, M. Welborn Sony, NTRU, Motorola, Certicom, XtremeSpectrum Slide 16 Entity authentication Potential threat due to non-expiring authentications (first party) Note – Threat model was not understood: –Need to assure that an entity is still alive –Two approaches Provide explicit security mechanism Rely on other secure commands Concise description of attacks provided after the security meeting in doc: 02123r0P802-15_TG3- MAC-Security-Threat-Model

17. IEEE 802.15.3-02/121r1 Submission 27 February 2002 B. Huang, D. Bailey, G. Rasor, R. Struik, M. Welborn Sony, NTRU, Motorola, Certicom, XtremeSpectrum Slide 17 Symmetric key for data protection Agree that we need to use symmetric key for data encryption/decryption Specific symmetric algorithms proposed: –Two-key 3-DES, AES Mode of operation needs to be specified in each proposal –Has implications on out-of-order packets –We will try to support out-of-order packets –Supporting out-of-order packets has implications on level of security provided

18. IEEE 802.15.3-02/121r1 Submission 27 February 2002 B. Huang, D. Bailey, G. Rasor, R. Struik, M. Welborn Sony, NTRU, Motorola, Certicom, XtremeSpectrum Slide 18 Symmetric key update Need to provide mechanism (protocol) to update shared keys –Security policy dictates when required Two approaches (largely the same*) –Without key confirmation –With key confirmation * handled by proposals

19. IEEE 802.15.3-02/121r1 Submission 27 February 2002 B. Huang, D. Bailey, G. Rasor, R. Struik, M. Welborn Sony, NTRU, Motorola, Certicom, XtremeSpectrum Slide 19 Integrity for data protection We need to provide authenticity and integrity on data traffic –Protect against traffic substitution/injection –Protects against replay attacks –Has implications on out-of-order packets –We will try to support out-of-order packets by specifying the freshness granularity Two modes proposed (largely the same*): –Encrypt-then-MAC and MAC-then-encrypt Specific symmetric algorithms proposed: –Two-key 3-DES, SHA-1, et.seq. HMAC * handled by proposals

20. IEEE 802.15.3-02/121r1 Submission 27 February 2002 B. Huang, D. Bailey, G. Rasor, R. Struik, M. Welborn Sony, NTRU, Motorola, Certicom, XtremeSpectrum Slide 20 Protection of commands We need to provide authenticity on DEV-PNC or PNC-DEV commands –Protect against command substitution/injection –Protects against replay attacks We need to provide authenticity on DEV-DEV commands Same algorithms as data protection, but use different keys

21. IEEE 802.15.3-02/121r1 Submission 27 February 2002 B. Huang, D. Bailey, G. Rasor, R. Struik, M. Welborn Sony, NTRU, Motorola, Certicom, XtremeSpectrum Slide 21 Non-goals: limiting the scope Out of scope –Implementation details: Key exposure –Access control list management Handled by DME (Possible informative text) On both SM side and DEV side –DRM (higher layer security) –Registration of certificates –Non-cryptographic means of establishing Identity-Public key binding