doc.: ieee 802.22-07/0031r0 submission jan. 2007 tom messerges, motorolaslide 1 security overview...

Jan. 2007

Tom Messerges, Motorola

Slide 1

doc.: IEEE 802.22-07/0031r0

Submission

Security Overview for IEEE 802.22 TG1IEEE P802.22 Wireless RANs Date: 2007-01-12

Name Company Address Phone email Tom Messerges Motorola Schaumburg, IL 847-576-5827 [email protected]

Steve Kuffner Motorola Schaumburg, IL 847-538-4158 [email protected]

Monique Brown Motorola Sunnyvale, CA 408-991-7460 [email protected]

Greg Buchwald Motorola Schaumburg, IL 847-576-4893 [email protected]

Ed Callaway Motorola Plantation, FL 954-723-8341 [email protected]

Authors:

Notice: This document has been prepared to assist IEEE 802.22. It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein.

Release: The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution, and any modifications thereof, in the creation of an IEEE Standards publication; to copyright in the IEEE’s name any IEEE Standards publication even though it may include portions of this contribution; and at the IEEE’s sole discretion to permit others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and accepts that this contribution may be made public by IEEE 802.22.

Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures http://standards.ieee.org/guides/bylaws/sb-bylaws.pdf including the statement "IEEE standards may include the known use of patent(s), including patent applications, provided the IEEE receives assurance from the patent holder or applicant with respect to patents essential for compliance with both mandatory and optional portions of the standard." Early disclosure to the Working Group of patent information that might be relevant to the standard is essential to reduce the possibility for delays in the development process and increase the likelihood that the draft publication will be approved for publication. Please notify the Chair Carl R. Stevenson as early as possible, in written or electronic form, if patented technology (or technology under patent application) might be incorporated into a draft standard being developed within the IEEE 802.22 Working Group. If you have questions, contact the IEEE Patent Committee Administrator at [email protected].>

Jan. 2007


Slide 2

doc.: IEEE 802.22-07/0031r0

Submission

Abstract

We provide an overview of security solutions for IEEE 802.22 TG1. The following topics are addressed:

– System Requirement and Approaches– Security Architecture and Procedures– MIC Generation and Verification– Security Analysis– Future Work

Jan. 2007


Slide 3

doc.: IEEE 802.22-07/0031r0

Submission

System Requirement and Approaches

Basic Requirement:• Unlicensed devices (e.g., WRAN) in the TV whitespace spectrum must yield to

licensed devices (e.g., wireless microphones) entitled to protection

Approaches for Unlicensed Device to Detect Licensed Device:

1. Sense energy in channel:Leave the channel if energy is detected

2. Detect beacon signal:Leave the channel if signal is detected that looks like a beacon

3. Acquire beacon frame and authenticate: Leave the channel if beacon frame data is authentic

Approach described in this presentation

Jan. 2007


Slide 4

doc.: IEEE 802.22-07/0031r0

Submission

Beacon Frame*

Security Architecture

Beacon

TG1 Beacon (PPD or SPD)

IEEE 802.22 WRAN CPE

Parameter1

MAC Address

LocationChannel

MapMessage

Integrity CodeParameter

2Parameter

3

1 6 8 5 41 1Octets:

IEEE 802.22 WRAN BS

On-Line Verifier

Beacon

Beacon

Authentication Response

BeaconKey

(128-bits)

* Note: the “Time” subfield in the beacon frame does not need to be transmitted since the WRAN or On-Line verifier needs to have an independent source for this information. However, the “time” subfield is still included in the calculation of the MIC.

PPD(Primary

Protecting Device)

Beacon

Beacon

Secure Authenticated Communications Channel (e.g., via IPsec or TLS)

Commands

Jan. 2007


Slide 5

doc.: IEEE 802.22-07/0031r0

Submission

Security Procedures1. TG1 Beacon broadcasts a beacon frame with a Message Integrity Code (MIC)

that is securely calculated based on:– Beacon’s MAC Address

– Parameters 1, 2, and 3

– Beacon’s location

– Channel map

– Time-of-day (accurate to within 10 minutes)

– 128-bit beacon key (unique to each Beacon)

2. Upon receipt of beacon– A PPD or SPD will verify its legitimacy based on out-of-scope technique (it cannot verify the

MIC)

