March 2007 doc IEEE 802 22 070137 r

March 2007 doc. : IEEE 802. 22 -07/0137 r 0 Public-Key Security for IEEE 802. 22 TG 1 IEEE P 802. 22 Wireless RANs Date: 2007 -03 -14 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 patcom@iee. org. > Submission 1 Ed Callaway, Motorola

March 2007 doc. : IEEE 802. 22 -07/0137 r 0 Abstract Given the complexity of key management in symmetric-key based security we provide an alternate security solution for IEEE 802. 22 TG 1 based on asymmetrickey (a. k. a. public-key) cryptography. Our presentation describes an asymmetrickey 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. Submission 2 Ed Callaway, Motorola

March 2007 doc. : IEEE 802. 22 -07/0137 r 0 Cryptography Review Beacon Header MIC Symmetric-Key • Small key • Fast • Small MIC (4 bytes) MIC Generation MIC Verification Time Valid Invalid Time Key Beacon Header Key Equal Signature Securely Shared Beacon Header Signature Asymmetric-Key • Simpler key-management • Signature (~80 bytes) Signature Generation Signature Verification Time Not Equal Private Key Submission 3 Time Public Key Valid Invalid From Certificate Ed Callaway, Motorola

March 2007 doc. : IEEE 802. 22 -07/0137 r 0 Example Symmetric Key Management Issue License FCC Deploy Beacon Sell Beacon Licensee Issue Beacon Smart Card (with MAC and long-term key) Beacon (with beacon smart card) Transmit Beacon Frame Submission Licensed Device Authority Deliver Key Database Request Verification or Session Key On-Line Verifier MAC/ Keys Unlicensed Device Authority Issue WRAN Smart Card Deliver Response WRAN-BS (with WRAN smart card) Beacon Manufacturer Deploy WRAN-BS 4 Unlicensed Device Operator Ed Callaway, Motorola

March 2007 doc. : IEEE 802. 22 -07/0137 r 0 Example Asymmetric Key Management Issue License FCC Deploy Beacon Sell Beacon Licensee Issue Beacon Smart Card (with MAC and private key) Beacon (with beacon smart card) Transmit Beacon Frame Licensed Device Authority Publish single public key Publish blacklist Website One-time load of public key Occasional check of blacklist Significant Simplification! Any Unlicensed Device (e. g. , WRAN BS or CPE) Submission Beacon Manufacturer 5 Ed Callaway, Motorola

March 2007 doc. : IEEE 802. 22 -07/0137 r 0 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 realtime 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) Submission 6 Ed Callaway, Motorola

March 2007 doc. : IEEE 802. 22 -07/0137 r 0 Proposed TG 1 Frame Structure 2. 498 ms Index N Sync Index N-1 Sync Index 1 Beacon Frame Rx ANP Rx Sync 2. 498 ms Sync Index N-1 Sync Beacon Frame 111 octets 92. 51 ms PHR P 1 MAC Address Location P 2 P 3 CRC 1* Channel Map Signature CRC 2* Certificate CRC 3* 1 1 6 8 1 1 2 5 49 2 33 2 20 octets 16. 67 ms 56 octets 46. 67 ms Beacon Header 35 octets 29. 17 ms Beacon Signature and Certificate * Note: the “CRC” subfields are used by a recipient to independently detect bit errors in the various subfields Submission 7 Ed Callaway, Motorola

March 2007 doc. : IEEE 802. 22 -07/0137 r 0 Multiple Options for Unlicensed Devices Use Channel No Detect sync and index? (5 ms) Yes Change Channel No Want more info? Yes Detect beacon header (16. 67 ms) No Detect beacon signature (46. 67 ms) Need certificate? Interference from beacon tolerable? Detect beacon certificate (29. 17 ms) Submission No Only under rare circumstances, the unlicensed device can choose to expend an additional 46. 67 ms of overhead to authenticate a suspicious beacon. No Yes No The unlicensed device has a choice of whether to expend an additional 16. 67 ms of overhead to acquire the beacon header. Suspicious Beacon? Yes Predominant overhead is just 5 ms. Beacons will be rare and, for the most part, an unlicensed device can simply change channels when it sees a sync/index Bogus Beacon? 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. Yes 8 Ed Callaway, Motorola

March 2007 doc. : IEEE 802. 22 -07/0137 r 0 Conclusions • Key management with symmetric keys imposes excessive burdens – Two unappealing options: Broadcasters trust unlicensed entities or online 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 Listen for header – Listen for signature Listen for certificate – 16. 67 ms – – 5 ms (cumulative: 21. 67 ms) 46. 67 ms (cumulative: 68. 34 ms) 29. 17 ms (cumulative: 97. 51 ms) – In practice, listening to full beacon will be rare Submission 9 Ed Callaway, Motorola