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
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>.
Voice: 973-386-6558
Email: sarvar@lucent.com
Outline
• Security functionality
– cryptographic functions vs primitive
• Creating cryptographic functions
• Choosing a cryptographic primitive or
algorithm
– AES vs RC4
Security has many parts
Key Provisioning
Entity
authentication
.
.
Session key
agreement
Message integrity
Security
Encryption mode
.
.
Encryption
algorithm
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.
Example
•Example of creating a cryptographic function from a
cryptographic primitive or algorithm.
Variable size input
512 bit input
Fixed MAC
160 bit output
HMAC
1.
2.
3.
Break input into 512 bit chunks
Iterate Fixed MAC on each chunk
Finally, run Fixed MAC an extra time
160 bit output
•The new function is secure if the primitive is secure!
•Gives flexibility without sacrificing security.
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
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.
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.
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.
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.
DES history
Attack
Complexity
Type of Attack
remarks
1973
NBS(NIST) solicits
proposals
1974
IBM submits Lucifer
1976
256
1985
252
1990
247 plaintexts
Differential
cryptanalysis
1993
243 plaintexts
Linear cryptanalysis
1994
768 plaintexts and
246 operations
Differential-linear
cryptanalysis
8 round DES
1995
32 plaintexts and 220
work
Differential
cryptanalysis with
partial differentials
6 round DES
1996
100,000 plaintexts
and 250 work
Linear cryptanalysis
w nonlinear approx
Brute force key
searching
NBS standardizes
DES
Reduced 6 rounds
DES
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.
AES history
• 1997 NIST requests proposals to replace DES.
• NIST selects 15 submissions for evaluation:
– CAST,Crypton,DEAL,DFC,E2,FROG,HPC,LOKI97,M
agenta,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.
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.
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.
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.
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.
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
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.
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!
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.
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.
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.
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)
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.
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.
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.