doc.: ieee 802.22-07/0137r0 submission march 2007 ed callaway, motorolaslide 1 public-key security...
TRANSCRIPT
March 2007
Ed Callaway, Motorola
Slide 1
doc.: IEEE 802.22-07/0137r0
Submission
Public-Key Security for IEEE 802.22 TG1IEEE P802.22 Wireless RANs Date: 2007-03-14
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].>
March 2007
Ed Callaway, Motorola
Slide 2
doc.: IEEE 802.22-07/0137r0
Submission
Abstract
Given the complexity of key management in symmetric-key based security we provide an alternate security solution for IEEE 802.22 TG1 based on asymmetric-key (a.k.a. public-key) cryptography. Our presentation describes an asymmetric-key approach and then compares it with symmetric-key approaches. The differences between approaches are analyzed.
Our conclusion is that even though the size of a beacon frame is larger for an asymmetric-key approach, the effect of this larger frame size on WRAN system performance can be minimized. Also, this increased burden can be offset by a significant simplification for WRAN operators in the area of key management. Furthermore, beacons (or other devices that mainly operate off-line) can leverage an asymmetric-key approach to provide additional secure functionality.
March 2007
Ed Callaway, Motorola
Slide 3
doc.: IEEE 802.22-07/0137r0
Submission
Cryptography Review
Beacon Header MIC
Key
MICGeneration
Beacon Header MIC
Key
ValidInvalid
MICVerification
Signature Generation
Beacon Header Signature
Private Key
Beacon Header
Public Key
ValidInvalid
Signature Verification
Asymmetric-Key• Simpler key-management• Signature (~80 bytes)
Symmetric-Key• Small key• Fast• Small MIC (4 bytes)
Equal
NotEqual
Signature
Securely Shared
From Certificate
Time Time
Time Time
March 2007
Ed Callaway, Motorola
Slide 4
doc.: IEEE 802.22-07/0137r0
Submission
Example Symmetric Key Management
DeliverKeyDatabase
IssueLicense
Unlicensed Device
Authority
LicenseeFCC
Licensed Device
Authority
Beacon Manufacturer
Unlicensed Device
Operator
SellBeacon
Issue Beacon Smart Card(with MAC and long-term key)
Beacon(with beacon smart card)
WRAN-BS(with WRAN smart card)
DeployBeacon
Issue WRANSmart Card
DeployWRAN-BS
TransmitBeaconFrame
RequestVerification or Session Key
DeliverResponse
On-LineVerifier
MAC/Keys
March 2007
Ed Callaway, Motorola
Slide 5
doc.: IEEE 802.22-07/0137r0
Submission
Example Asymmetric Key Management
Publish single public keyPublish blacklist
IssueLicense
Website
LicenseeFCC
Licensed Device
Authority
Beacon Manufacturer
SellBeacon
Issue Beacon Smart Card(with MAC and private key)
Beacon(with beacon smart card)
Any Unlicensed Device (e.g., WRAN
BS or CPE)
DeployBeacon
TransmitBeaconFrame
One-time load of public keyOccasional check of blacklist
SignificantSimplification!
March 2007
Ed Callaway, Motorola
Slide 6
doc.: IEEE 802.22-07/0137r0
Submission
Features of Asymmetric-Key Approach
• Licensed users (e.g., the broadcasters) do not need to trust other entities to manage their symmetric keys or develop elaborate schemes to securely share these keys
• Unlicensed users (e.g., WRAN operators) do not need to rely on real-time beacon verifier or implement elaborate schemes to protect the broadcaster’s symmetric keys (reduced liability)
• Verification of beacons is “self-contained” – any device (licensed or unlicensed – including WRAN CPE or BS) can independently verify beacon frames (e.g., off-line beacons can verify other beacons during inter-beacon communications)
March 2007
Ed Callaway, Motorola
Slide 7
doc.: IEEE 802.22-07/0137r0
Submission
Proposed TG1 Frame Structure
SignatureP1MAC
AddressLocation P2 P3
CRC3*
1 6 8 491 21
Channel Map
5
CRC1*
2
20 octets 16.67 ms
Beacon Frame
SyncIndex
NSync
IndexN-1
SyncIndex
1
2.498 ms
111 octets 92.51 ms
SyncIndex
NSync
IndexN-1
Beacon Header Beacon Signature and Certificate
* Note: the “CRC” subfields are used by a recipient to independently detect bit errors in the various subfields
PHR
1
AN
P
AN
P
2.498 ms
Beacon FrameRxRx
Certificate
33
56 octets 46.67 ms 35 octets 29.17 ms
CRC2*
2
March 2007
Ed Callaway, Motorola
Slide 8
doc.: IEEE 802.22-07/0137r0
Submission
Suspicious Beacon?No
NoYes
Multiple Options for Unlicensed Devices
Use Channel
Yes
Detect sync and index? (5 ms)
Detect beacon header (16.67 ms)
Detect beacon signature (46.67 ms)
No
Want more info?
Yes
Yes
Bogus Beacon?
Change Channel
No
Predominant overhead is just 5ms. Beacons will be rare and, for the most part, an unlicensed device can simply change channels when it sees a sync/index
The unlicensed device has a choice of whether to expend an additional 16.67 ms of overhead to acquire the beacon header.
Only under rare circumstances, the unlicensed device can choose to expend an additional 46.67 ms of overhead to authenticate a suspicious beacon.
Detect beacon certificate (29.17 ms)
If the unlicensed device does not get the public-key via an out-of-band channel, it must expend an additional “one-time” overhead of 29.17 ms to get the certificate via the beacon.
Need certificate?Yes
Yes
No
Interference from beacon
tolerable?
No
March 2007
Ed Callaway, Motorola
Slide 9
doc.: IEEE 802.22-07/0137r0
Submission
Conclusions
• Key management with symmetric keys imposes excessive burdens– Two unappealing options: Broadcasters trust unlicensed entities or on-
line verification is needed
• Key management in asymmetric-key approach is much cleaner:– No need for on-line verification: no Internet delays or reliability issues– Unlicensed entities do not need broadcaster’s secret keys
• Impact of larger beacon frame can be managed– Unlicensed devices have range of listening time options (5 to 97.5 ms)
• Listen for sync burst – 5 ms• Listen for header – 16.67 ms (cumulative: 21.67 ms) • Listen for signature – 46.67 ms (cumulative: 68.34ms)• Listen for certificate – 29.17 ms (cumulative: 97.51 ms)
– In practice, listening to full beacon will be rare