– A WRAN CPE will forward it to a WRAN BS

– A WRAN BS will perform initial authentication checks (e.g., verify the frame format and location fields)

– A WRAN BS will forward initially authenticated beacon frames to an “On-Line Verifier” for final authentication

3. “On-Line Verifier” will use the 128-bit beacon key corresponding to the beacon’s MAC address to verify the beacon frame and return a “VALID” or “INVALID” response to the WRAN BS

Jan. 2007


Slide 6

doc.: IEEE 802.22-07/0031r0

Submission

MIC Generation

Message Integrity Code

4

Parameter1

MAC Address

LocationChannel

MapParameter

2Parameter

3

1 6 8 51 1Octets:

Beacon Frame

MIC Generation Function*

* MIC function is based on HMAC (FIPS PUB 198) and SHA-256 (FIPS PUB 180-2)

Shared Device Key (128 bits)

Time of Day (6 octets)

Jan. 2007


Slide 7

doc.: IEEE 802.22-07/0031r0

Submission

MIC Verification

Message Integrity Code

4

Parameter1

MAC Address

LocationChannel

MapParameter

2Parameter

3

1 6 8 51 1Octets:

Beacon Frame

MIC Generation Function*Shared Device Key

(128 bits)

Time of Day (6 octets)Message

Integrity Code′

Equal?

* MIC function is based on HMAC (FIPS PUB 198) and SHA-256 (FIPS PUB 180-2)

Jan. 2007


Slide 8

doc.: IEEE 802.22-07/0031r0

Submission

Security Analysis – Assets and Vulnerabilities

Assets:• System functionality (e.g., WRAN provides Internet access, wireless microphones work)• RF Spectrum (used by either licensed or unlicensed devices)• Time/Computational/Power Resources (of WRAN, TG1 Beacon, On-Line Verifier)• Beacon key

Points of Vulnerability:• Communications from beacon to WRAN or other beacon• Communications between WRAN BS and Internet• Communications to and from the On-Line Verifier• Communications between WRAN BS and WRAN CPE• Communications within wireless microphone system• Beacon key sharing between beacon and on-line verifier• Equipment (including Beacon, WRAN BS and CPE, On-Line Verifier)

Jan. 2007


Slide 9

doc.: IEEE 802.22-07/0031r0

Submission

Threats Against “Points of Vulnerability” (1 of 3)

Threats against “Communications from beacon to WRAN or other beacon”:• RF spectrum is jammed

• Mock wireless microphone or TV waveform is transmitted

• Beacon frame with a invalid MIC is transmitted to a WRAN BS/CPE or beacon

• Illegitimate beacon frame with a valid MIC is transmitted to a WRAN BS/CPE or beacon

• Legitimate beacon frame is replayed to a WRAN BS/CPE or beacon

• Mock RTS or ANP is transmitted to beacon

• Adversary monitors valid beacon frames with intent to learn beacon key (e.g., via cryptanalysis)

Threats against “Communications between WRAN BS and Internet”:• WRAN BS connection to the Internet is severed (either physically or logically)

• WRAN BS communications to/from the Internet are monitored or modified

Threats against “Communications to and from the On-Line Verifier”:• WRAN BS connection to the On-Line Verifier is severed (either physically or logically)

• WRAN BS communications to/from the On-Line Verifier are monitored or modified

• Illegitimate entities communicate with the On-Line Verify for nefarious purposes (e.g., to help derive valid MIC’s for beacons)

Jan. 2007


Slide 10

doc.: IEEE 802.22-07/0031r0

Submission


Threats against “Communications between WRAN BS and WRAN CPE”:• RF spectrum is jammed

• Compromised WRAN CPE can send bogus beacon frames or RF signal reports to WRAN BS

• Compromised WRAN BS can send bogus commands to WRAN CPE

Threats against “Communications within wireless microphone system”:• RF spectrum is jammed

Threats against “Beacon key sharing between beacon and On-Line Verifier”:• The initial provisioning of beacon keys or key updates of beacons is monitored

• Phony beacon key updates are sent to beacon

Jan. 2007


Slide 11

doc.: IEEE 802.22-07/0031r0

Submission


