12
research & development Design and Analysis of Cryptographic Algorithms for Mobile Communication Systems Henri Gilbert Orange Labs {[email protected]} research & development Orange Group development of 3G algorithms (2) outline development of cryptographic algorithms for a real life application introduction cryptographic features of 2G and 3G systems algorithms development process within ETSI/SAGE approach to design / specification / evaluation links with academic research case studies 1999: KASUMI block cipher + resulting encryption (UEA1, A5/3) and MAC (UIA1) 2005: SNOW 3G stream cipher + resulting encryption (UEA2) and MAC (UIA2) 2000: MILENAGE authentication and key generation algorithm

outline - COSIC€¦ · motivation: standard CBC-MAC would have resulted in a forgery attack after 232 messages development of 3G algorithms (16) research & development Orange Group

  • Upload
    others

  • View
    2

  • Download
    0

Embed Size (px)

Citation preview

research & development

Design and Analysis of Cryptographic Algorithms

for Mobile Communication Systems

Henri GilbertOrange Labs

{[email protected]}

research & development Orange Groupdevelopment of 3G algorithms (2)

outline development of cryptographic algorithms for a real life application

introductioncryptographic features of 2G and 3G systems

algorithms development process within ETSI/SAGE

approach to design / specification / evaluation

links with academic research

case studies1999: KASUMI block cipher + resulting encryption (UEA1, A5/3) and MAC (UIA1)

2005: SNOW 3G stream cipher + resulting encryption (UEA2) and MAC (UIA2)

2000: MILENAGE authentication and key generation algorithm

research & development Orange Groupdevelopment of 3G algorithms (3)

security in mobile systems

security aspects:

Radio access network

MS = ME + (U)SIM

Core Network External networks(PSTN, IP…)

radio accessterminal core network e2e transactions

research & development Orange Groupdevelopment of 3G algorithms (4)

cryptographic algorithms of GSM

subscriber authentication

authentication & key generation algorithms A3/A8permanent subscriber key Ki (SIM & HLR)A3/A8 is not standardized (operator dependent)

traffic and signalling encryption

circuit switched GSM: standard A5 algorithms A5/1, A5/2, A5/3

packet oriented GSM (GPRS):standard GEA algorithms GEA1, GEA2, GEA3

RAND (challenge)

A3/A8

KcSRES

Ki

Kc

IV (frame nb.)

A5

114-bit keystream

128

6432

128

Kc*

IV

GEA

5 to 1600-byte keystream

22

33

64

64

(counter, dir.)

research & development Orange Groupdevelopment of 3G algorithms (5)

HLR/AuCMSC/VLRBTS

RANDKi

A3/A8SRES

Kc

checksSRES

Kc, start enc.start enc.

ACK

IV(frame nb.) A5 A5

114-bit keystream 114-bit keystream

+ +plain traffic &sig.

Kc

SIM

encrypted traffic & sig.

visited network

homenetwork

RAND

A3/A8

KcSRES

n triplets (RAND, SRES, Kc)

KiME

GSM SECURITY: OVERVIEW

IV(frame nb.)

plain traffic& sig.

off lineon line

research & development Orange Groupdevelopment of 3G algorithms (6)

limitations of GSM security

no network authentication and no explicit integrity protectionmoreover encryption initiative is left up to the network

eavesdropping attacks using false base stations turned out to be a reality…

⇒ UMTS: network authentication and signalling messages auth.

⇒ GSM and UMTS: encryption indicator (in some mobiles)

limitations of GSM encryptionencryption ends at the base station => vulnerability of the BTS-BSC interface

efficient attack on A5/2, gradual erosion of the protection offered by A5/1 [Biham et al.]

⇒ UMTS: strong encryption (128-bit key, hopefully full strength), ends at RNC

⇒ GSM: move to A5/3 (derived from 3G algorithm KASUMI)

research & development Orange Groupdevelopment of 3G algorithms (7)

cryptographic features of UMTS mutual authentication (slightly simplified)

subscriber auth. ≈ GSM authgeneration of session keys CK and IK network auth. ≈ MAC of sequence nb. SQNSQN anonymization: mask AK

f1-f5 also named AKA (auth. & key agreement)no standard AKA; example AKA: MILENAGE

traffic and signalling encryptiontwo standard f8 algorithms

• UEA1 derived from KASUMI• UEA2 derived from SNOW 3G

message authenticationtwo standard f9 algorithms

• UEA1 derived from KASUMI• UEA2 derived from SNOW 3G

RAND SQN AMF

K

RES CK IK AK MAC-A64 128 128 48 64

f1f2 f3 f4 f5

48 16128

CK f8

IV (count-c, bearer, dir.)

keystream

f9IK

MAC

message+ (count, fresh, direction)

128

128

128

128

32

research & development Orange Groupdevelopment of 3G algorithms (8)

HLR/AuC

MSC/VLR

RAND, AUTNK

f1-f5RES

CK

checks RES

start enc., CK, IKstart enc.ACK

IV IVf8 f8

+ +{ DATA || MAC }

CK

USIM RAND, SQN

home

network

f1-f5

