May 2001 William A. ArbaughSlide 1 doc.: IEEE /245r0 Submission Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: IEEE : Security-Privacy Introduction and Overview Date Submitted: May, 2001 Source: William A. ArbaughCompany: University of Maryland Address: Voice: , Re: [ ] Abstract: Security and Privacy principles Purpose: 1) To inform the IEEE about fundamental security and privacy issues in wireless personal area networks. Notice:This document has been prepared to assist the IEEE P 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 these viewgraphs become(s) the property of IEEE and may be made publicly available by P

May 2001 William A. ArbaughSlide 2 doc.: IEEE /245r0 Submission Security/Privacy Introduction and Overview William A. Arbaugh

May 2001 William A. ArbaughSlide 3 doc.: IEEE /245r0 Submission Talk Outline Introduction Roadmap Scenarios Preliminary threat analysis Preliminary requirement analysis

May 2001 William A. ArbaughSlide 4 doc.: IEEE /245r0 Submission Some beginning thoughts “Security is a process” “Cryptography is not security ” “ To be effective, security must be transparent ”

May 2001 William A. ArbaughSlide 5 doc.: IEEE /245r0 Submission You can never have 100% Security is all about Risk Management

May 2001 William A. ArbaughSlide 6 doc.: IEEE /245r0 Submission Similarities to but… WPAN is a much more difficult problem CPU constraints Power constraints Memory constraints Cost constraints Infrastructure issues The end points in are hosts.

May 2001 William A. ArbaughSlide 7 doc.: IEEE /245r0 Submission Security Architecture Elements Integrity Source of data, i.e. prevent datagram forgeries Data content, i.e. prevent data modification Confidentiality How long does the data need to remain protected? Authentication

May 2001 William A. ArbaughSlide 8 doc.: IEEE /245r0 Submission Trusted Element What is it? Most every day transactions have a common trusted element to them. Establishing a trusted element with each scenario is one of the most difficult aspects of a security architecture for WPAN.

May 2001 William A. ArbaughSlide 9 doc.: IEEE /245r0 Submission Roadmap Define scenarios Develop threat model Define requirements Develop architecture External review

May 2001 William A. ArbaughSlide 10 doc.: IEEE /245r0 Submission Scenarios Consumer Peripherals Photo frames Trade show Exchange info Exchange proprietary info

May 2001 William A. ArbaughSlide 11 doc.: IEEE /245r0 Submission Scenarios cont. Trading floor / Auctions Bids public, but need non-repudiation Settlement Kiosks/commerce

May 2001 William A. ArbaughSlide 12 doc.: IEEE /245r0 Submission Threat Classes Class I Clever outsiders that attempt to take advantage of existing system weaknesses. Access to moderately sophisticated equipment is assumed. Class II Knowledgeable insiders with detailed information about various parts of the system, and they may have access to sophisticated equipment.

May 2001 William A. ArbaughSlide 13 doc.: IEEE /245r0 Submission Threat Classes cont. Class III Funded organizations able to assemble specialized teams with access to extremely sophisticated equipment.

May 2001 William A. ArbaughSlide 14 doc.: IEEE /245r0 Submission Threat and Requirements The next few slides present a “straw man” for both the threat and security requirements for each scenario. They are designed to be the starting point for discussions.

May 2001 William A. ArbaughSlide 15 doc.: IEEE /245r0 Submission Consumer Threat Model ConfidentialityIntegrityAuthentication None-Class I

May 2001 William A. ArbaughSlide 16 doc.: IEEE /245r0 Submission Trade Show Threat Model ConfidentialityIntegrityAuthentication None-Class I None 1 1.It would be nice, but establishing a common trust element is too dificult.

May 2001 William A. ArbaughSlide 17 doc.: IEEE /245r0 Submission Auction Threat Model ConfidentialityIntegrityAuthentication NoneClass II -Class III

May 2001 William A. ArbaughSlide 18 doc.: IEEE /245r0 Submission Kiosk Threat Model ConfidentialityIntegrityAuthentication Class I – Class III

May 2001 William A. ArbaughSlide 19 doc.: IEEE /245r0 Submission Requirements A single solution WILL NOT meet all of the potential requirements. Choices (all have draw backs) Engineer to the strongest requirements Implement a security association mechanism Provide minimal support (Class I protection) in.15 and meet stronger requirements with upper layers

May 2001 William A. ArbaughSlide 20 doc.: IEEE /245r0 Submission Now What? Committee should agree on a set of scenarios representing typical WPAN usage. Committee agrees on a threat model for each scenario. Committee agrees on security requirements for each scenarios. Architecture developed based on the above. Architecture submitted for external review.

May 2001 William A. ArbaughSlide 21 doc.: IEEE /245r0 Submission Conclusions Security is a process and must be viewed holistically with the rest of the system. Security must be designed into the system from the beginning.