Security Ad-Hoc Report Draft Month Year doc.: IEEE 802.11-yy/xxxxr0 January 2009 Security Ad-Hoc Report Draft Date: 2009-02-04 Authors: Alex Reznik, InterDigital John Doe, Some Company

January 2009 Abstract This presentation summarizes the recommendations of the security ad-hoc group. Currently a draft. Aimed to become part of a recommendation to the EC as well as provide starting point for the tutorial Abstract to be removed/modified as needed. Alex Reznik, InterDigital

Security Goals and General Approach January 2009 Security Goals and General Approach Within the context of white spaces, security design needs to focus on two goals: Primary goal: Protection of incumbents Secondary goal: Protection of secondary users The number of issues and technologies is larger than with protection of incumbents Requires a comprehensive approach General Approach to Security This bullet is subject to addition of information on the end-to-end slides and approval by the group The ad-hoc recommends that an end-to-end security design approach be used in developing security aspects of white space technologies Within 802 this means a focus on the following The interfaces required for support of higher-level security technologies, such as data/application security, secure identity protocols, device security, etc. Support of security technologies as discussed below Alex Reznik, InterDigital

Threat Analysis (1/4) High Level Threats January 2009 Threat Analysis (1/4) High Level Threats Illegal Use of Spectrum Causing harmful interference to incumbents Denial of Service between Secondary Users Threats to coexistence protocols between secondary devices e.g. Stealing/hogging spectrum Unauthorized disclosure or modification of “sensitive user/location” information Disclosure of user location Modification of database info “sensitive user/location” information is not correct Registered incumbent or secondary user location Database info poisoning Sensitive user/location information includes User location information User identity Database registration/authentication paramenters Sensor measurements reported to the database by user Interference report from the database Alex Reznik, InterDigital

Threat Analysis 2/4 Mapping Use Cases to Threats – Master Devices January 2009 Threat Analysis 2/4 Mapping Use Cases to Threats – Master Devices Use Cases/Threats 4W Fixed 4W-4W fed by 100mW 4W-100 mW 100 mW (Registered Master) (Un -registered Master) 50 mW (Sensing Only) ≤ 40 mW Illegal Use of Spectrum X DoS between Secondary Users Disclosure/ Modification of “Relevant“ Info “Relevant” Info Not correct Alex Reznik, InterDigital

Threat Analysis 3/4 Mapping Use Cases to Threats – Client Devices January 2009 Threat Analysis 3/4 Mapping Use Cases to Threats – Client Devices Use Cases/Threats 4W Fixed 4W-4W fed by 100mW 4W-100 mW 100 mW (Registered Master) (Un -registered Master) 50 mW (Sensing Only) ≤ 40 mW Illegal Use of Spectrum X DoS between Secondary Users Disclosure/ Modification of “Relevant“ Info “Relevant” Info Not correct Alex Reznik, InterDigital

Threat Analysis 3/4 - Caveats January 2009 Threat Analysis 3/4 - Caveats For the “50mW (Sensing Only)” and “≤ 40mW” the Disclosure/Modification of Relevant Info & Relevant Info Not Correct threats, are not applicable as those devices will not make use of the database. The “≤ 40mW” use case is not affected by the Illegal Use of Spectrum threat due to low power. Devices can operate in adjacent channels. Client devices cannot pose the Illegal Use of Spectrum threat in some use cases because the master chooses the spectrum, polls the database, and bears the responsibility for violation. The exception is when the master device is unregistered. Given that registration for the lower power devices is not required. This also may be applicable for lower power networks operating in a mesh or peer to peer topology, where every device would be considered a master. Alex Reznik, InterDigital

General Recommendations January 2009 General Recommendations Device Security Key requirement for protection of incumbents Ensures that devices cannot be modified to “break the rules” Potentially required to pass FCC certification Generally, not in scope for 802. However 802 may need to provide support of proper device security operation: Measurement and signaling required to verify that the device is operating according to applicable specifications and policies Ability to affect device operations (e.g. disable transmissions) should device be found to be in violation of such policies See TNC in the end-to-end architecture slides for an example. Low-Layer Security Support of low-layer techniques by 802 is recommended to address the following Incumbent classification / identification identification of malicious and negligent impersonators Protection of coexistence signaling It is recommended that the WGs coordinate their efforts in this area Sensor and location measurement security Support by 802 of techniques that secure and attest sensing and location measurements is recommended Protection of database information Protection of database information on the device and its transmission over the air interface links is recommended and appropriate techniques should be supported by 802 Alex Reznik, InterDigital

Location Privacy: and End-to-End Service Example ? January 2009 Location Privacy: and End-to-End Service Example ? Potential end-to-end requirements Support of mechanisms to prevent tracking of changes in location of a mobile device based on information sent in database queries. Support of mechanisms to prevent long term tracking of a mobile device’s location based on it's transmissions. Mapping this to existing mechanisms within 802 Mapping this to recommended additional mechanisms Alex Reznik, InterDigital; Ranga Reddy, US Army; Michael Williams, Nokia

January 2009 End-to-End Security 1/2 Alex Reznik, InterDigital

January 2009 End-to-End Security 2/2 Alex Reznik, InterDigital