RES IK CK AUTN

n quintets(RAND,RES,IK,CK, AUTN)

KRNC

checks AUTN

f9count, fresh

IK

{ DATA || MAC }

f9count, freshchecks

MAC

ME

UMTS SECURITY: OVERVIEW

encrypted traffic & sig.

Node-B

research & development Orange Groupdevelopment of 3G algorithms (9)

ETSI/SAGEwhat's that?

security algorithms group of experts of European Telecommunication Standard Institute

in charge of security algorithms standardisation for telecommunications

‒ mobile communication systems: 2G (GSM/GPRS), 3G (UMTS) …

‒ other systems: radio lans, teleconferencing, smart cards, inter-PNO exchanges, TETRA

created in the early 90's

initial mandate included liaison with national authorities to get export approval

membershipclosed group: no longer for secrecy reasons, for efficiency reasons

~ 10 telecom. operators or manufacturers with strong cryptography expertise

chaired by Gert Roelofsen until he left KPN research

and since then by Steve Babbage, Vodafone

research & development Orange Groupdevelopment of 3G algorithms (10)

export controls before 98

strong export restrictions on encryption, in particular for mobile systems ‒A5/1 was much stronger than ciphers that were freely exportable at that time

no transparent rules, case by case approvalSAGE algorithms were not published ‒ this was needed to get export approval ‒ however, for massively deployed algorithms, secrecy does not last long…

since 98 (Wassenaar agreements)export controls still exist…… but have been considerably eased and are no longer a real issue for mobilesSAGE moved to public algorithms soon after 98‒☺ increase public confidence‒☺ take advantage from publicly available designs‒ other less decisive pros & cons: ☺ public evaluation after deployment, increased vulnerability to side channel attacks

research & development Orange Groupdevelopment of 3G algorithms (11)

SAGE approach to algorithms development "balance the benefits of public evaluation against industry timescales" [S. Babbage]1. take the best from available research results

investigate most promising public designsadapt design to specific requirements of the intended application taking most recent advances in cryptanalysis into account

2. algorithm design /specification / evaluation workset-up a project team with clear timescales and allocation of taskssplit participants into separate design and evaluation teams‒ requirements capture (all)‒ design team: 1st design, 2nd design, final design‒ evaluation team: mathematical evaluation, statistical testing

output: specification, ref. implementation and spec.testing, design & eval. report

3. Independent evaluation and follow-on researchevaluation reports by well known academic expert teams (limited evaluation time)monitoring of (and often contribution to) follow-on public research

research & development Orange Groupdevelopment of 3G algorithms (12)

Case study 1: KASUMI, UEA1, UIA1 (1999)requirements (in brief)

stream cipher f8 and MAC f9‒ security: full strength‒ low H/W complexity‒ good H/W and S/W performance‒ f8: good IV agility

⇒ block cipher with stream cipher & MAC modes ‒ for flexibility reasons

available research results to start from strategies to thwart statistical attacks:‒ [Daemen-Rijmen]: wide trail strategy‒ [Vaudenay]: decorrelation theory and resulting block ciphers‒ [Nyberg-Knudsen, Aoki]: differential & linear bounds on 3R-Feistel schemes

[Matsui]: application to the embedded construction of MISTY block cipher⇒ MISTY (a 64-bit block cipher) was selected as the starting point for the design

‒ MISTY's designer, M. Matsui (Mitsubishi) joined SAGE ‒ KASUMI (≈ "misty" in Japanese) was designed

CK f8

IV count-c bearer dir.

keystream

f9IK

MAC

message, count, fresh, dir.

128

128

research & development Orange Groupdevelopment of 3G algorithms (13)

KASUMIS9

S7

S9

zero-extend

zero-extend

truncate

KIij1 KIij2

169 7

FO FI

bitwise AND operationbitwise OR operationone bit left rotation

3216 16

KLi1

KLi2

S7truncate

FIi1 KIi1KOi1

FIi2 KIi2KOi2

FIi3 KIi3KOi3

16 1632

FL

FO1FL1

FO3FL3

FO5FL5

FO7FL7

FO2 FL2

FO4 FL4

FO6 FL6

FO8 FL8

KL1 KO1, KI132 3264

KL6

KL8

KL7

KL2

KL5

KL4

KL3

KO2, KI2

KO3, KI3

KO4, KI4

KO5, KI5

KO6, KI6

KO7, KI7

KO8, KI8

plaintext (64 bits)

ciphertext (64 bits)

Main changes from MISTY1- 4th round in FI- FL: modified location, rotation - new S-boxes S7 and S9- simplified key schedule

↓≈ same conjectured securityslightly lower H/W complexity

F

research & development Orange Groupdevelopment of 3G algorithms (14)

KASUMI-based f8: UEA1

CK(128 bits)

IV(64 bits)

keystream KS

non-standard mode, combination of:-"prewhitening" (computation of secret A),- CNT mode- OFB mode

64-bit blocksize => standard modes would have resulted in strong 232-block distinguishers

research & development Orange Groupdevelopment of 3G algorithms (15)

KASUMI-based f9: UIA1

data