Threats against “Beacon Equipment”:• Beacon is stolen and used for nefarious purposes

• Beacon key is extracted from a beacon and used to send mock beacons to WRAN and other beacons

• Beacon’s credentials with On-Line Verifier system are extracted, enabling mock key updates to beacon

Threats against “WRAN Equipment”:• WRAN BS is compromised and used to attack On-Line Verifier (e.g., to bring down On-Line

Verifier or use it to help find valid MIC’s)

• WRAN BS credentials with the On-Line Verifier are extracted, enabling mock communications with the On-Line verifier

Threats against “On-Line Verifier Equipment”:• On-Line Verifier system is compromised and beacon keys are exposed, enabling mock beacons

• On-Line Verifier system’s credentials with WRAN are extracted, enabling mock beacon validity responses sent to WRAN

• On-Line Verifier system’s credentials with beacon are extracted, enabling mock key updates to beacon

Jan. 2007


Slide 12

doc.: IEEE 802.22-07/0031r0

Submission

Specific Threat Analysis (1 of 4)Threat:

Illegitimate beacon frame with a valid MIC is transmitted to a WRAN BS/CPE or beacon.

Risk:1/232 chance of guessing a valid MIC or O(232) work to use on-line verifier to get a valid MIC.

Comments:WRAN vacates RF spectrum unnecessarily (but only for 10 minute period in geographic location specified by the beacon location code). To prevent a bogus "required need timer" field in Parameter 3, the WRAN can periodically confirm that the beacon is still transmitting. If a beacon can be transmitted or tested by the On-Line Verifier in approximately 25ms, it will take over 3 years to get one valid MIC (on average).

Threat:Legitimate beacon frame is replayed to a WRAN BS/CPE or beacon.

Risk:Attacker must be collocated within range of a legitimate beacon that is already operating.

Comments:The MIC is calculated using location and time information. A replay attack would need to replay a beacon from a nearby legitimate beacon and could only do so for 10 minutes until it would need to listen for and then replay an updated beacon. Time is proposed to be accurate to within 10 minutes as a tradeoff between sufficient protection against extended replay (e.g., replay a beacon frame long after the legitimate beacon has shut off) and sufficient ability to maintain clock synchronization between the beacon and the verifier of the beacon frame.

Jan. 2007


Slide 13

doc.: IEEE 802.22-07/0031r0

Submission


Mock RTS or ANP is transmitted to beacon.

Risk:Any rogue device can transmit legitimate looking RTS and ANP signals since these are unauthenticated.

Comments:Repetitive reception of illegitimate RTS signals could cause a beacon to defer sending its beacon frame. However, the policy of the PPD should be that it cannot be completely shut down by this attack. For example, a good policy might be that upon receipt of an RTS, the PPD should listen for the next frame, but must transmit its own payload for the subsequent N frames, where N is at least 1.

Threat:Adversary monitors valid beacon frames with intent to learn beacon key (e.g., via cryptanalysis).

Risk:Beacon frames, which include the MIC are sent in the clear and can be readily monitored.

Comments:Use of strong cryptographic algorithms (e.g., HMAC and SHA-256) with a secret 128-bit beacon key make it infeasible that cryptanalysis will succeed.

Jan. 2007


Slide 14

doc.: IEEE 802.22-07/0031r0

Submission


Beacon is stolen and used for nefarious purposes.

Risk:Physically secured beacons could be difficult to steal and the attacker would risk getting caught.

Comments:A stolen beacon can be reported back to the On-Line Verifier and blacklisted.

Threat:Beacon key is surreptitiously extracted from a beacon and used to send mock beacons to WRAN and other beacons.

Risk:Physically secured beacons with tamper-resistance would make it difficult for an attacker to execute this threat without a risk of getting caught.

Comments:It should not be easy to extract the beacon key from a beacon. To prevent insider attacks, even the owner of a beacon should not be able to extract the beacon key.

Jan. 2007


Slide 15

doc.: IEEE 802.22-07/0031r0

Submission


On-Line Verifier system is compromised and beacon keys are exposed, enabling mock beacons.

Risk:The infrastructure can be easily hardened against outside attacks using standard IT security best practices.

Comments:Insider attacks should be prevented through the use of secure key management best practices (e.g., use of hardware security modules).

