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

2. 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

3. 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

4. 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

5. 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

6. 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

7. 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

8. 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

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

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