1. Security Ad-Hoc Report Draft
Month Year
doc.: IEEE yy/xxxxr0
March 2009
Security Ad-Hoc Report Draft
Date:
Authors:
Alex Reznik, InterDigital; Ranga Reddy, US Army;
Michael Williams, Nokia; Richard Paine, self, Paul Lambert, Marvell
John Doe, Some Company

2. March 2009
Abstract
This presentation summarizes the recommendations of the security ad-hoc group.
It consists of 2 parts:
Main section includes recommendation and threat analysis
Main section will be presented as part of the White Spaces ECSG tutorial
Background section includes additional information intended to illustrate, support and explain points made in the main section.
Alex Reznik, InterDigital; Ranga Reddy, US Army;
Michael Williams, Nokia; Richard Paine, self; Paul Lambert, Marvell

3. March 2009
Main Section
Alex Reznik, InterDigital; Ranga Reddy, US Army;
Michael Williams, Nokia; Richard Paine, self; Paul Lambert, Marvell

4. Security Goals and General Approach
March 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 unlicensed users
The number of issues and technologies is larger than with protection of incumbents
Requires a comprehensive approach
Approach to Security
The ad-hoc recommends that an end-to-end security analysis 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; Ranga Reddy, US Army;
Michael Williams, Nokia; Richard Paine, self, Paul Lambert, Marvell

5. Threat Analysis: High Level Threats
March 2009
Threat Analysis: 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 may include
User location information
User identity
Database registration/authentication parameters
Sensor measurements reported to the database by user
Interference report from the database
Etc.
Alex Reznik, InterDigital; Ranga Reddy, US Army;
Michael Williams, Nokia; Richard Paine, self; Paul Lambert, Marvell

6. Threat Analysis Mapping Use Cases to Threats – Master Devices
March 2009
Threat Analysis 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; Ranga Reddy, US Army;
Michael Williams, Nokia; Richard Paine, self; Paul Lambert, Marvell

7. Threat Analysis Mapping Use Cases to Threats – Client Devices
March 2009
Threat Analysis 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; Ranga Reddy, US Army;
Michael Williams, Nokia; Richard Paine, self; Paul Lambert, Marvell

8. Threat Analysis: Caveats
March 2009
Threat Analysis: 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; Ranga Reddy, US Army;
Michael Williams, Nokia; Richard Paine, self; Paul Lambert, Marvell

9. Ad-Hoc Recommendations
March 2009
Ad-Hoc Recommendations
Further Work
Present recommendation represents the best that could be accomplished with a limited time-span of this SG
The contributors and other security ad-hoc participant recognize the need for a much more detailed analysis resulting in
A detailed use-case based threat analysis
Detailed recommendation for addressing identified threats
802 should plan to further pursue this topic either in a separate SG or as part of other whitespace activities
Device security is an important requirement for protection of incumbents. Further study is needed to determine whether device security has an impact on 802.
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; Ranga Reddy, US Army;
Michael Williams, Nokia; Richard Paine, self; Paul Lambert, Marvell

10. Background and Additional Information
March 2009
Background and Additional Information
Alex Reznik, InterDigital; Ranga Reddy, US Army;
Michael Williams, Nokia; Richard Paine, self; Paul Lambert, Marvell

11. Illustrating the role of device security: Configurable Radio
March 2009
Illustrating the role of device security: Configurable Radio
Compliance attestation : an important piece in the cognitive radio puzzle
Provides the most effective mechanism for ensuring that a radio is following the required specifications
May be required to demonstrate regulatory compliance
In particular, MAC and PHY (and perhaps even the RF) must be attested to
The trend, especially in the area of “cognitive radios,” is toward implementations which are highly configurable.
Code attestation is not sufficient to ensure compliance
Compliance must be attested over all possible configurations
The state space may be too large for full code-based attestations
Limited attestation can address this problem however
May be defined within RF/PHY/MAC or external to it
Must have the ability to monitor operation of the un-trusted entity for policy compliance
Must have the ability to limit operation when non-compliance observed
At a minimum, interfaces that enable monitor/limitation of operation must be defined and supported
T CM
Certify Compliance
Network
and above
MAC
MAC
PHY
PHY RF RF
Un-trusted
Trusted
Alex Reznik, InterDigital; Ranga Reddy, US Army;
Michael Williams, Nokia; Richard Paine, self; Paul Lambert, Marvell

12. March 2009
Location Privacy
The Geo-location database gets regular queries from every mobile TVWS device
User location is sensitive information that could be captured and misused
Location information can be captured at database or in transit
Recommendation:
Standards developed within IEE 802 should provide mechanisms and policies to ensure privacy of mobile users locations.
Alex Reznik, InterDigital; Ranga Reddy, US Army;
Michael Williams, Nokia; Richard Paine, self; Paul Lambert, Marvell

13. End-to-End Secure Comm.
Application-Secured Payload
SSL, TLS, etc.
March 2009
End-to-End Secure Comm.
TOG’s SMA Secure Datastore and Schema
TOG’s SMA Secure Datastore and Schema
IPSec, HIP, SMA, etc.
IETF’s Secure
DataStore and
Schema (MAP)
IETF’s Secure
DataStore and
Schema (MAP)
Application
Application
OSI-Session
OSI-Session
OSI-Internetworking
SMA PKI Datastore
People/Machines
SMA PKI Datastore
People/Machines
OSI-Internetworking
802 Interface to the “outside world”
Media
Physical Channel
Media
Modem
Modem
802.1x,etc.
802.1x, etc.
FCC Secure
WS DataStore
FCC Secure
WS DataStore
Alex Reznik, InterDigital; Ranga Reddy, US Army;
Michael Williams, Nokia; Richard Paine, self; Paul Lambert, Marvell

14. Vulnerabilities Associated with Location
March 2009
Vulnerabilities Associated with Location
Application:
Spectrum
Client/Server
Vulnerabilities: server address spoofing.
OSI-Session:
HTTP 
Vulnerabilities: tracking of location via IP address tracking
SMA PKI Datastore
People/Machines
OSI-netwk.: IP+TCP
Vulnerabilities: tracking of location via MAC ID
Physical Channel
Media
General Comments:
Location privacy can be compromised at every interface
Device/user tracking can be done through tracking of MAC IDs, IP addresses, HTTP sessions, etc.
A comprehensive solution to location privacy and anonymization is required
Modem = 802.xx PHY+MAC
802.1x, etc.
FCC Secure
WS DataStore
Alex Reznik, InterDigital; Ranga Reddy, US Army;
Michael Williams, Nokia; Richard Paine, self; Paul Lambert, Marvell