Jan. 2007


Slide 16

doc.: IEEE 802.22-07/0031r0

Submission

Summary of Security Solution Features

• On-line beacon verification – beacon keys always under control of licensed entities, but devices without backhaul cannot verify MIC

• Beacon protected with 32-bit MIC (best attack seems to take > 3 years for getting, on average, one valid MIC)*

• Use of a 128-bit beacon key to generate MIC – cryptanalysis attack O(2128)

• MIC calculated using time and location data to mitigate against replay attacks

• Very small MIC and removal of time subfield from beacon lead to small quiet time for WRANs

*Assuming an external entity can use the On-Line Verifier to test a guessed MIC every 25ms

Jan. 2007


Slide 17

doc.: IEEE 802.22-07/0031r0

Submission

References

• FIPS Pub 180-2, “Secure Hash Standard (SHS)”, Federal Information Processing Standards Publication 180-2, US Department of Commerce/N.I.S.T., Springfield, Virginia, August 2002. Available from http://www.itl.nist.gov/fipspubs/.

• FIPS Pub 198, “The Keyed-Hash Message Authentication Code (HMAC)”, Federal Information Processing Standards Publication 198, US Department of Commerce/N.I.S.T., Springfield, Virginia, March 2002.Available from http://www.itl.nist.gov/fipspubs/.

Jan. 2007


Slide 18

doc.: IEEE 802.22-07/0031r0

Submission

Backup Slides

Jan. 2007


Slide 19

doc.: IEEE 802.22-07/0031r0

Submission

Threats, Risks and Comments (1 of 2)Threat Category Threat Description Risk Comments

RF spectrum is jammed Requires jamming device to be nearby with continuous operation. Nearby jamming devices are subject to detection and pose increased risk to an attacker.

Mock wireless microphone or TV waveform is transmitted

Requires mock signaling device to be nearby with continuous operation.

WRAN may be initially fooled with a mock waveform, but a first step to counter this issue would be to verify the presence of a BEACON frame, the second step would be to verify the MIC using the On-Line Verifier. Note that only a recipient that can communicate to the On-Line Verifier (such as a WRAN BS) can perform this verification. In particular, another beacon device that is off-line may not be able to verify a MIC.

Beacon frame with a invalid MIC is transmitted to a WRAN BS/CPE or beacon

Depends on availability (or ease of building) an RF device that can mimic a beacon

WRAN and On-Line Verifier resources are unnecessarily consumed, but since MIC is wrong the RF spectrum is not vacated

Illegitimate beacon frame with a valid MIC is transmitted to a WRAN BS/CPE or beacon

1/232 chance of guessing a valid MIC or O(232) work to use on-line verifier to get a valid MIC

WRAN vacates RF spectrum unnecessarily (but only for 10 minute period in geographic location specified by the beacon location code). To prevent a bogus "required need timer" field in Parameter 3, the WRAN can periodically confirm that the beacon is still transmitting. If a beacon can be transmitted or tested by the On-Line Verifier in approximately 25ms, it will take over 3 years to get one valid MIC (on average).

Legitimate beacon frame is replayed to a WRAN BS/CPE or beacon

Attacker must be collocated within range of a legitimate beacon that is already operating.

The MIC is calculated using location and time information. A replay attack would need to replay a beacon from a nearby legitimate beacon and could only do so for 10 minutes until it would need to listen for and then replay an updated beacon. Time is proposed to be accurate to within 10 minutes as a tradeoff between sufficient protection against extended replay (e.g., replay a beacon frame long after the legitimate beacon has shut off) and sufficient ability to maintain clock synchronization between the beacon and the verifier of the beacon frame.

Mock RTS or ANP is transmitted to beacon Any rogue device can transmit legitimate looking RTS and ANP signals since these are unauthenticated.

Repetitive reception of illegitimate RTS signals could cause a beacon to defer sending its beacon frame. However, the policy of the PPD should be that it cannot be completely shut down by this attack. For example, a good policy might be that upon receipt of an RTS, the PPD should listen for the next frame, but must transmit its own payload for the subsequent N frames, where N is at least 1.

Adversary monitors valid beacon frames with intent to learn beacon key (e.g., via cryptanalysis)

