1 / 27

Project

Project. IEEE 802.20 Working Group on Mobile Broadband Wireless Access < http://grouper.ieee.org/groups/802/20/ >. Title. Functional Requirements for 802.20 Security. Date Submitted. 2004-07-12. Source(s). Sarvar Patel 67 Whippany Road, Whippany, NJ 07981.

zahur
Download Presentation

Project

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Project IEEE 802.20 Working Group on Mobile Broadband Wireless Access <http://grouper.ieee.org/groups/802/20/> Title Functional Requirements for 802.20 Security Date Submitted 2004-07-12 Source(s) Sarvar Patel67 Whippany Road,Whippany, NJ 07981 Voice: 973-386-6558Email: sarvar@lucent.com Re: MBWA Call for Contributions: Session # 9 - July 12-16, 2004 Abstract This document discusses security issues related to 802.20 requirements. Purpose Address 802.20 security. Notice This document has been prepared to assist the IEEE 802.20 Working Group. 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.20. Patent Policy The contributor is familiar with IEEE patent policy, as outlined in Section 6.3 of the IEEE-SA Standards Board Operations Manual<http://standards.ieee.org/guides/opman/sect6.html#6.3> and in Understanding Patent Issues During IEEE Standards Development <http://standards.ieee.org/board/pat/guide.html>.

  2. Outline • Security functionality • cryptographic functions vs primitive • Creating cryptographic functions • Choosing a cryptographic primitive or algorithm • AES vs RC4

  3. Security has many parts Key Provisioning Message integrity Entity authentication Security Encryption mode . . . . Session key agreement Encryption algorithm

  4. Creating cryptographic functions • We know how to build upon things • Given a building block (primitive), we know how to build many secure things: • Entity authentication and session key agreement protocol from a secure cryptographic algorithm. • Message authentication on large messages from a message authentication algorithm on a single block. • Encryption mode using a secure block cipher • Can give proofs of security • Under reasonable assumptions.

  5. Example • Example of creating a cryptographic function from a • cryptographic primitive or algorithm. Variable size input 512 bit input HMAC Fixed MAC • Break input into 512 bit chunks • Iterate Fixed MAC on each chunk • Finally, run Fixed MAC an extra time 160 bit output 160 bit output • The new function is secure if the primitive is secure! • Gives flexibility without sacrificing security.

  6. Choosing a cryptographic primitive or algorithm • Our protocols/functions only as good as the underlying algorithm. • Discussion emphasis on encryption • Can create other functionalities at least with block ciphers. • Encryption primitives • Block ciphers • Stream ciphers

  7. 3 most important things about an algorithm Security, Security, and Security! • Given good security then we can consider performance in software, hardware, memory usage, etc. • Designing algorithms involves some black magic. • Part science and part art. • Algorithm should be strong against known attack but no absolute confidence against all possible attacks.

  8. Design process • Let smart people design it and then see if other smart people can break it! • Need to motivate smart people to try attacking. • Need to be motivated for few years. • Lifecycle of the algorithm • 20 to 30 years. • Eventually, enough cryptanalysis succeeds that the algorithm needs to be replaced.

  9. What is an attack? • Brute force searching: • Tries all key values, e.g. 2128 operations to recover key for AES-128. • Cryptanalysis tries to exploit internal structure of the cipher. • Shortcut attack • if the complexity of the attack is less than brute force key searching. • Breaks the cipher in an academic sense even if not in practice. • e.g. a 280 operation method to recover the key would be considered a shortcut attack even if it is not feasible to perform currently in practice. • Presence of shortcut attacks widely used by cryptographic community to rule out selecting ciphers.

  10. Key recovery vs. distinguishing attacks. • Key recovering vs. distinguishing attacks. • Key recovery is easy to understand. • Distinguishing attacks for block cipher: • distinguish a block cipher from a random permutation • Distinguishing attack for stream cipher: • distinguish pseudorandom output from truly random bit stream • A distinguishing attack may be bad enough to actually lead to a break in encryption, • but more likely the assumptions used to build things are no longer true and we can no longer trust the security of our constructions. • A distinguishing attack even if not practical is used to rule out ciphers.

  11. DES history

  12. DES history • Many types of attacks discovered – most cryptanalyzed algorithm ever. • Some require too many plaintexts • Some only work against reduced round DES • Surprisingly, brute force still the best attack after all these years! • Needed a replacement because DES was aging • 56 bit key is too small • EFF built a special purpose machine to recover DES with brute force searching in 4 days. • 64 bit block size is also too small.

  13. AES history • 1997 NIST requests proposals to replace DES. • NIST selects 15 submissions for evaluation: • CAST,Crypton,DEAL,DFC,E2,FROG,HPC,LOKI97,Magenta,MARS,RC6,Rijndael,Serpent,Twofish • Round 1 results: Eliminated 10 algorithms that had major or minor security flaws after analysis and public comment. • 5 candidates: MARS,RC6,Rijndael,Serpent,Twofish. • October 2000 selects Rijndael after analysis and public comments on the finalists. • AES with 128 bits key size has 10 rounds. • Also AES with 192 and 256 key size are defined.

  14. AES Cryptanalysis: shortcut attacks • Square attacks • 7 round AES-192 and AES-256 faster than exhaustive search by Lucks in 2000. • 9 round AES-256 with 277 plaintexts, 256 related keys, and 2224 encryptions by Ferguson et al in 2000. • Collision attacks • 7 round AES by Gilbert and Minier in 2000. • Impossible Differentials attack • 5 round AES by Biham and Keller in 2000. • 6 round AES by Cheon et. al in 2001.

  15. AES cryptanalysis: algebraic ideas • None below show a faster than exhaustive attacks. • Since AES can be represented mathematically doesn’t mean it is simple to solve. • Other algebraic problems remain intractable. • Ferguson, Schroeppel and Whiting, “A simple representation of Rijndael” 2001. • Results in an equation with 226 unknowns. • No practical algorithm known to solve such an equation • Courtois and Pieprzyck, “ Cryptanalysis of block ciphers with over defined system of equations” Asiacrypt 2002. • Don Coppersmith states that “I believe that the Courtois-Pieprzyk work is flawed. They over count the number of linearly independent equations. The result is that they do not in fact have enough linear equations to solve the system.” • Murphy and Robshaw “Comments on the security of the AES and the XSL technique”. • They say cannot trust the estimate for number of equation in previous reference.

  16. RC4 Cryptanalysis • Shortcut attacks against RC4 • n=5, state can be recovered in 242 steps vs. key space of 2160. • 230 bytes to distinguish RC4 vs. random. • 2nd byte has bias. 200 streams needed to distinguish RC4 from random. • 1st byte has bias. 1700 first bytes needed to distinguish RC4 from random. • Existence of distinguishing attack means we cannot naively use RC4 to securely build other things. • Shortcut attacks even academic ones are sufficient to rule out the cipher for longterm use.

  17. WEP to 802.11i: • RC4  AES • They chose AES for longterm solution instead of RC4! • Given the bad publicity of WEP, it was important to show they are serious about security. • They showed this by moving to a strong encryption algorithm AES. • For wireless situation they found AES flexible enough.

  18. Speed of AES vs. RC4 • Compared on Pentium: www.eskimo.com/~weidai/benchmarks.html • RC4 speed is less than 2 times (1.77x) AES speed in software according to above site. • AES-128 runs at 62MB/sec • RC4 runs at 110MB/sec

  19. Stream ciphers as powerful as block ciphers? • Both are sufficient for encryption. • Can do more things with a block cipher in general. • Block ciphers take two arguments: 1) key and 2) plaintext. • Stream ciphers only take key as an argument. • Argument useful for things like challenge/response protocols and session key derivation. • Easy to go from block cipher (pseudorandom permutation) to stream cipher (pseudorandom generator). • Not easy to create block cipher from stream cipher.

  20. US Govt use of AES • Classification: • Unclassified • Sensitive but unclassified • Confidential – lowest classification level. • Secret – the second highest classification. • Top secret – the highest security level, includes such information as cutting edge weaponry, etc. • Nov 2001 FIPS197 endorsed AES for sensitive data. • NSA (2003) endorses AES for Secret and Top secret! • In CNSS Policy No. 15, Fact Sheet No. 1. • This is incredible since DES was only endorsed for sensitive but unclassified. • The endorsement by NSA is after all the potential attacks on AES. The attacks must be assumed to be not significant. • Equipment sold to US Govt may need AES anyway!

  21. Europe (Nessie) selects AES • Nessie is a project of the European commission • Solicited submissions for various algorithms including block and stream ciphers. • European version of AES for many more algorithms. • AES was chosen as a approved 128 bit block cipher. • No stream cipher was good enough! • Most didn’t have enough security. • The most secure one was based on AES by extracting hard bits, but was considered too slow.

  22. IETF brings in AES • RFCs to bring in AES in to IPSEC. • RFC 3268 brings AES in to TLS, it states: • “RC2,RC4, and IDEA are all subject to IP claims. RSA Security Inc. has trademark rights in the name RC2 and RC4, and claims that the RC4 algorithm itself is a trade secret.” • “Now that the AES process is completed there will be commercial pressure to use the selected cipher. The AES is efficient and has withstood extensive cryptanalytic efforts. The AES is therefore a desirable choice.” • SRTP uses AES for encryption.

  23. 3GPP and 3GPP2 use Rijndael • 3GPP chose AES for its MAC and key derivation functions. • Actually it chose Rijndael before it was the winner of AES. • It had chosen Kasumi for encryption before AES was finalized. • 3GPP2 chose AES for the encryption algorithm. • There was intensive effort to agree on a cipher, many company specific proposals were made. • Once AES winner was announced it became clear to all that we have to standardize on AES.

  24. Evaluation ? • Quality of cipher is usually “measured” by confidence people have that cipher does not get broken in next N years. • Not measured simply by best known attack against it. • E.g. no confidence in a new cipher. • Standardization committee like 802.20 simply does not have enough time to evaluate a cipher properly. • Hence should rely on evaluation efforts of others like NIST and Nessie. • Furthermore, modified RC4 suggested is like a new cipher! • NIST reviews every 5 yrs for re-endorsement • Its too late if attack makes it to publication • Will 802.20 be able periodically re-evaluate? • Again its best to rely on efforts of other (i.e. NIST)

  25. Summary • RC4 has suffered significant attacks making it not viable for longterm standardization. • Most everybody for good reason is moving towards AES. • Speed difference in software may not be that dramatic. • AES is efficient in hardware also. • AES has no known shortcut attacks.

  26. Summary • Geographically diverse endorsement of AES: NIST in N. America and Nessie in Europe). • Various standards moving towards AES including IETF, 802.11i, 3GPP2, 3GPP. • NSA endorses AES for Top secret classified data! • Much more than DES ever was.

  27. Conclusion • 802.20 would be well served with AES. • 802.20 can begin the task of selecting or building secure protocols and functionality using AES as a secure block.

More Related