22090216000000proposedresolutionstocommentsrelatedtosecurityin80222draftv20Word文档格式.docx

1、CompanyAddressPhoneemailApurva ModyBAE SystemsP.O. Box 868, MER 15-2350, Nashua, NH 03061-0868603-885-2621404-819-0314apurva.mody, apurva_modyTom KiernanUS Army （CERDEC）Ft Monmouth, NJ-Thomas.kiernanus.army.milRanga ReddyFt. Monmouth, NJRanga.reddyus.army.milAbstractThis document contains the propos

2、ed resolutions to comments related to Security in 802.22 Draft v2.0 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 fo

3、rm 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 creati

4、on of an IEEE Standards publication; to copyright in the IEEEs name any IEEE Standards publication even though it may include portions of this contribution; and at the IEEEs sole discretion to permit others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor al

5、so 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 , including the statement IEEE standards may include the known use of patent（s）, including patent applications

6、, 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 re

7、duce 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 as early as possible, in written or electronic form, if patented technology （or technology under patent application） might be in

8、corporated into a draft standard being developed within the IEEE 802.22 Working Group. If you have questions, contact the IEEE Patent Committee Administrator at .Remaining security comments that need to be resolved:298, 356, 361, 1346, 403, 404, 407, 473, 474, 505, 506, 508, 509Comments 298, 356, 36

9、1, 1346, 403, 404, 407 were assigned to the Security ad-hoc by the MAC ad-hoc. Comments 473, 474, 505, 506, 508, 509, 511, 512, 523 are related to security issues, and should be handled by the Security ad-hoc as well.Comments 674, 717, 719, 725, 726, 731, 732 are comments deferred during Security ad

10、-hoc calls. Discussion on those comments are provided hereComment 298Comment:Why are the CBP burst to be protected. Arent they broadcast packets by definition for inter-cell coexistence among different WRAN cells. If these cells belong to the same network that needs protection, everything could be d

11、one over the backhaul.Suggested Remedy:Reconsider the need for security on the CBP bursts since any WRAN operator will need to know how to decode it to act upon it and therefore will be able to mess with it and change the text accordingly.Resolution （as currently discussed）:Problem is from malicious

12、 users creating false CBP bursts. Since any WRAN operator will need to know how to decode these CBP bursts to act upon it, they will therefore be able to mess with it. What is the need for securing these CBP bursts then? Also, the bursts giving identity as per the FCC R&O would need to be in the cle

13、ar. Assigned to the security ad-hoc group for resolution.Initial Feedback from Security Adhoc:The desire to protect the CBP is to keep malicious users/operators from preventing legitimate users/operators from using available channel and engaging in coexistence operations. The current procedure （in s

14、ummary） uses a public key to sign the CBP burst, the signature is then added to the CBP burst when transmitted. Upon reception of the burst, the receiving BS would use the key of the transmitting BS to verify the signature （e.g. authenticate the signature）. If verification fails, then the CBP would

15、have to be dropped. Signing of the data burst involves processing the burst through some mathematical function, whose behavior is “modulated” by an input key. The burst data itself is not modified in anyway. So, using signatures doesnt hide the data, like encryption does. This means that the burst i

16、s still readable by the receiving BS. Now if the receiving BS doesnt have the public key of the transmitting BS or doesnt support the CBP authentication via signature, it obviously cannot verify the signature. In this case, the receiving BS can choose to either ignore the signature and go on to proc

17、ess the CBP, or possibly execute a certificate exchange to get the transmitting BSs certificate so it can properly verify CBP bursts in the future.Now, having described the procedure that is currently implemented, let us describe some of the other ways that errors can be detected in packet transmiss

18、ions and provide some reasoning as to why the security ad-hoc chose its current approach:1. Cyclic Redundancy Check （CRC） is a non-secure method to create an error-detecting code, whereby the data is divided by a known polynomial, generates a CRC value that would be appended to a packet during trans

19、mission. Upon reception, the receiving node re-calculates the CRC value, and if there is a difference, its assumed there is some kind of error, and the packet would then be discarded. The problem is, that depending on the length/type of CRC polynomial, it is possible to hack the data in such a way t

20、hat when the CRC is calculated, the CRC output will be the same as for the unmodified data stream. IEEE 802.3 uses a specific polynomial that is 32 bits long and CRC values that 32bits （4 octets） long.2. Hashing algorithms like MD5 and SHA-1 are used to provide the same capability as a CRC, but the

21、mathematical formula is supposed to be more secure that a simple CRC. Unfortunately, it has been recently discovered, that MD5 and SHA-1 still have a collision vulnerability. This means it is possible to have two data sets/packets that generate the same MD5/SHA-1 hash value. Because of this, NIST is

22、 deprecating use of SHA-1 in any federal （US） standards, and suggesting moving onto SHA-2 （SHA with 224, 256, 384, or 512 bit signature/hash） for any hash/signature calculations. SHA-2 hashes can range in 28, 32, 48, 64 octets.3. Even if you specify SHA-2, using a hash algorithm without modulating w

23、ith some key is not a good approach. That is what HMAC is for. HMAC requires that a key be applied to the hashing algorithm to make it more secure. But this then requires a key to be distributed?Knowing that a simple CRC or earlier-generation hash algorithm wouldnt be sufficient, the security ad-hoc

24、 went looking for protocols that would avoid some the issues that have been described. That is why the TG1 approach has been adopted. The security ad-hoc decided that it would be a good idea to pursue the current method, because from the TG1 perspective, the base standard would have to include ECC c

25、ertificate identification capability to verify TG1 beacons to be compatible with the TG1 standard. If this was the case, then why not adapt the TG1 approach?This approach uses keys from an ECC implicit certificate to sign TG1 beacons. It is as compact as possible, while providing an adequate amount

26、of security. We have made some adaptations to this process. We do not use the ECC certificate key to sign the CBP burst directly to sign the message, instead we use it to derive a key to sign the CBP burst with GMAC （which is the AES-GCM version of HMAC）. The signature of this output is only 8 octet

27、s, much smaller than the smallest SHA-2 output and smaller than the TG1 beacon signature output. We feel the certificate exchange process should be kept in the standard. If it is engaged, it would be only be done so infrequently, so the impact of using it would be minimal. There are some higher-laye

28、r and network issues （which are highlighted in Section 7.6.8 of P802.22/D2） with using this approach when an operator is setting up this network. These issues would have to either be addressed in TG2 or within an industry forum.Now having said all of this, in the year or so, since our method was dev

29、eloped, lots of things have changed. The wireless mic industry doesnt want to make use of TG1 beacons. Also the FCC R&Os treatment of microphone beacons may change. If this is case, then the use of the at all TG1 beacon is put into question and justification of our use of the ECC method in the base

30、standard, because TG1 is using it, will have to be re-evaluated. Also, remember, use of CBP protection mechanism is optional. We define it in the base standard to allow for operators to implement as they see fit. And let us not forget the requirements for accessing the database. If BSs, and CPEs for

31、 that matter, require their own credentials, then quite possibly the infrastructure for generating and distributing the certificates may be in place, so the impact to the operator should be minimized.Comment Status:Security ad-hoc suggests that membership should re-review the CBP protection mechanism for security issues, and defer this comment until we have a clearer picture regarding the requirements as stated in the R&O.Comment 356, 361, 473, 474, 505, 506, 508, 509 From C