Beacon frames, which include the MIC are sent in the clear and can be readily monitored.

Use of strong cryptographic algorithms (e.g., HMAC and SHA-256) with a secret 128-bit beacon key make it infeasible that cryptanalysis will succeed.

WRAN BS connection to the Internet is severed (either physically or logically)

Sufficient redundancy and security (physical and logical) can make this difficult.

WRAN BS communications to/from the Internet are monitored or modified

Cryptographic techniques can make this difficult.

WRAN BS connection to the On-Line Verifier is severed (either physically or logically)

Sufficient redundancy and security (physical and logical) can make this difficult.

WRAN BS communications to/from the On-Line Verifier are monitored or modified

Cryptographic techniques can make this difficult.

Illegitimate entities communicate with the On-Line Verify for nefarious purposes (e.g., to help derive valid MIC’s for beacons)

Cryptographic techniques can make this difficult.The security policy of the On-Line Verifier should be that it only communicate with legitimate entities. This can be enforced requiring the use of an IPsec or TLS secured communication channel.


Compromised WRAN CPE can send bogus beacon frames or RF signal reports to WRAN BS

Since CPE is under customer control, it may more readily manipulated.WRAN BS could compare multiple CPE reports to detect this attack. MIC verification can help against this attack, too.

Compromised WRAN BS can send bogus commands to WRAN CPE

Physical security of WRAN BS and cryptographically secured communications with CPEs could make this difficult.

WRAN BS and CPE should use security best practices to secure their communications.

Threats against “Communications

within wireless microphone system”:


WRAN needs to use security best practices to secure its connection to the Internet.

WRAN needs to use security best practices to secure its connection to the On-Line Verifier.


from beacon to WRAN or other

beacon”:


between WRAN BS and Internet”:

Threats against “Communications to and from the On-Line

Verifier”:


between WRAN BS and WRAN CPE”:

Jan. 2007


Slide 20

doc.: IEEE 802.22-07/0031r0

Submission

Threats, Risks and Comments (2 of 2)

Threat Category Threat Description Risk Comments

Beacon is stolen and used for nefarious purposes Physically secured beacons could be difficult to steal and the attacker would risk getting caught.

A stolen beacon can be reported back to the On-Line Verifier and blacklisted.

Beacon key is surreptitiously extracted from a beacon and used to send mock beacons to WRAN and other beacons

Physically secured beacons with tamper-resistance would make it difficult for an attacker to execute this threat without a risk of getting caught.

It should not be easy to extract the beacon key from a beacon. To prevent insider attacks, even the owner of a beacon should not be able to extract the beacon key.

Beacon’s credentials with On-Line Verifier system are extracted, enabling mock key updates to beacon

Physically secured beacons with tamper-resistance would make it difficult for an attacker to execute this threat without a risk of getting caught.

It should not be easy to extract (or modify) these credentials from a beacon.

WRAN BS is compromised and used to attack On-Line Verifier (e.g., to bring down On-Line Verifier or use it to help find valid MIC’s)

Physical and logical security of WRAN BS should make this difficult. On-Line Verifier can use standard IT security mechanisms to detect and throttle this type of attack.

WRAN BS credentials with the On-Line Verifier are extracted, enabling mock communications with the On-Line verifier

Physical and logical security of WRAN BS should make this difficult.There should be a way to revoke access privelges to the On-Line Verifier of a known compromised WRAN BS. The damage done by unknown compromised devices can be throttled. Attacks against the MIC require

232 queries to get, on average, one valid MIC. On-Line Verifier system is compromised and beacon keys are exposed, enabling mock beacons On-Line Verifier system’s credentials with WRAN are extracted, enabling mock beacon validity responses sent to WRAN On-Line Verifier system’s credentials with beacon are extracted, enabling mock key updates to beacon

Infrastructure components should be very difficult to attack.The infrastructure can be easily hardened against outside attacks using standard IT security best practices. Insider attacks should be prevented through the use of secure key management best practices (e.g., use of hardware security modules).

Threats against “Beacon Equipment”:

Threats against “WRAN Equipment”:

Threats against “On-Line Verifier Equipment”:

doc.: ieee 802.22-07/0031r0 submission jan. 2007 tom messerges, motorolaslide 1 security overview...

Documents