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. Abstract to be removed once this becomes part of the tutorial 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 This requires support of device security as discussed below Secondary goal: Protection of Cognitive Radios While secondary, this is a much larger problem them protection of incumbents Requires a much more comprehensive approach General Approach to Security 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 certain low-level security technologies as discussed below Alex Reznik, InterDigital

Risk Analysis (1/4) High Level Threats January 2009 Risk Analysis (1/4) High Level Threats Illegal Use of Spectrum Causing harmful interference to incumbents Denial of Service to other Secondary Users Threats to coexistence protocols between secondary devices e.g. Stealing/hogging spectrum, preventing from other Unauthorized disclosure or modification of “relevant” information User location Database Info “Relevant” information is not correct Database info Alex Reznik, InterDigital

Risk Analysis 2/4 Mapping Use Cases to Threats – Master Devices January 2009 Risk 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 to other Secondary Users Disclosure/Modification of “Relevant“ Info “Relevant” Info Not correct Alex Reznik, InterDigital

Risk Analysis 3/4 Mapping Use Cases to Threats – Client Devices January 2009 Risk 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 to other Secondary Users Disclosure/Modification of “Relevant“ Info “Relevant” Info Not correct Alex Reznik, InterDigital

Risk Analysis 3/4 - Caveats January 2009 Risk 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, as it is the only use case (due to its’ low power) that can operate in adjacent channels. Illegal Use of Spectrum is not considered a threat, from the client side, for some use cases because it is expected that the master device will poll the database on behalf of the client and that the client will only operate on channels the master tells it to. 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 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 While generally above MAC (and thus out of scope for 802), 802 should support the following A “device security SAP” which provides key parameters required to make sure that the radio is compliant with required policies in real-time. The policies may include any of the following: FCC regulations, coexistence policies, intra-RAT protocol specification. Low-Layer Security Support of low-layer techniques 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 of techniques that secure and attest sensing and location measurements of recommended Protection of database information Protection of database information on the device and its transmission over the air interface links is recommended Alex Reznik, InterDigital

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

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