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

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

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

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

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

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

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
Generally, not in scope for 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

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

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

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