IK(128 bits)

auth. tag (32 bits)

non-standard mode again - CBC-MAC variant - 128-bit "chaining variable" instead of 64

motivation: standard CBC-MAC would have resulted in a forgery attack after 232 messages

research & development Orange Groupdevelopment of 3G algorithms (16)

KASUMI, UEA1, UIA1 (end)

independent evaluationfrom three well known academic teams coordinated by leading ECRYPT partners…in overall, confirmed soundness of proposed algorithms(some suggested variations not supported by strong cryptanalytic arguments against the evaluated specification were not retained)

follow on researchf9 forgery from 248 chosen message MACs [Knudsen-Mitchell]whether forgery from 232 chosen message MACs feasible as for standard modes is still opensuper-pseudo-randomness of 5-round MISTY [2 ind. papers at FSE 00]pseudo-randomness of expanding functions inspired from f8 and MILENAGE [Gilbert]algebraic interpretation of higher order differential properties of MISTY [Babbage-Frisch]research on modes of operation…

research & development Orange Groupdevelopment of 3G algorithms (17)

Case study 2: SNOW 3G, UEA2, UIA2 (2005)

requirements (in brief)same as UEA1, UIA1, but fallback algorithms set‒ maximize "cryptographic distance" from KASUMI‒ minimize potential vulnerability to algebraic attacks

⇒ stream cipher + UH MAC approach seemed worth being investigated

available research results to start from (stream ciphers)NESSIE had failed selecting a stream cipher, but:‒ had stimulated the design of IV-dependent stream ciphers‒ had resulted in cryptanalytic advances, e.g. linear masking attacks [Coppersmith et al.]

ECRYPT / eSTREAM stream ciphers project had just started‒ SASC workshop gave an accurate picture of the state of the art

⇒ SNOW 2.0 [Ekdahl-Johansson] was retained as a starting point for the design with permission

of its authors. ‒ its resistance to linear masking & algebraic attacks had been analysed

[Watanabe et al., Billet-Gilbert]

research & development Orange Groupdevelopment of 3G algorithms (18)

from SNOW 2.0 …

R1 R2S

α-1 α

s0s2s5s11s15

current state: - LFSR: 16 32-bit words- FSM memory: 2 32-bit words

32x32 S-box S- based on AES

research & development Orange Groupdevelopment of 3G algorithms (19)

to SNOW 3G

R1 R2S1

α-1 α

R3S2

s0s2s5s11s15

Main changes from SNOW 2.0:-additional memory word R3-additional 32x32 S-box S2based on Dickson polynomials

=> extra security margin against algebraic & linear masking attacks

research & development Orange Groupdevelopment of 3G algorithms (20)

SNOW 3G, UEA2, UIA2 (cont.)

available research results to start from: UH function-based MACs

Wegman-Carter paradigm: MAC(M) = hk(M) ⊕ OTP,

where {hk} is an almost 2-universal family of hash functions

many efficient UH MACs based on polynomials had been recently proposed hk(M) = PolyM(k), typically over GF(2n)

how to best derive k and OTP from IK using a streamcipher was unclear

research & development Orange Groupdevelopment of 3G algorithms (21)

message authentication f9: UIA2

SNOW 3G

IV

IK

128

128

COUNT-CBEARERDIRECTION

M = (M0,..,Mt) PolyM(P)

P Q

OTP

MAC

64 64 32

computations are done over GF(264)

• 32–bit OTP, but also 128-bit hash key (P,Q), is

derived fom IK using SNOW 3G

(conservative choice)

MAC = hPQ(M) ⊕ OTPwhere hPQ(M) = (PolyM(P) •Q) truncated to 32 bits

multiplication by Q allows to keep forgery proba.

close to ideal value 2-32, even for long messages:

2-stage MAC construction [Stinson 92, Bierbrauer

et al. 93, Neversteen-Preneel 99, Bernstein 05]

Truncate

hPQ

32 bits

research & development Orange Groupdevelopment of 3G algorithms (22)

SNOW 3G, UEA2, and UIA2 (end)

independent evaluationtwo well known academic teams (coordinated by leading ECRYPT partners…)

various potential lines of attack were investigated

in overall, confirmed SAGE confidence in proposed design

follow on researchimproved linear masking on SNOW 2.0 [Nyberg-Wallen]

note about how to improve truncated G-MAC [Nyberg-Gilbert-Robshaw]

warning about key recovery attacks on some polynomial based UH MACs

when unlike in UIA2 hash key is not renewed [Handschuh-Preneel, Crypto 08]

research & development Orange Groupdevelopment of 3G algorithms (23)

conclusion

cryptographic research and standardisation are distinct processes…distinct objectives, distinct timescalesresearch must not be entirely driven by the requirements of applicationsstandardisation may have to deal with problems research did not / cannot solve

…but they must interact closely standardisation groups and the research community must not be disjointthe research and scientific exchanges promoted by ECRYPT and ECRYPT II in the future are quite useful to achieve this kind of interaction

next cryptography standardization challenges in mobiles?other security aspects (underway)massively deployed public key cryptography in (U)SIMs?