1

UMTSSecurity UMTSSecurity UMTSSecurity UMTSSecurity

Date Date Date Date: :: : 20.11.2009
Revision: Revision: Revision: Revision: 008/UMS/009
Author: Author: Author: Author: JakubBluszcz

Leliwa Technical Bulletin
C
o
p
y
r
i
g
h
t

©
2
0
1
0

L
e
l
i
w
a
.

A
l
l

R
i
g
h
t
s

R
e
s
e
r
v
e
d
.

LeliwaTechnicalBulletinUMTSSecurity

2
Tableofcontents Tableofcontents Tableofcontents Tableofcontents
Topic Topic Topic Topic Page Page Page Page
Introduction.....................................................................................................3
Useridentityconfidentiality .............................................................................3
Entityauthentication .......................................................................................7
Confidentiality...............................................................................................15
Dataintegrity ................................................................................................20
UMTS–GSMinteroperation..........................................................................22
AcronymsandAbbreviations ........................................................................32
References ...................................................................................................34
Disclaimer.....................................................................................................35

UMTSSecurityLeliwaTechnicalBulletin

3
Introduction Introduction Introduction Introduction
Thisdocumentdescribesthesetofsecurityfeaturesthatprovideuserswith
secureaccessto3Gservices,andwhichinparticularprotectagainstattacks
onthe(radio)accesslink.
UMTSoffersthefollowingsecurityfeatures(seeFig.1):
UMTS security features
user identity confidentiality,
authentication of the user toward the network,
authentication of the network toward the user,
confidentiality (ciphering),
data integrity.

Figure1UMTSsecurityfeatures
AsinGSM/GPRS,user(temporary)identification,authenticationandkey
agreementtakesplaceindependentlyineachservicedomain.Userplane
trafficiscipheredusingthecipherkeyagreedforthecorrespondingservice
domainwhilecontrolplanedataiscipheredandintegrityprotectedusingthe
cipherandintegritykeysfromeitheroneoftheservicedomains.
Useridentityconfidentiality Useridentityconfidentiality Useridentityconfidentiality Useridentityconfidentiality
Thepermanentuseridentity(IMSI)ofausertowhomaservicesisdelivered
cannotbeeavesdroppedontheradioaccesslink.Toachievethis,theuseris
normallyidentifiedbyatemporaryidentitybywhichheisknownbythevisited
servingnetwork.
Thismechanismallowstheidentificationofauserontheradioaccesslinkby
meansofaTemporary/Packet-TemporaryMobileSubscriberIdentity
(TMSI/P-TMSI).ATMSI/P-TMSIhaslocalsignificanceonlyintheLocation
Area(LA)orRoutingArea(RA)inwhichtheuserisregistered.Outsidethat
areaitisaccompaniedbyanappropriateLocationAreaIdentification(LAI)or
RoutingAreaIdentification(RAI)inordertoavoidambiguities.The
associationbetweenthepermanentandtemporaryuseridentitiesiskeptby
theVLR/SGSNinwhichtheuserisregistered.
LeliwaTechnicalBulletinUMTSSecurity

4
MSC/VLR
SGSN
C
o
r
e

N
e
t
w
o
r
k
TMSI
P-TMSI
IMSI
IMSI
RAN
TMSI¯ ¯¯ ¯IMSI
P-TMSI¯ ¯¯ ¯IMSI

Figure2Useridentityconfidentiality
TheTMSI/P-TMSI,whenavailable,isnormallyusedtoidentifytheuseron
theradioaccesspath,forinstanceinpagingrequests,locationupdate
requests,attachrequests,servicerequests,connectionre-establishment
requestsanddetachrequests.
Toavoidusertraceability,whichmayleadtothecompromiseofuseridentity
confidentiality,theuserisnotidentifiedforalongperiodbymeansofthe
sametemporaryidentity.Inadditionanysignallingoruserdatathatmight
revealtheuser'sidentityiscipheredontheradioaccesslink.
IfaTMSIprovidedbyanMSisunknowninthenetworke.g.duetoadata
basefailure,thenetworkrequirestheMStoprovideitsIMSI.Inthiscasethe
identificationprocedureisusedbeforetheTMSIreallocationprocedureis
initiated.
ThereallocationofaTMSIcanbeperformedeitherbyauniqueprocedure
describedinthenextsectionorimplicitlybyalocationupdatingprocedure.
TMSIreallocationprocedure TMSIreallocationprocedure TMSIreallocationprocedure TMSIreallocationprocedure
ThepurposeoftheTMSIreallocationprocedureistoallocateanew
TMSI/LAIpairtoauserbywhichhemaysubsequentlybeidentifiedonthe
radioaccesslink.Theprocedureisperformedaftertheinitiationofciphering.
TheallocationofatemporaryidentityisillustratedinFig.3.
TMSIn, LAIn /
P-TMSIn, RAIn
(P-)TMSI Allocation Command
(P-) TMSI Allocation Complete
SGSN
VLR

Figure3TMSIallocation
UMTSSecurityLeliwaTechnicalBulletin

5
OTheVLRgeneratesanewtemporaryidentity(TMSIn)andstoresthe
associationofTMSIn

andthepermanentidentityIMSIinitsdatabase.The
VLRthensendstheTMSIn

andoptionallythenewlocationareaidentityLAIn
totheuser.UponreceipttheuserstoresTMSIn

andautomaticallyremoves
theassociationwithanypreviouslyallocatedTMSI.
OTheusersendsanacknowledgementbacktotheVLR.Uponreceiptofthe
acknowledgementtheVLRremovestheassociationwiththeoldtemporary
identityTMSIoandtheIMSI(iftherewasany)fromitsdatabase.
DistributionofIMSIandauthenticationdata DistributionofIMSIandauthenticationdata DistributionofIMSIandauthenticationdata DistributionofIMSIandauthenticationdata
IncaseauseridentifiesitselfusingaTMSIo/LAIopairthatwasnotassigned
bythevisitedVLRnandthevisitedVLRnandthepreviouslyvisitedVLRo
exchangeauthenticationdata,thevisitedVLRnrequestthepreviouslyvisited
VLRotosendthepermanentuseridentityandoptionallytemporary
authenticationdata.
IfthepreviouslyvisitedVLRocannotbecontactedorcannotretrievetheuser
identity,thevisitedVLRnrequeststheusertoidentifyitselfbymeansofits
permanentuseridentity.
TMSIo, LAIo /
P-TMSIo, RAIo
User identity request
SGSNo
VLRo
SGSNn
VLRn

Loc. Upd (TMSI) /
RA Upd (P-TMSI)
O
OUser identity response
IMSI,
quintets / triplets,
security context

Figure4DistributionofIMSIbetweenVLRs/SGSNs
OTheprocedureisinvokedbythenewlyvisitedVLRn/SGSNnafterthe
receiptofaLocationupdaterequest/Routingareaupdaterequestfromthe
userwhereintheuserisidentifiedbymeansofatemporaryuseridentity
TMSIo/P-TMSIoandthelocationareaidentityLAIo/routingareaidentity
RAIounderthejurisdictionofapreviouslyvisitedVLRo/SGSNothatbelongs
tothesameservingnetworkdomainasthenewlyvisitedVLRn/SGSNn.
OTheVLRn/SGSNnsendsaUseridentityrequesttotheVLRo/SGSNo,this
messagecontainsTMSIoandLAIo/P-TMSIoandRAIo.
LeliwaTechnicalBulletinUMTSSecurity

6
OTheVLRo/SGSNosearchestheuserdatainthedatabase.Iftheuseris
found,theVLRo/SGSNosendsauseridentityresponsebackthat:
• includestheIMSI
• mayincludeanumberofunusedauthenticationvectors(quintetsor
triplets),
• mayincludethecurrentsecuritycontextdata:CK,IKandKSI(UMTS)
orKcandCKSN(GSM).
IftheusercannotbeidentifiedtheVLRo/SGSNosendsaUseridentity
responseindicatingthattheuseridentitycannotberetrieved.
OIftheVLRn/SGSNnreceivesaUseridentityresponsewithanIMSI,it
createsanentryandstoresanyauthenticationvectorsandanydataonthe
currentsecuritycontext.
IftheVLRn/SGSNnreceivesaUseridentityresponseindicatingthattheuser
couldnotbeidentified,itinitiatestheuseridentificationproceduredescribed
inthenextsection.
Identificationbyapermanentidentity Identificationbyapermanentidentity Identificationbyapermanentidentity Identificationbyapermanentidentity
Themechanismisinvokedwhenevertheusercannotbeidentifiedbymeans
ofatemporaryidentity.Inparticular,itisusedwhentheuserregistersforthe
firsttimeinaservingnetwork,orwhentheservingnetworkcannotretrieve
theIMSIfromtheTMSI/P-TMSIbywhichtheuseridentifiesitselfonthe
radiopath.
IMSI
User identity request
User identity response
SGSN
VLR

Figure5Identificationbythepermanentidentity
OThemechanismisinitiatedbythevisitedVLR/SGSNthatrequeststhe
usertosenditspermanentidentity.
OTheuser'sresponsecontainstheIMSIincleartext.Thisrepresentsa
breachintheprovisionofuseridentityconfidentiality.
UMTSSecurityLeliwaTechnicalBulletin

7
Entityauthentication Entityauthentication Entityauthentication Entityauthentication
Twosecurityfeaturesrelatedtoentityauthenticationareprovided:
• userauthentication: userauthentication: userauthentication: userauthentication:thepropertythattheservingnetwork
corroboratestheuseridentityoftheuser,
• networkauthentication: networkauthentication: networkauthentication: networkauthentication:thepropertythattheusercorroboratesthathe
isconnectedtoaservingnetworkthatisauthorisedbytheuser'sHE
toprovidehimservices;thisincludestheguaranteethatthis
authorisationisrecent.
Theentityauthenticationoccursateachconnectionset-upbetweentheuser
andthenetwork.Twomechanismshavebeenincluded:anauthentication
mechanismusinganauthenticationvectordeliveredbytheuser'sHEtothe
servingnetwork,andalocalauthenticationmechanismusingtheintegritykey
establishedbetweentheuserandservingnetworkduringtheprevious
executionoftheauthenticationandkeyestablishmentprocedure.
S
e
r
v
i
n
g

N
e
t
w
o
r
k
user authentication
network authentication

Figure6Entityauthentication
Authenticationandkeyagreement Authenticationandkeyagreement Authenticationandkeyagreement Authenticationandkeyagreement
Themechanismdescribedhereachievesmutualauthenticationbytheuser
andthenetworkshowingknowledgeofasecretkeyKwhichisshared
betweenandavailableonlytotheUSIMandtheAuCintheuser'sHE.In
additiontheUSIMandtheHEkeeptrackofcountersSQN
MS
andSQN
HE

respectivelytosupportnetworkauthentication.ThesequencenumberSQN
HE
isanindividualcounterforeachuserandthesequencenumberSQN
MS

denotesthehighestsequencenumbertheUSIMhasaccepted.
Themethodwaschoseninsuchawayastoachievemaximumcompatibility
withtheGSMsecurityarchitectureandfacilitatemigrationfromGSMto
UMTS.Themethodiscomposedofachallenge/responseprotocolidentical
totheGSMsubscriberauthenticationandkeyestablishmentprotocol
LeliwaTechnicalBulletinUMTSSecurity

8
combinedwithasequencenumber-basedone-passprotocolfornetwork
authentication.
AnoverviewofthemechanismisshowninFig.7.
Authentication data request (IMSI)
SGSN
VLR HLR
Authentication data response (AV(1..n))
Generate authentication
vectors AV(1..n)
Store authentication vectors
Select authentication vector AV(i)
User authentication request (RAND(i), AUTN(i))
Verify AUTN(i),
compute RES(i)
User authentication response (RES(i))
Compare RES(i) and XRES(i)
Select CK(i) and IK(i) Compute CK(i) and IK(i)
D
i
s
t
r
i
b
u
t
i
o
n

o
f

a
u
t
h
e
n
t
i
c
a
t
i
o
n

v
e
c
t
o
r
s

f
r
o
m

H
E

t
o

S
N
A
u
t
h
e
n
t
i
c
a
t
i
o
n

a
n
d

k
e
y

e
s
t
a
b
l
i
s
h
m
e
n
t

Figure7Authenticationandkeyagreement
TheAuthenticationdatarequestincludestheIMSIandtherequestingnode
type(PSorCS).UponreceiptofarequestfromtheVLR/SGSN,theHE/AuC
sendsanorderedarrayofnauthenticationvectorsAV(1..n),(theequivalent
ofaGSM‘triplet’)totheVLR/SGSN.Theauthenticationvectorsareordered
basedonsequencenumber.Eachauthenticationvectorconsistsofthe
followingcomponents:arandomnumberRAND,anexpectedresponse
XRES,acipherkeyCK,anintegritykeyIKandanauthenticationtoken
AUTN.Eachauthenticationvectorisgoodforoneauthenticationandkey
agreementbetweentheVLR/SGSNandtheUSIM.
WhentheVLR/SGSNinitiatesanauthenticationandkeyagreement,it
selectsthenextauthenticationvectorfromtheorderedarrayandsendsthe
parametersRANDandAUTNtotheuser.Authenticationvectorsina
particularnodeareusedonanFIFObasis.TheUSIMcheckswhetherAUTN
canbeacceptedand,ifso,producesaresponseRESwhichissentbackto
theVLR/SGSN.TheUSIMalsocomputesCKandIK.TheVLR/SGSN
comparesthereceivedRESwithXRES.IftheymatchtheVLR/SGSN
considerstheauthenticationandkeyagreementexchangetobesuccessfully
completed.TheestablishedkeysCKandIKwillthenbetransferredbythe
USIMandtheVLR/SGSNtotheentitieswhichperformcipheringandintegrity
functions.
VLR/SGSNscanoffersecureserviceevenwhenHE/AuClinksare
unavailablebyallowingthemtousepreviouslyderivedcipherandintegrity
keysforausersothatasecureconnectioncanstillbesetupwithoutthe
needforanauthenticationandkeyagreement.Authenticationisinthatcase
UMTSSecurityLeliwaTechnicalBulletin

9
basedonasharedintegritykey,bymeansofdataintegrityprotectionof
signallingmessages.
Generationofauthenticationvectors Generationofauthenticationvectors Generationofauthenticationvectors Generationofauthenticationvectors
Fig.8showsthegenerationofanauthenticationvectorAVbytheHE/AuC.
Generate SQN
Generate RAND
f1 f2 f3 f4 f5
MAC XRES CK IK AK
SQN RAND AMF K
AUTN := SQN ⊕ AK || AMF || MAC
AV := RAND || XRES || CK || IK || AUTN

Figure8Generationofauthenticationvectors
TheHE/AuCstartswithgeneratingafreshsequencenumberSQNandan
unpredictablechallengeRAND.ForeachusertheHE/AuCkeepstrackofa
counterSQN
HE.

Subsequentlythefollowingvaluesarecomputed:
• aMessageAuthenticationCodeMAC MessageAuthenticationCodeMAC MessageAuthenticationCodeMAC MessageAuthenticationCodeMAC=f1
K
(SQN||RAND||AMF)
wheref1isamessageauthenticationfunction;
• aneXpectedRESponseXRE eXpectedRESponseXRE eXpectedRESponseXRE eXpectedRESponseXRES SS S=f2
K
(RAND)wheref2isamessage
authenticationfunction;
• aCipherKeyCK CipherKeyCK CipherKeyCK CipherKeyCK=f3
K
(RAND)wheref3isakeygeneratingfunction;
• anIntegrityKeyIK IntegrityKeyIK IntegrityKeyIK IntegrityKeyIK=f4
K
(RAND)wheref4isakeygenerating
function;
• anAnonymityKeyAK AnonymityKeyAK AnonymityKeyAK AnonymityKeyAK=f5
K
(RAND)wheref5isakeygenerating
functionorf5≡0.
FinallytheauthenticationtokenAUTN=SQN⊕AK||AMF||MACis
constructed.
AKisananonymitykeyusedtoconcealthesequencenumberasthelatter
mayexposetheidentityandlocationoftheuser.Theconcealmentofthe
sequencenumberistoprotectagainstpassiveattacksonly.
LeliwaTechnicalBulletinUMTSSecurity

10
AnauthenticationandkeymanagementfieldAMFisincludedinthe
authenticationtokenofeachauthenticationvector.ExampleusesofAMF
includes:
• supportmultipleauthenticationalgorithmsandkeys(Thismechanism
isusefulfordisasterrecoverypurposes.AMFmaybeusedtoindicate
thealgorithmandkeyusedtogenerateaparticularauthentication
vector.)
• changingsequencenumberverificationparameters(Thismechanism
isusedtochangedynamicallythelimitonthedifferencebetweenthe
highestSEQacceptedsofarandareceivedsequencenumberSEQ.)
• settingthresholdvaluestorestrictthelifetimeofcipherandintegrity
keys(TheUSIMcontainsamechanismtolimittheamountofdata
thatisprotectedbyanaccesslinkkeyset.TheAMFfieldmaybe
usedbytheoperatortosetoradjustthislimitintheUSIM).
Fig.9showsthesummaryofallauthenticationparameters.
var. 4-16 octets authentication RESponse RES
128 bits Integrity Key IK
128 bits Cipher Key CK
64 bits Message Authentication Code MAC-S
64 bits Message Authentication Code MAC
16 bits Authentication Management Field AMF
48 bits Anonymity Key AK
48 bits SeQuence Numbers SQN
128 bits RANDom challenge RAND
128 bits authentication Key K
Length Parameter name

Figure9Authenticationparameters
UMTSSecurityLeliwaTechnicalBulletin

11
Authenticat Authenticat Authenticat Authenticationandkeyagreement ionandkeyagreement ionandkeyagreement ionandkeyagreement
Thepurposeofthisprocedureistoauthenticatetheuserandestablishanew
pairofcipherandintegritykeysbetweentheVLR/SGSNandtheUSIM.
Duringtheauthentication,theUSIMverifiesthefreshnessofthe
authenticationvectorthatisused.
User authentication request (RAND || AUTN)
SGSN
VLR
User authentication response (RES)
User authentication reject (CAUSE)

Figure10Authenticationandkeyestablishment
TheVLR/SGSNinvokestheprocedurebyselectingthenextunused
authenticationvectorintheVLR/SGSNdatabaseandsendstotheUSIMthe
randomchallengeRANDandanauthenticationtokenfornetwork
authenticationAUTN.
UponreceipttheuserproceedsasshowninFig.11.
f5
AK
RAND AUTN
SQN⊕AK AMF MAC
SQN
f1 f2 f3 f4
XMAC RES CK IK
K
Verify MAC = XMAC Verify that SQN is in the correct range

Figure11UserauthenticationfunctionintheUSIM
UponreceiptofRANDandAUTNtheUSIMfirstcomputestheanonymitykey
AK=f5
K
(RAND)andretrievesthesequencenumberSQN=(SQN⊕AK)⊕
AK.
LeliwaTechnicalBulletinUMTSSecurity

12
NexttheUSIMcomputesXMAC=f1
K
(SQN||RAND||AMF)andcompares
thiswithMACwhichisincludedinAUTN.Iftheyaredifferent,theusersends
UserauthenticationrejectbacktotheVLR/SGSNwithanindicationofthe
causeandtheuserabandonstheprocedure.Inthiscase,VLR/SGSN
initiatesanAuthenticationfailurereportproceduretowardstheHLR.
VLR/SGSNmayalsodecidetoinitiateanewidentificationandauthentication
proceduretowardstheuser.
NexttheUSIMverifiesthatthereceivedsequencenumberSQNisinthe
correctrange.Ifcorrect,theUSIMcomputesRES=f2
K
(RAND)andincludes
thisparameterinaUserauthenticationresponsebacktotheVLR/SGSN.
FinallytheUSIMcomputesthecipherkeyCK=f3
K
(RAND)andtheintegrity
keyIK=f4
K
(RAND).
IftheUSIMalsosupportsconversionfunctionc3,itderivestheGSMcipher
keyKcfromtheUMTScipher/integritykeysCKandIK.
UponreceiptofUserauthenticationresponsetheVLR/SGSNcomparesRES
withtheeXpectedRESponseXRESfromtheselectedauthenticationvector.
IfXRESequalsRESthentheauthenticationoftheuserhaspassed.The
VLR/SGSNalsoselectstheappropriatecipherkeyCKandintegritykeyIK
fromtheselectedauthenticationvector.IfXRESandRESaredifferent,
VLR/SGSNinitiatesanAuthenticationfailurereportproceduretowardsthe
HLRandmayalsodecidetoinitiateanewidentificationandauthentication
proceduretowardstheuser.
Sequence Sequence Sequence Sequencenumbers numbers numbers numbers
TheverificationoftheSQNbytheUSIMwillcausetheMStorejectan
attemptbytheVLR/SGSNtore-useaquintettoestablishaparticularUMTS
securitycontextmorethanonce.IngeneralthereforetheVLR/SGSNcanuse
aquintetonlyonce.
Themechanismsforverifyingthefreshnessofsequencenumbersinthe
USIMtosomeextentallowstheout-of-orderuseofsequencenumbers.This
istoensurethattheauthenticationfailurerateduetosynchronisationfailures
issufficientlylow.ThisrequiresthecapabilityoftheUSIMtostoreinformation
onpastsuccessfulauthenticationevents(e.g.sequencenumbers).The
mechanismensuresthatasequencenumbercanstillbeacceptedifitis
amongthelastx=32sequencenumbersgenerated.Thesameminimum
numberxneedstobeusedacrossthesystemstoguaranteethatthe
synchronisationfailurerateissufficientlylowundervarioususagescenarios,
inparticularsimultaneousregistrationintheCS-andthePS-servicedomains
andusermovementbetweenVLRs/SGSNswhichdonotexchange
authenticationinformation.
IftheUSIMconsidersthesequencenumbertobenotinthecorrectrange,it
sendsSynchronisationfailurebacktotheVLR/SGSNandabandonsthe
procedure,seeFig.12.
UMTSSecurityLeliwaTechnicalBulletin

13
User authentication request (RAND || AUTN)
SGSN
VLR
User authentication reject
(AUTS, CAUSE = synchronisation failure)

Figure12Synchronisationfailure
ThesynchronisationfailuremessagecontainstheparameterAUTS.Itis
AUTS=Conc(SQN
MS
)||MAC-S.Conc(SQN
MS
)=SQN
MS
⊕ f5*
K
(RAND)is
theconcealedvalueofthecounterSQN
MS
intheMS,andMAC-S=
f1*
K
(SQN
MS
||RAND||AMF)whereRANDistherandomvaluereceivedin
thecurrentuserauthenticationrequestandAMFisadummyvalueofall
zeros.f1*isamessageauthenticationcode(MAC)functionandf5*isthekey
generatingfunctionusedtocomputeAKinre-synchronisationprocedures,
bothwiththepropertythatnovaluableinformationcanbeinferredfromthe
functionvaluesoff1*andf5*aboutthoseoff1,...,f5,f5*andviceversa.
TheconstructionoftheparameterAUTSinshownintheFig.13.
f5*
AK
RAND
SQNMS⊕AK
AMF
MAC-S
SQNMS
f1*
K
AUTS = SQNMS ⊕ AK || MAC-S

Figure13ConstructionoftheparameterAUTS
R RR Re ee e- -- -synchronisationprocedure synchronisationprocedure synchronisationprocedure synchronisationprocedure
AVLR/SGSNmaysendtwotypesofauthenticationdatarequeststothe
HE/AuC,the(regular)one,describedearlierinthischapterandoneusedin
caseofsynchronisationfailures,describedinthissection.
Uponreceivingasynchronisationfailuremessagefromtheuser,the
VLR/SGSNsendsanauthenticationdatarequestwitha‘synchronisation
failureindication’totheHE/AuC,togetherwiththeparameters:
• RANDsenttotheMSintheprecedinguserauthenticationrequest,
and
• AUTSreceivedbytheVLR/SGSNintheresponsetothatrequest,
LeliwaTechnicalBulletinUMTSSecurity

14
WhentheHE/AuCreceivesanauthenticationdatarequestwitha
‘synchronisationfailureindication"itretrievesSQN
MS
fromConc(SQN
MS
)by
computingConc(SQN
MS
)⊕f5
*
K
(RAND)andchecksifSQN
HE
isinthecorrect
range,i.e.ifthenextsequencenumbergeneratedSQN
HE
usingwouldbe
acceptedbytheUSIM.
IfSQN
HE
isinthecorrectrangethentheHE/AuCsendsanauthentication
dataresponsewithanewbatchofauthenticationvectorstotheVLR/SGSN.
OtherwiseitverifiesAUTSandiftheverificationissuccessfultheHE/AuC
resetsthevalueofthecounterSQN
HE
toSQN
MS
.
WhenevertheVLR/SGSNreceivesanewbatchofauthenticationvectorsit
deletestheoldonesforthatuserintheVLR/SGSNandtheusermaynowbe
authenticatedbasedonanewauthenticationvector.
RAND, AUTN
SGSN
VLR
AUTS
HLR/AuC
RAND, AUTS
{Qi}

Figure14Re-synchronisationmechanism
Reportingauthenticationfailures Reportingauthenticationfailures Reportingauthenticationfailures Reportingauthenticationfailures
Thepurposeofthisprocedureistoprovideamechanismforreporting
authenticationfailuresfromtheservingenvironmentbacktothehome
environment,seeFig.15.
SGSN
VLR
HLR
Authentication failure report
(IMSI, failure cause, access type, authentication
re-attempt, VLR/SGSN address and RAND)

Figure15ReportingauthenticationfailurefromVLR/SGSNtoHLR
TheprocedureisinvokedbytheservingnetworkVLR/SGSNwhenthe
authenticationprocedurefails.TheAuthenticationfailurereportcontains
amongotherparameters:subscriberidentity,failurecausecode(wrong
networksignature/wronguserresponse),VLR/SGSNaddressandRAND.
TheHEmaycancelthelocationoftheuserafterreceivinganauthentication
failurereportandstoresthereceiveddatasothatfurtherprocessingtodetect
possiblefraudsituationscouldbeperformed.
UMTSSecurityLeliwaTechnicalBulletin

15
Confidentiality Confidentiality Confidentiality Confidentiality
Foursecurityfeaturesrelatedtoconfidentialityareprovided:
• cipheralgorithmagreement cipheralgorithmagreement cipheralgorithmagreement cipheralgorithmagreement(MSandtheSNsecurelynegotiatethe
algorithmthattheyusesubsequently),
• cipherkeyagreement cipherkeyagreement cipherkeyagreement cipherkeyagreement(MSandtheSNagreeonacipherkeythatthey
usesubsequently),
• confidentialityofuserdata confidentialityofuserdata confidentialityofuserdata confidentialityofuserdata(userdatacannotbeoverheardonthe
radioaccessinterface),
• confidentialityofsignallin confidentialityofsignallin confidentialityofsignallin confidentialityofsignallingdata gdata gdata gdata(signallingdatacannotbeoverheard
ontheradioaccessinterface).
Cipherkeyandintegritykeysetting Cipherkeyandintegritykeysetting Cipherkeyandintegritykeysetting Cipherkeyandintegritykeysetting
Authenticationandkeysettingaretriggeredbytheauthenticationprocedure
describedearlierinthischapter.TheCKandIKarestoredintheVLR/SGSN
andtransferredtotheRNCwhenneeded.TheCKandIKfortheCSdomain
andseparatelyforPSdomainarestoredontheUSIMandupdatedatthe
nextauthenticationfromeachdomain.
Authentication
SGSN
VLR RNC
CK, IK CK, IK

Figure16Cipherkeyandintegritykeysetting
Cipheringandin Cipheringandin Cipheringandin Cipheringandintegritymodenegotiation tegritymodenegotiation tegritymodenegotiation tegritymodenegotiation
WhenanMSwishestoestablishaconnectionwiththenetwork,theMS
indicatestothenetworkintheMS/USIMClassmarkwhichcipherandintegrity
algorithmstheMSsupports.Thisinformationitselfisintegrityprotected.Asit
isthecasethattheRNCdoesnothavetheintegritykeyIKwhenreceiving
theMS/USIMClassmarkthisinformationmustbestoredintheRNC.The
dataintegrityoftheclassmarkisperformed,duringthesecuritymodeset-up
procedurebyuseofthemostrecentlygeneratedIK.
LeliwaTechnicalBulletinUMTSSecurity

16
Cipherkeyandintegritykeyidentification Cipherkeyandintegritykeyidentification Cipherkeyandintegritykeyidentification Cipherkeyandintegritykeyidentification
Thekeysetidentifier(KSI)isanumberwhichisassociatedwiththecipher
andintegritykeysderivedduringauthentication.Thekeysetidentifieris
allocatedbythenetworkandsentwiththeauthenticationrequestmessageto
theMSwhereitisstoredtogetherwiththecalculatedcipherkeyCKand
integritykeyIK.KSIinUMTScorrespondstoCKSNinGSM.TheUSIM
storesoneKSI/CKSNforthePSdomainkeysetandoneKSI/CKSNforthe
CSdomainkeyset.
Thepurposeofthekeysetidentifieristomakeitpossibleforthenetworkto
identifythecipherkeyCKandintegritykeyIKwhicharestoredintheMS
withoutinvokingtheauthenticationprocedure.Thisisusedtoallowre-useof
thecipherkeyCKandintegritykeyIKduringsubsequentconnectionset-ups.
KSIandCKSNhavethesameformat.Thekeysetidentifieristhreebits
(sevenvaluesareusedtoidentifythekeysetandavalueof‘111’isusedby
theMStoindicatethatavalidkeyisnotavailableforuse).
Authentication
SGSN
VLR
CK, IK,
KSI
KSI
Ciphering, integrity protection
KSI
after some time
CK, IK,
KSI

Figure17Cipherkeyandintegritykeyidentification
Cipherkeyandintegritykeylifetime Cipherkeyandintegritykeylifetime Cipherkeyandintegritykeylifetime Cipherkeyandintegritykeylifetime
Authenticationandkeyagreement,whichgeneratescipher/integritykeys,is
notmandatoryatcallset-up,andthereisthereforethepossibilityofunlimited
andmaliciousre-useofcompromisedkeys.TheUSIMthereforecontainsa
mechanismtolimittheamountofdatathatisprotectedbyanaccesslinkkey
set.
ThelifetimeofcipherandintegritykeysislimitedbyTHRESHOLDvalues
thatcanbesetoradjustbytheoperatorandsendtotheUSIMinsideAMF
fieldoftheauthenticationvector.
Thecipheringandintegrityprotectionalgorithmsaredrivenbycounters
(COUNT-CandCOUNT-I)thatatconnectionestablishmentneedtobe
initialised.ForthatpurposetheMEandtheUSIMhavetheabilitytostorea
UMTSSecurityLeliwaTechnicalBulletin

17
STARTvalue.TheMEandtheUSIMstoreaSTART
CS
valuefortheCS
cipher/integritykeysandaSTART
PS
valueforthePScipher/integritykeys.
ThelengthofSTARTis20bits.
Atradioconnectionestablishmentforaparticularservingnetworkdomain
(CSorPS)theMEsendstheSTART
CS
andtheSTART
PS
valuetotheRNCin
theRRCconnectionsetupcompletemessage.TheMEmarkstheSTART
valuesintheUSIMasinvalidbysettingSTART
CS
andSTART
PS
to
THRESHOLD.
ThecipheringsequencenumberCOUNT-Candintegritysequencenumber
COUNT-Iareboth32bitslong.TheMEandtheRNCinitialisethe20most
significantbitsoftheCOUNT-CandOUNT-ItothecurrentvalueofSTART
andtheremainingbitstozeroatthestartofciphering.ThantheCOUNT-C
andCOUNT-IisincrementedateachRLCcycle.
DuringauthenticationandkeyagreementtheSTARTvalueassociatedwith
thenewkeysetofthecorrespondingservicedomainissetto0intheUSIM
andintheME.
0 5 6 9 2
0 0 0 0 0
Authentication
SGSN
VLR
Ciphering, integrity protection
after some time
0 5 6 9 2
0 8 4 7 1
Ciphering, integrity protection
after some time
Authentication
0 0 0 0 0
Ciphering, integrity protection
START=5692
START=THRESHOLD
0 8 4 7 1
THRESHOLD=8000

Figure18Cipherkeyandintegritykeylifetime
Securitymodeset Securitymodeset Securitymodeset Securitymodeset- -- -upprocedure upprocedure upprocedure upprocedure
Thissectiondescribesonecommonprocedureforbothcipheringand
integrityprotectionset-up.
Themessagesequenceflowbelowdescribestheinformationtransferat
initialconnectionestablishment,possibleauthenticationandstartofintegrity
protectionandpossibleciphering.
LeliwaTechnicalBulletinUMTSSecurity

18
SGSN
VLR
SRNC
ORRC connection establishment
(START values)
O‘Initial L3 message’ (user identity, KSI)
OAuthentication and key generation
OSecurity mode cmd. (CK, IK)
OSec. mode cmd. (CN dom., FRESH, MAC-I)
OVerification
OSecurity mode complete (MAC-I)
OVerification
OSecurity mode complete (MAC-I)
Ciphering / deciphering

Figure19Localauthenticationandconnectionset-up
ORRCconnectionestablishmentincludesthetransferfromMStoRNCof
thecipheringcapabilities(UEAs)andtheintegritycapabilities(UIAs)ofthe
MS.OptionallytheGSMClassmarks2and3andtheSTARTvaluesforthe
CS/PSservicedomainareincluded.TheSTARTvaluesandtheUEsecurity
capabilityinformationarestoredintheSRNC.
OTheMSsendstheInitialL3message(Locationupdaterequest,CM
servicerequest,Routingareaupdaterequest,Attachrequest,Paging
responseetc.)totheVLR/SGSN.Thismessagecontainstheuseridentity
andtheKSI.
OUseridentityrequest,authenticationoftheuserandgenerationofnew
securitykeys(IKandCK)maybeperformed.AnewKSIwillthenalsobe
allocated.
OTheVLR/SGSNinitiatesintegrityandcipheringbysendingtheRANAP
messageSecurityModeCommandtoSRNCthatcontainstheIKandCKto
beused.Ifanewauthenticationandsecuritykeygenerationhasbeen
performed,thisisindicatedinthemessagesenttotheSRNC.Theindication
ofnewgeneratedkeysimpliesthattheSTARTvalueistoberesetatstart
useofthenewkeys.Otherwise,itistheSTARTvaluealreadyavailableinthe
SRNCthatisused.
OTheSRNCgeneratestheRRCmessageSecuritymodecommand.The
messageincludestherandomvalueFRESHtobeusedforintegrity
protection.BecauseofthattheMScanhavetwocipheringandintegritykey
sets,thenetworkmustindicatewhichkeysettouse.Thisisobtainedby
includingaCNtypeindicatorinformationintheSecuritymodecommand
message.BeforesendingthismessagetotheMS,theSRNCgeneratesthe
MAC-I(MessageAuthenticationCodeforIntegrity)andattachesthis
informationtothemessage.
OTheMScomputesXMAC-IonthemessagereceivedbyusingtheUIA,the
storedCOUNT-IandthereceivedFRESHparameter.TheMSverifiesthe
UMTSSecurityLeliwaTechnicalBulletin

19
integrityofthemessagebycomparingthereceivedMAC-Iwiththegenerated
XMAC-I.
OTheMScompilestheRRCmessageSecuritymodecompleteand
generatestheMAC-Iforthismessage.Ifverificationisnotsuccessful,the
procedureendsintheMS.
OAtreceptionoftheresponsemessage,theSRNCcomputestheXMAC-I
onthemessage.TheSRNCverifiesthedataintegrityofthemessageby
comparingthereceivedMAC-IwiththegeneratedXMAC-I.
OThetransferoftheRANAPmessageSecuritymodecompletefromSRNC
totheVLR/SGSNendstheprocedure.
TheSecuritymodecommandtoMSstartsthedownlinkintegrityprotection,
i.e.thisandallfollowingdownlinkmessagessenttotheMSareintegrity
protectedusingthenewintegrityconfiguration.TheSecuritymodecomplete
fromMSstartstheuplinkintegrityprotection,i.e.thisandallfollowing
messagessentfromtheMSareintegrityprotectedusingthenewintegrity
configuration.Whencipheringshallbestarted,theCipheringActivationtime
informationthatisexchangedbetweenSRNCandMSduringtheSecurity
modeset-upproceduresetstheRLCSequenceNumber/ConnectionFrame
NumberwhentostartcipheringinDownlinkrespectiveUplinkusingthenew
cipheringconfiguration.
Cipheringmethod Cipheringmethod Cipheringmethod Cipheringmethod
Fig.20illustratestheuseofthecipheringalgorithmf8toencryptplaintextby
applyingakeystreamusingabitperbitbinaryadditionoftheplaintextand
thekeystream.Theplaintextmayberecoveredbygeneratingthesame
keystreamusingthesameinputparametersandapplyingabitperbitbinary
additionwiththeciphertext.
f8 CK
BEARER
COUNT-C DIRECTION
LENGTH
KEYSTREAM
BLOCK

PLAINTEXT
BLOCK
CIPHERTEXT
BLOCK
f8 CK
BEARER
COUNT-C DIRECTION
LENGTH
KEYSTREAM
BLOCK

PLAINTEXT
BLOCK
Sender Receiver

Figure20Cipheringofuserandsignallingdata
LeliwaTechnicalBulletinUMTSSecurity

20
TheinputparameterstothealgorithmarethecipherkeyCK,atime
dependentinputCOUNT-C,thebeareridentityBEARER,thedirectionof
transmissionDIRECTIONandthelengthofthekeystreamrequiredLENGTH.
Basedontheseinputparametersthealgorithmgeneratestheoutput
keystreamblockKEYSTREAMwhichisusedtoencrypttheinputplaintext
blockPLAINTEXTtoproducetheoutputciphertextblockCIPHERTEXT.
ThereisoneBEARERparameterperradiobearerassociatedwiththesame
userandmultiplexedonasingle10msphysicallayerframe.Theradiobearer
identifierisinputtoavoidthatfordifferentkeystreamanidenticalsetofinput
parametervaluesisused.
TheDIRECTIONidentifierisinputtoavoidthatforthekeystreamsfortheup-
linkandforthedown-linkwouldusetheidenticalsetofinputparameter
values.
TheLENGTHindicatordeterminesthelengthoftherequiredkeystream
block.
ThereisoneCKforCSconnections(CK
CS
),establishedbetweentheCS
servicedomainandtheuserandoneCKforPSconnections(CK
PS
)
establishedbetweenthePSservicedomainandtheuser.Theradiobearers
forCSuserdataarecipheredwithCK
CS
.TheradiobearersforPSuserdata
arecipheredwithCK
PS
.Thesignallingradiobearersareusedfortransferof
signallingdataforservicesdeliveredbybothCSandPSservicedomains.
ThesesignallingradiobearersarecipheredbytheCKoftheservicedomain
forwhichthemostrecentsecuritymodenegotiationtookplace.
Dataintegrity Dataintegrity Dataintegrity Dataintegrity
Threesecurityfeaturesrelatedtodataintegrityareprovided:
• integrityalgorithmagreement integrityalgorithmagreement integrityalgorithmagreement integrityalgorithmagreement(theMSandtheSNsecurelynegotiate
theintegrityalgorithmthattheyusesubsequently),
• integritykeyagreement integritykeyagreement integritykeyagreement integritykeyagreement(theMSandtheSNagreeonanintegritykey
thattheyusesubsequently),
• dataintegrityandoriginauthenticationofsignallingdata dataintegrityandoriginauthenticationofsignallingdata dataintegrityandoriginauthenticationofsignallingdata dataintegrityandoriginauthenticationofsignallingdata(theproperty
thatthereceivingentity(MSorSN)isabletoverifythatsignalling
datahasnotbeenmodifiedinanunauthorisedwaysinceitwassent
bythesendingentity(SNorMS)andthatthedataoriginofthe
signallingdatareceivedisindeedtheoneclaimed).
Integritykeyagreementandintegrityalgorithmagreementisrealisedby
meansofamechanismthataredescribedearlierinthischapter.
UMTSSecurityLeliwaTechnicalBulletin

21
D DD Dataintegrityprotectionmethod ataintegrityprotectionmethod ataintegrityprotectionmethod ataintegrityprotectionmethod
Fig.21illustratestheuseoftheintegrityalgorithmf9toauthenticatethedata
integrityofasignallingmessage.
f9 IK
MESSAGE
COUNT-I DIRECTION
FRESH
MAC-I
Sender Receiver
f9 IK
MESSAGE
COUNT-I DIRECTION
FRESH
XMAC-I

Figure21DerivationofMAC-I(orXMAC-I)onasignallingmessage
TheinputparameterstothealgorithmaretheIntegrityKey(IK),theintegrity
sequencenumber(COUNT-I),arandomvaluegeneratedbythenetworkside
(FRESH),thedirectionbitDIRECTIONandthesignallingdataMESSAGE.
Basedontheseinputparameterstheusercomputesmessageauthentication
codefordataintegrityMAC-Iusingtheintegrityalgorithmf9.TheMAC-Iis
thenappendedtothemessagewhensentovertheradioaccesslink.The
receivercomputesXMAC-Ionthemessagereceivedinthesamewayasthe
sendercomputedMAC-Ionthemessagesentandverifiesthedataintegrity
ofthemessagebycomparingittothereceivedMAC-I.
Thenetwork-sidenonceFRESH FRESH FRESH FRESHis32bitslong.TheinputparameterFRESH
protectsthenetworkagainstreplayofsignallingmessagesbytheuser.At
connectionset-uptheRNCgeneratesarandomvalueFRESHandsendsitto
theuserinthe(RRC)Securitymodecommand.ThevalueFRESHis
subsequentlyusedbyboththenetworkandtheuserthroughouttheduration
ofasingleconnection.Thismechanismassuresthenetworkthattheuseris
notreplayinganyoldMAC-Is.
TheremaybeoneIK IK IK IKforCSconnections(IK
CS
),establishedbetweentheCS
servicedomainandtheuserandoneIKforPSconnections(IK
PS
)
establishedbetweenthePSservicedomainandtheuser.Thedataintegrity
ofradiobearersforuserdataisnotprotected.Thesignallingradiobearers
areusedfortransferofsignallingdataforservicesdeliveredbybothCSand
PSservicedomains.Thesesignallingradiobearersaredataintegrity
protectedbytheIKoftheservicedomainforwhichthemostrecentsecurity
modenegotiationtookplace.
Therestoftheinputparametershaveexactlythesamemeaningasfor
algorithmforcipheringdescribedintheprevioussection.
LeliwaTechnicalBulletinUMTSSecurity

22
Unsuccessfulintegritycheck Unsuccessfulintegritycheck Unsuccessfulintegritycheck Unsuccessfulintegritycheck
ThesupervisionoffailedintegritychecksisperformedbothintheMSandthe
SRNC.Incaseoffailedintegritycheck(i.e.faultyormissingMAC)is
detectedafterthattheintegrityprotectionisstartedtheconcernedmessage
isdiscarded.
UMTS UMTS UMTS UMTS– –– –GSMinteroperation GSMinteroperation GSMinteroperation GSMinteroperation
UMTS UMTS UMTS UMTSsubscriberconnectedtoGSMBSS subscriberconnectedtoGSMBSS subscriberconnectedtoGSMBSS subscriberconnectedtoGSMBSS
UMTSAKAisappliedwhentheuserisattachedtoaGSMBSS,incasethe
userhasaMEcapableofUMTSAKAandalsotheVLR/SGSNisR99+.In
thiscase,theGSMcipherkeyKcisderivedfromtheUMTScipher/integrity
keysCKandIK,bytheVLR/SGSNonthenetworksideandbytheUSIMon
theuserside.
SGSN
VLR
HLR/AuC
{RAND,XRES, CK, IK, AUTN}
RAND, AUTN
UMTS AKA
USIM
RES
CK, IK →Kc CK, IK →Kc
BSC
Kc
GSM EA A5/x

Figure22UserattachedtoGSMBSSwithUMTSAKAcapableME
(VLR/SGSNR99+)
GSMAKAisappliedwhentheuserisattachedtoaGSMBSS,incasethe
userhasaMEnotcapableofUMTSAKA.Inthiscase,theGSMuser
responseSRESandtheGSMcipherkeyKcarederivedfromtheUMTSuser
responseRESandtheUMTScipher/integritykeysCKandIK.AR98-
VLR/SGSNusesthestoredKcandRESandaR99+VLR/SGSNderivesthe
SRESfromRESandKcfromCK,IK.
UMTSSecurityLeliwaTechnicalBulletin

23
SGSN
VLR
HLR/AuC
{RAND,XRES, CK, IK, AUTN}
RAND
GSM AKA
USIM
SRES
BSC
Kc
GSM EA A5/x
CK, IK →Kc,
RES →SRES
CK, IK →Kc,
RES →SRES

Figure23UserattachedtoGSMBSSwithUMTSAKAnon-capableME
(VLR/SGSNR99+)
GSMAKAisappliedwhentheuserisattachedtoaGSMBSS,incasethe
VLR/SGSNisR98-.Inthiscase,theUSIMderivestheGSMuserresponse
SRESandtheGSMcipherkeyKcfromtheUMTSuserresponseRESand
theUMTScipher/integritykeysCK,IK.
SGSN
VLR
HLR/AuC
{RAND,SRES, Kc}
RAND
GSM AKA
USIM
SRES
BSC
Kc
GSM EA A5/x
CK, IK →Kc,
RES →SRES
CK, IK →Kc,
RES →SRES

Figure24UserattachedtoGSMBSS(VLR/SGSNR99-)
Fig.25showsthedifferentscenariosthatcanoccurwithUMTSsubscribers
inamixednetworkarchitecture.
LeliwaTechnicalBulletinUMTSSecurity

24
UMTS AKA
non-capable ME
GSM BSS
VLR/SGSN
Release 99+
HLR/AuC
CK, IK →Kc
RES →SRES
VLR/SGSN Release 99+
CK, IK →Kc
RES →SRES CK, IK →Kc
Release 98-
UTRAN
UMTS AKA capable ME ME
USIM
CK, IK →Kc CK, IK →Kc CK, IK →Kc
RES →SRES
CK, IK →Kc
RES →SRES
Quintets Triplets
CK, IK [Kc] [Kc] [Kc]
RAND, AUTN, RES RAND, AUTN, RES RAND, [AUTN], SRES RAND, SRES
CK, IK, Kc CK, IK, Kc Kc Kc
UMTS security GSM security

Figure25AuthenticationandkeyagreementofUMTSsubscribers
IncaseofaGSMBSS,cipheringisappliedintheGSMBSSforservices
deliveredviatheMSC/VLR,andbytheSGSNforservicesdeliveredviathe
SGSN.InthelattercasetheGSMcipherkeyKcisnotsenttotheGSMBSS.
IncaseofaUTRAN,cipheringandintegrityarealwaysappliedintheRNC,
andtheUMTScipher/integritykeysCKanIKarealwayssenttotheRNC.
c1: RAND[GSM] = RAND
c2: SRES[GSM] = XRES*1 ⊕ XRES*2 ⊕ XRES*3 ⊕ XRES*4
c3: Kc[GSM] = CK1 ⊕ CK2 ⊕ IK1 ⊕ IK2
XRES* is 16 octets long and XRES* = XRES if XRES is 16 octets long and XRES*
= XRES || 0...0 if XRES is shorter than 16 octets,
XRES*i are all 4 octets long and XRES* = XRES*1 || XRES*2 || XRES*3 || XRES*4,
CKi and IKi are both 64 bits long and CK = CK1 || CK2 and IK = IK1 || IK2.

Figure26Conversionfunctions
GSMsubscribersconnectedtoUTRAN GSMsubscribersconnectedtoUTRAN GSMsubscribersconnectedtoUTRAN GSMsubscribersconnectedtoUTRAN
ForGSMsubscribers,GSMAKAisalwaysused.WheninanUTRAN,the
UMTSCKandIKarederivedfromtheGSMcipherkeyKcbytheMEandthe
VLR/SGSN,bothR99+entities.
Fig.28showsthedifferentscenariosthatcanoccurwithGSMsubscribers
usingeitherR98-orR99+MEinamixednetworkarchitecture.
UMTSSecurityLeliwaTechnicalBulletin

25
R98- UE
GSM BSS
VLR/SGSN
Release 98- or Release 99+
HLR/AuC
VLR/SGSN Release 99+
Kc →CK, IK
Release 98-
UTRAN
R99+ UE R99+ or R98- UE
SIM
Triplets Triplets
CK, IK [Kc] [Kc] [Kc]
RAND, SRES RAND, SRES RAND, SRES RAND, SRES
Kc Kc Kc Kc
GSM security

Fig27AuthenticationandkeyagreementforGSMsubscribers
WhentheuserisattachedtoaUTRAN,theR99+VLR/SGSNderivesthe
UMTScipher/integritykeysfromtheGSMcipherkeyusingthefollowing
conversionfunctions:
c4: CK[UMTS] = Kc || Kc
c5: IK[UMTS] = Kc1 ⊕ Kc2 || Kc || Kc1 ⊕ Kc2
Kci are both 32 bits long and Kc = Kc1 || Kc2

Figure28Conversionfunctions
CShandover(UTRANtoGERAN) CShandover(UTRANtoGERAN) CShandover(UTRANtoGERAN) CShandover(UTRANtoGERAN)
Ifcipheringhasbeenstartedwhenanintersystemhandoveroccursfrom
UTRANtoGSMBSS,thenecessaryinformation(e.g.Kc,supported/allowed
GSMcipheringalgorithms)istransmittedwithinthesysteminfrastructure
beforetheactualhandoverisexecutedtoenablethecommunicationto
proceedfromtheoldRNCtothenewGSMBSS,andtocontinuethe
communicationincipheredmode.Theintersystemhandoverwillimplya
changeofcipheringalgorithmfromaUEAtoaGSMA5.TheGSMBSS
includestheselectedGSMcipheringmodeinthehandovercommand
messagesenttotheMSviatheRNC.
Theintegrityprotectionofsignallingmessagesisstoppedathandoverto
GSMBSS.
AtthenetworksidetheMSC/VLRderivestheGSMcipherkeyKcfromthe
UMTScipher/integritykeysCKandIKusedbeforetheintersystemhandover
LeliwaTechnicalBulletinUMTSSecurity

26
(usingtheconversionfunctionc3)andsendsKctothetargetBSC(which
forwardsittotheBTS).
Attheuserside,theMEappliesthederivedGSMcipherkeyKcfromthekey
setwhichwasusedbeforetheintersystemhandover.
CK, IK →Kc
MSC
BSC
GSM A5
RNC
UEA
A5/x
CK, IK →Kc
UMTS security context
Kc
MSC
BSC
GSM A5
RNC
UEA
A5/x
GSM security context

Figure29CShandover(UTRANtoGSMBSS)
TheconversionisonlyneededifbeforethehandovertheUMTSsecurity
contextwasestablished(USIMintheME).Theconversionisnotneededin
casewhenbeforethehandovertheGSMsecuritycontextwasestablished
(SIMintheME).
CShandover(GERANtoUTRAN) CShandover(GERANtoUTRAN) CShandover(GERANtoUTRAN) CShandover(GERANtoUTRAN)
Ifcipheringhasbeenstartedwhenanintersystemhandoveroccursfrom
GSMBSStoUTRAN,thenecessaryinformation(e.g.CK,IK,STARTvalue
information,supported/allowedUMTSalgorithms)istransmittedwithinthe
systeminfrastructurebeforetheactualhandoverisexecutedtoenablethe
communicationtoproceedfromtheoldGSMBSStothenewRNC,andto
continuethecommunicationincipheredmode.Theintersystemhandoverwill
implyachangeofcipheringalgorithmfromaGSMA5toaUEA.
Theintegrityprotectionofsignallingmessagesisstartedimmediatelyafter
theintersystemhandoverfromGSMBSStoUTRANiscompleted.
Atthenetworkside,theMSC/VLRderives,theUMTScipher/integritykeys
CKandIKfromthekeysetusedbeforetheintersystemhandover.
Attheuserside,theMEappliestheUMTScipher/integritykeysCKandIK
fromthekeysetwhichwasusedbeforetheintersystemhandover.
UMTSSecurityLeliwaTechnicalBulletin

27
Kc →CK, IK
MSC
RNC
UEA
BSC
GSM A5
Kc →CK, IK
GSM security context
CK, IK
MSC
RNC
UEA
BSC
GSM A5
UMTS security context

Figure30CShandover(GSMBSStoUTRAN)
TheconversionisonlyneededifbeforethehandovertheGSMsecurity
contextwasestablished(e.g.SIMintheME).Theconversionisnotneeded
incasewhenbeforethehandovertheUMTSsecuritycontextwas
established(USIMintheME).
PSsystemchange(UTRANtoGERAN) PSsystemchange(UTRANtoGERAN) PSsystemchange(UTRANtoGERAN) PSsystemchange(UTRANtoGERAN)
IncaseofanintersystemchangetoaGSMBSS,theSGSNderivestheGSM
cipherkeyKcfromtheUMTScipher/integritykeysCKandIKagreedduring
thelatestAKAprocedureandappliesit.
Attheuserside,theMEappliesthederivedGSMcipherkeyKcreceived
fromtheUSIM/SIMduringthelatestAKAprocedure.
LeliwaTechnicalBulletinUMTSSecurity

28
SGSN
BSC
GEA
RNC
UEA
CK, IK →Kc
CK, IK →Kc UMTS security context
SGSN
BSC
GEA
RNC
UEA
GSM security context

Figure31PSsystemchange(UTRANtoGSMBSS)
TheconversionisonlyneededifbeforethehandovertheUMTSsecurity
contextwasestablished(USIMintheME).Theconversionisnotneededin
casewhenbeforethehandovertheGSMsecuritycontextwasestablished
(SIMintheME).
PSsystemchange(GERANtoUTRAN) PSsystemchange(GERANtoUTRAN) PSsystemchange(GERANtoUTRAN) PSsystemchange(GERANtoUTRAN)
UMTSsecuritycontext UMTSsecuritycontext UMTSsecuritycontext UMTSsecuritycontext
IncaseofanintersystemchangetoaUTRAN,theSGSN,theUMTS
cipher/integritykeysCKandIKagreedduringthelatestUMTSAKA
procedurearesenttothetargetRNC.
Attheuserside,inbothcases,theMEappliestheUMTScipher/integrity
keysCKandIKreceivedfromtheUSIMduringthelatestUMTSAKA
procedure.
SGSN
RNC
UEA
BSC
GEA
UMTS security context
CK, IK

Figure32PSsystemchange(GERANtoUTRAN)–UMTSsecuritycontext
UMTSSecurityLeliwaTechnicalBulletin

29
GSMsecuritycontext GSMsecuritycontext GSMsecuritycontext GSMsecuritycontext
EstablishedforaUMTSsubscriber EstablishedforaUMTSsubscriber EstablishedforaUMTSsubscriber EstablishedforaUMTSsubscriber
AGSMsecuritycontextforaUMTSsubscriberisestablishedincasethe
userhasaR99+MEbuttheSGSNisR98.Asresult,incaseofintersystem
changetoaUTRANcontrolledbyanotherR99+SGSN,theinitialR98-
SGSNsendstheGSMKcagreedduringthelatestGSMAKAprocedureto
thenewSGSNcontrollingthetargetRNC.
SincethenewR99+SGSNhasnoindicationofwhetherthesubscriberis
GSMorUMTS,aR99+SGSNshallperformanewUMTSAKAwhen
receivingKcfromaR98-SGSN.AUMTSsecuritycontextusingfresh
quintetsisthenestablishedbetweentheR99+SGSNandtheUSIM.Thenew
SGSNbecomesthenewanchorpointfortheservice.
SGSN RNC
UEA
BSC
GEA
GSM security context
Kc
SGSN
R99+
R98 USIM
HLR/AuC
UMTS AKA

Figure33PSsystemchange(GERANtoUTRAN)–GSMsecuritycontextfor
UMTSsubscriber
EstablishedforaGSMsubscriber EstablishedforaGSMsubscriber EstablishedforaGSMsubscriber EstablishedforaGSMsubscriber
Atthenetworkside,threecasesaredistinguished:
a) IncaseofanintersystemchangetoaUTRANcontrolledbythesame
SGSN,theSGSNderivesUMTScipher/integritykeysCKandIKfromthe
GSMcipherkeyKc(usingtheconversionfunctionsc4andc5)agreedduring
thelatestGSMAKAprocedureandsendsthemtothetargetRNC.
SGSN
RNC
UEA
BSC
GEA
GSM security context
Kc →CK, IK
Kc →CK, IK
SIM

Figure34PSsystemchange(GERANtoUTRAN)–GSMsecuritycontextfor
GSMsubscriber(sameSGSN)
LeliwaTechnicalBulletinUMTSSecurity

30
b) IncaseofanintersystemchangefromaR99+SGSNtoaUTRAN
controlledbyanotherSGSN,theinitialSGSNsendstheGSMKcagreed
duringthelatestGSMAKAproceduretothe(new)SGSNcontrollingthe
targetRNC.ThenewSGSNbecomesthenewanchorpointfortheservice.
ThenewSGSNstorestheGSMcipherkeyKcandderivestheUMTS
cipher/integritykeysCKandIKwhicharethenforwardedtothetargetRNC.
SGSN RNC
UEA
BSC
GEA
GSM security context
Kc →CK, IK
SGSN
R99+
Kc
Kc →CK, IK
SIM

Figure35PSsystemchange(GERANtoUTRAN)–GSMsecuritycontextfor
GSMsubscriber(SGSNR99+toanotherSGSN)
c) IncaseofanintersystemchangefromanR98-SGSNtoaUTRAN
controlledbyanotherSGSN,theinitialSGSNsendstheGSMcipherkeyKc
agreedduringthelatestGSMAKAproceduretothe(new)SGSNcontrolling
thetargetRNC.ThenewSGSNbecomesthenewanchorpointforthe
service.ToensureuseofUMTSkeysforapossibleUMTSsubscriber
(superfluousinthiscase),aR99+SGSNwillperformanewAKAwhena
R99+MEiscomingfromaR98-SGSN.
SGSN RNC
UEA
BSC
GEA
GSM security context
Kc →CK, IK
SGSN
R98-
Kc
SIM
GSM AKA
HLR/AuC

Figure36PSsystemchange(GERANtoUTRAN)–GSMsecuritycontextfor
GSMsubscriber(SGSNR98-toanotherSGSN)
Attheuserside,inallcases,theMEderivestheUMTScipher/integritykeys
CKandIKfromtheGSMcipherkeyKc(usingtheconversionfunctionsc4
andc5)receivedfromtheSIMduringthelatestGSMAKAprocedureand
UMTSSecurityLeliwaTechnicalBulletin

31
appliesthem.Incasec)thesekeyswillbeover-writtenwithanewCK,IKpair
duetothenewAKA.

LeliwaTechnicalBulletinUMTSSecurity

32
AcronymsandAbbreviations AcronymsandAbbreviations AcronymsandAbbreviations AcronymsandAbbreviations

3G 3G 3G 3G ThirdGeneration
AK AK AK AK AnonymityKey
AKA AKA AKA AKA AuthenticationandKeyAgreement
AMF AMF AMF AMF AuthenticationManagementField
AUC AUC AUC AUC AuthenticationCentre
AUTN AUTN AUTN AUTN AUthenticationTokeN
AUTS AUTS AUTS AUTS AutomaticUpdateTransactionSystem
AV AV AV AV AuthenticationVector
BSC BSC BSC BSC BaseStationController
BSS BSS BSS BSS BaseStationSystem
BTS BTS BTS BTS BaseTransceiverStation
CK CK CK CK CipheringKey
CKSN CKSN CKSN CKSN CipheringKeySequenceNumber
CN CN CN CN CoreNetwork
CS CS CS CS
CircuitSwitching/ConvergenceSublayer/
CodingScheme
FIFO FIFO FIFO FIFO FirstIn,FirstOut
GERAN GERAN GERAN GERAN GSM/EDGERadioAccessNetwork
GPRS GPRS GPRS GPRS GeneralPacketRadioService
GSM GSM GSM GSM GlobalSystemforMobileCommunications
HE HE HE HE HomeEnvironment
HLR HLR HLR HLR HomeLocationRegister
IK IK IK IK IntegrityProtectionKey
IMSI IMSI IMSI IMSI InternationalMobileSubscriberIdentity
LA LA LA LA LocationArea/LinkAdaptation
LAI LAI LAI LAI LocationAreaIdentity
MAC MAC MAC MAC
MediaAccessControl/Message
AuthenticationCode
MAC MAC MAC MAC- -- -I II I MessageAuthenticationCodeforIntegrity
ME ME ME ME MobileEquipment
MS MS MS MS MobileStation
PS PS PS PS PacketSwitching/PresenceService
P PP P- -- -TMSI TMSI TMSI TMSI PacketTMSI
RA RA RA RA RoutingArea
RAI RAI RAI RAI RoutingAreaIdentity
RAN RAN RAN RAN RadioAccessNetwork
RANAP RANAP RANAP RANAP RANApplicationPart
RAND RAND RAND RAND RandomNumber
RES RES RES RES authenticationRESponse
RLC RLC RLC RLC RadioLinkControl
UMTSSecurityLeliwaTechnicalBulletin

33
RNC RNC RNC RNC RadioNetworkController
RRC RRC RRC RRC RadioResourceControl
SEQ SEQ SEQ SEQ SequenceNumber
SGSN SGSN SGSN SGSN ServingGPRSSupportNode
SIM SIM SIM SIM SubscriberIdentityModule
SN SN SN SN ServingNetwork/SubscriberNumber
SQN SQN SQN SQN SeQuenceNumber
SRNC SRNC SRNC SRNC ServingRadioNetworkController
TMSI TMSI TMSI TMSI TemporaryMobileSubscriberIdentity
UEA UEA UEA UEA UserEncryptionAlgorithm
UMTS UMTS UMTS UMTS UniversalMobileTelecommunicationSystem
USIM USIM USIM USIM UMTSSubscriberIdentityModule
UTRAN UTRAN UTRAN UTRAN UMTSTerrestrialRadioAccessnetwork
VLR VLR VLR VLR VisitorLocationRegister
XRES XRES XRES XRES eXpectedRESponse

LeliwaTechnicalBulletinUMTSSecurity

34
References References References References
Thissectioncontainsthelocationsofvariousspecifications,document
referencesandusefulinformationwhereyoucanlearnmoreaboutthis
subject.

[1] 33.1023Gsecurity;Securityarchitecture

[2] 25.331RadioResourceControl(RRC);Protocolspecification

[3] 25.321MediumAccessControl(MAC)protocolspecification

[4] 25.322RadioLinkControl(RLC)protocolspecification

[5] 25.413UTRANIuinterfaceRadioAccessNetworkApplicationPart
(RANAP)signalling

[6] 24.301Non-Access-Stratum(NAS)protocolforEvolvedPacket
System(EPS);Stage3

UMTSSecurityLeliwaTechnicalBulletin

35
Disclaimer Disclaimer Disclaimer Disclaimer
ThisdocumentisbasedonLeliwatrainingmaterials.

Informationinthisdocumentissubjecttochangewithoutnotice.Leliwa
assumesnoresponsibilityforanyerrorsthatmayappearinthisdocument.

Thisdocumentmaybefreelyredistributed.Youcanstoreitonanyservers
andmakeitavailableforpublicdownload.Insuchcaseitmustbeclearly
indicatedthatitcomesfromLeliwawebsitewww.leliwa.com

Ifyoureceivedonlythisfile,youcandownloadmoreLeliwaTechnical
Bulletinsfromthefollowingaddress:
http://www.leliwa.com/downloads
Ifyouwanttobeinformedwhenthenewbulletinsareuploaded,pleasesend
ablanke-mailwithSubject="Update_request"tobulletins@leliwa.comor
clickthislink:mailto:bulletins@leliwa.com?subject=Update_request

LeliwaSp.zo.o. LeliwaSp.zo.o. LeliwaSp.zo.o. LeliwaSp.zo.o.

Plebiscytowa1.122
PL-44-100Gliwice
Poland
GPS:N50.2981°,E018.6561°

telephone:+48323766305
fax:+48323766307
Skype:leliwa_poland
email:info@leliwa.com

LeliwaTelecomAB LeliwaTelecomAB LeliwaTelecomAB LeliwaTelecomAB

Orrpelsvägen66
SE-16766BROMMA
Sweden
GPS:N59.3260°,E17.9464°

telephone:+4684459430
email:info@leliwa.com

Leliwa Technical Bulletin

UMTS Security

Table of contents
Topic Page

Introduction.....................................................................................................3 User identity confidentiality .............................................................................3 Entity authentication .......................................................................................7 Confidentiality ...............................................................................................15 Data integrity ................................................................................................20 UMTS – GSM interoperation..........................................................................22 Acronyms and Abbreviations ........................................................................32 References ...................................................................................................34 Disclaimer.....................................................................................................35

2

UMTS Security

Leliwa Technical Bulletin

Introduction
This document describes the set of security features that provide users with secure access to 3G services, and which in particular protect against attacks on the (radio) access link. UMTS offers the following security features (see Fig. 1):

UMTS security features
user identity confidentiality, authentication of the user toward the network, authentication of the network toward the user, confidentiality (ciphering), data integrity.

Figure 1 UMTS security features
As in GSM/GPRS, user (temporary) identification, authentication and key agreement takes place independently in each service domain. User plane traffic is ciphered using the cipher key agreed for the corresponding service domain while control plane data is ciphered and integrity protected using the cipher and integrity keys from either one of the service domains.

User identity confidentiality
The permanent user identity (IMSI) of a user to whom a services is delivered cannot be eavesdropped on the radio access link. To achieve this, the user is normally identified by a temporary identity by which he is known by the visited serving network. This mechanism allows the identification of a user on the radio access link by means of a Temporary / Packet-Temporary Mobile Subscriber Identity (TMSI/P-TMSI). A TMSI / P-TMSI has local significance only in the Location Area (LA) or Routing Area (RA) in which the user is registered. Outside that area it is accompanied by an appropriate Location Area Identification (LAI) or Routing Area Identification (RAI) in order to avoid ambiguities. The association between the permanent and temporary user identities is kept by the VLR/SGSN in which the user is registered.

3

If a TMSI provided by an MS is unknown in the network e. To avoid user traceability. due to a data base failure. the network requires the MS to provide its IMSI. The reallocation of a TMSI can be performed either by a unique procedure described in the next section or implicitly by a location updating procedure. TMSI reallocation procedure The purpose of the TMSI reallocation procedure is to allocate a new TMSI/LAI pair to a user by which he may subsequently be identified on the radio access link. when available. which may lead to the compromise of user identity confidentiality. location update requests. In addition any signalling or user data that might reveal the user's identity is ciphered on the radio access link.Leliwa Technical Bulletin UMTS Security TMSI RAN IMSI Core Network TMSI P-TMSI MSC/VLR SGSN IMSI IMSI P-TMSI IMSI Figure 2 User identity confidentiality The TMSI / P-TMSI. In this case the identification procedure is used before the TMSI reallocation procedure is initiated. The allocation of a temporary identity is illustrated in Fig. service requests. is normally used to identify the user on the radio access path. for instance in paging requests. connection re-establishment requests and detach requests. LAIn / P-TMSIn. RAIn (P-)TMSI Allocation Command (P-) TMSI Allocation Complete Figure 3 TMSI allocation SGSN VLR 4 . attach requests. The procedure is performed after the initiation of ciphering. the user is not identified for a long period by means of the same temporary identity. TMSIn.g. 3.

The VLR then sends the TMSIn and optionally the new location area identity LAIn to the user.UMTS Security Leliwa Technical Bulletin The VLR generates a new temporary identity (TMSIn) and stores the association of TMSIn and the permanent identity IMSI in its database. security context SGSNo VLRo Figure 4 Distribution of IMSI between VLRs / SGSNs The procedure is invoked by the newly visited VLRn/SGSNn after the receipt of a Location update request / Routing area update request from the user wherein the user is identified by means of a temporary user identity TMSIo/P-TMSIo and the location area identity LAIo / routing area identity RAIo under the jurisdiction of a previously visited VLRo/SGSNo that belongs to the same serving network domain as the newly visited VLRn/SGSNn. LAIo / P-TMSIo. If the previously visited VLRo cannot be contacted or cannot retrieve the user identity. SGSNn VLRn Loc. The user sends an acknowledgement back to the VLR. Upon receipt the user stores TMSIn and automatically removes the association with any previously allocated TMSI. 5 . the visited VLRn request the previously visited VLRo to send the permanent user identity and optionally temporary authentication data. The VLRn/SGSNn sends a User identity request to the VLRo/SGSNo. Upd (TMSI) / RA Upd (P-TMSI) TMSIo. Distribution of IMSI and authentication data In case a user identifies itself using a TMSIo/LAIo pair that was not assigned by the visited VLRn and the visited VLRn and the previously visited VLRo exchange authentication data. Upon receipt of the acknowledgement the VLR removes the association with the old temporary identity TMSIo and the IMSI (if there was any) from its database. RAIo User identity request User identity response IMSI. this message contains TMSIo and LAIo / P-TMSIo and RAIo. quintets / triplets. the visited VLRn requests the user to identify itself by means of its permanent user identity.

The user's response contains the IMSI in clear text. This represents a breach in the provision of user identity confidentiality. SGSN VLR User identity request User identity response IMSI Figure 5 Identification by the permanent identity The mechanism is initiated by the visited VLR/SGSN that requests the user to send its permanent identity. Identification by a permanent identity The mechanism is invoked whenever the user cannot be identified by means of a temporary identity. If the user cannot be identified the VLRo/SGSNo sends a User identity response indicating that the user identity cannot be retrieved. it creates an entry and stores any authentication vectors and any data on the current security context. If the user is found. IK and KSI (UMTS) or Kc and CKSN (GSM). If the VLRn/SGSNn receives a User identity response with an IMSI.Leliwa Technical Bulletin UMTS Security The VLRo/SGSNo searches the user data in the database. or when the serving network cannot retrieve the IMSI from the TMSI / P-TMSI by which the user identifies itself on the radio path. may include the current security context data: CK. In particular. it is used when the user registers for the first time in a serving network. If the VLRn/SGSNn receives a User identity response indicating that the user could not be identified. the VLRo/SGSNo sends a user identity response back that: • • • includes the IMSI may include a number of unused authentication vectors (quintets or triplets). 6 . it initiates the user identification procedure described in the next section.

The sequence number SQNHE is an individual counter for each user and the sequence number SQNMS denotes the highest sequence number the USIM has accepted.UMTS Security Leliwa Technical Bulletin Entity authentication Two security features related to entity authentication are provided: • • user authentication: the property that the serving network corroborates the user identity of the user. and a local authentication mechanism using the integrity key established between the user and serving network during the previous execution of the authentication and key establishment procedure. this includes the guarantee that this authorisation is recent. The entity authentication occurs at each connection set-up between the user and the network. The method is composed of a challenge / response protocol identical to the GSM subscriber authentication and key establishment protocol 7 . network authentication: the property that the user corroborates that he is connected to a serving network that is authorised by the user's HE to provide him services. In addition the USIM and the HE keep track of counters SQNMS and SQNHE respectively to support network authentication. The method was chosen in such a way as to achieve maximum compatibility with the GSM security architecture and facilitate migration from GSM to UMTS. Two mechanisms have been included: an authentication mechanism using an authentication vector delivered by the user's HE to the serving network. Serving Network user authentication network authentication Figure 6 Entity authentication Authentication and key agreement The mechanism described here achieves mutual authentication by the user and the network showing knowledge of a secret key K which is shared between and available only to the USIM and the AuC in the user's HE.

Each authentication vector consists of the following components: a random number RAND. The established keys CK and IK will then be transferred by the USIM and the VLR/SGSN to the entities which perform ciphering and integrity functions. Upon receipt of a request from the VLR/SGSN. the HE/AuC sends an ordered array of n authentication vectors AV(1.n). 7. an expected response XRES. An overview of the mechanism is shown in Fig.n)) Store authentication vectors Select authentication vector AV(i) User authentication request (RAND(i). compute RES(i) User authentication response (RES(i)) Compare RES(i) and XRES(i) Compute CK(i) and IK(i) Select CK(i) and IK(i) Figure 7 Authentication and key agreement The Authentication data request includes the IMSI and the requesting node type (PS or CS)... an integrity key IK and an authentication token AUTN. The VLR/SGSN compares the received RES with XRES. AUTN(i)) Verify AUTN(i). it selects the next authentication vector from the ordered array and sends the parameters RAND and AUTN to the user.. produces a response RES which is sent back to the VLR/SGSN. Authentication is in that case Authentication and key establishment 8 . The USIM also computes CK and IK. SGSN VLR Distribution of authentication vectors from HE to SN HLR Authentication data request (IMSI) Generate authentication vectors AV(1.n) Authentication data response (AV(1. a cipher key CK. Each authentication vector is good for one authentication and key agreement between the VLR/SGSN and the USIM. The USIM checks whether AUTN can be accepted and. if so. When the VLR/SGSN initiates an authentication and key agreement. (the equivalent of a GSM ‘triplet’) to the VLR/SGSN. The authentication vectors are ordered based on sequence number. If they match the VLR/SGSN considers the authentication and key agreement exchange to be successfully completed. VLR/SGSNs can offer secure service even when HE/AuC links are unavailable by allowing them to use previously derived cipher and integrity keys for a user so that a secure connection can still be set up without the need for an authentication and key agreement. Authentication vectors in a particular node are used on an FIFO basis.Leliwa Technical Bulletin UMTS Security combined with a sequence number-based one-pass protocol for network authentication.

The concealment of the sequence number is to protect against passive attacks only. by means of data integrity protection of signalling messages. 8 shows the generation of an authentication vector AV by the HE/AuC. 9 . an Integrity Key IK = f4K (RAND) where f4 is a key generating function. Finally the authentication token AUTN = SQN ⊕ AK || AMF || MAC is constructed. Subsequently the following values are computed: • • • • • a Message Authentication Code MAC = f1K(SQN || RAND || AMF) where f1 is a message authentication function. Generate SQN Generate RAND K AMF SQN RAND f1 f2 f3 f4 f5 MAC XRES CK IK AK AUTN := SQN ⊕ AK || AMF || MAC AV := RAND || XRES || CK || IK || AUTN Figure 8 Generation of authentication vectors The HE/AuC starts with generating a fresh sequence number SQN and an unpredictable challenge RAND. an Anonymity Key AK = f5K (RAND) where f5 is a key generating function or f5 ≡ 0.UMTS Security Leliwa Technical Bulletin based on a shared integrity key. AK is an anonymity key used to conceal the sequence number as the latter may expose the identity and location of the user. an eXpected RESponse XRES = f2K (RAND) where f2 is a message XRES authentication function. For each user the HE/AuC keeps track of a counter SQNHE. a Cipher Key CK = f3K (RAND) where f3 is a key generating function. Generation of authentication vectors Fig.

AMF may be used to indicate the algorithm and key used to generate a particular authentication vector. • • Fig. The AMF field may be used by the operator to set or adjust this limit in the USIM). Parameter name K RAND SQN AK AMF MAC authentication Key RANDom challenge SeQuence Numbers Anonymity Key Authentication Management Field Message Authentication Code Length 128 bits 128 bits 48 bits 48 bits 16 bits 64 bits 64 bits 128 bits 128 bits var.) setting threshold values to restrict the lifetime of cipher and integrity keys (The USIM contains a mechanism to limit the amount of data that is protected by an access link key set. Example uses of AMF includes: • support multiple authentication algorithms and keys (This mechanism is useful for disaster recovery purposes. 4-16 octets MAC-S Message Authentication Code CK IK RES Cipher Key Integrity Key authentication RESponse Figure 9 Authentication parameters 10 . 9 shows the summary of all authentication parameters.) changing sequence number verification parameters (This mechanism is used to change dynamically the limit on the difference between the highest SEQ accepted so far and a received sequence number SEQ.Leliwa Technical Bulletin UMTS Security An authentication and key management field AMF is included in the authentication token of each authentication vector.

Upon receipt the user proceeds as shown in Fig. SGSN VLR User authentication request (RAND || AUTN) User authentication response (RES) User authentication reject (CAUSE) Figure 10 Authentication and key establishment The VLR/SGSN invokes the procedure by selecting the next unused authentication vector in the VLR/SGSN database and sends to the USIM the random challenge RAND and an authentication token for network authentication AUTN. RAND AUTN SQN⊕AK f5 AK AMF MAC ⊕ SQN K f1 XMAC f2 RES f3 CK f4 IK Verify MAC = XMAC Verify that SQN is in the correct range Figure 11 User authentication function in the USIM Upon receipt of RAND and AUTN the USIM first computes the anonymity key AK = f5K (RAND) and retrieves the sequence number SQN = (SQN ⊕ AK) ⊕ AK. During the authentication. the USIM verifies the freshness of the authentication vector that is used. 11. 11 .UMTS Security Leliwa Technical Bulletin Authentication Authentication and key agreement The purpose of this procedure is to authenticate the user and establish a new pair of cipher and integrity keys between the VLR/SGSN and the USIM.

If XRES and RES are different. If XRES equals RES then the authentication of the user has passed. The same minimum number x needs to be used across the systems to guarantee that the synchronisation failure rate is sufficiently low under various usage scenarios. it sends Synchronisation failure back to the VLR/SGSN and abandons the procedure. the USIM computes RES = f2K (RAND) and includes this parameter in a User authentication response back to the VLR/SGSN. Sequence numbers The verification of the SQN by the USIM will cause the MS to reject an attempt by the VLR/SGSN to re-use a quintet to establish a particular UMTS security context more than once. VLR/SGSN may also decide to initiate a new identification and authentication procedure towards the user. sequence numbers). The VLR/SGSN also selects the appropriate cipher key CK and integrity key IK from the selected authentication vector. If correct. Finally the USIM computes the cipher key CK = f3K (RAND) and the integrity key IK = f4K (RAND). in particular simultaneous registration in the CS. This requires the capability of the USIM to store information on past successful authentication events (e. If the USIM also supports conversion function c3. see Fig. Next the USIM verifies that the received sequence number SQN is in the correct range. VLR/SGSN initiates an Authentication failure report procedure towards the HLR and may also decide to initiate a new identification and authentication procedure towards the user. If the USIM considers the sequence number to be not in the correct range. 12. The mechanism ensures that a sequence number can still be accepted if it is among the last x = 32 sequence numbers generated. In this case. 12 . The mechanisms for verifying the freshness of sequence numbers in the USIM to some extent allows the out-of-order use of sequence numbers.and the PS-service domains and user movement between VLRs/SGSNs which do not exchange authentication information. This is to ensure that the authentication failure rate due to synchronisation failures is sufficiently low. the user sends User authentication reject back to the VLR/SGSN with an indication of the cause and the user abandons the procedure. If they are different. In general therefore the VLR/SGSN can use a quintet only once.g. VLR/SGSN initiates an Authentication failure report procedure towards the HLR. it derives the GSM cipher key Kc from the UMTS cipher/integrity keys CK and IK. Upon receipt of User authentication response the VLR/SGSN compares RES with the eXpected RESponse XRES from the selected authentication vector.Leliwa Technical Bulletin UMTS Security Next the USIM computes XMAC = f1K (SQN || RAND || AMF) and compares this with MAC which is included in AUTN.

f5. It is AUTS = Conc(SQNMS ) || MAC-S.UMTS Security Leliwa Technical Bulletin SGSN VLR User authentication request (RAND || AUTN) User authentication reject (AUTS. together with the parameters: • • RAND sent to the MS in the preceding user authentication request.. both with the property that no valuable information can be inferred from the function values of f1* and f5* about those of f1. . f1* is a message authentication code (MAC) function and f5* is the key generating function used to compute AK in re-synchronisation procedures. The construction of the parameter AUTS in shown in the Fig. 13 . described earlier in this chapter and one used in case of synchronisation failures. and MAC-S = f1*K(SQNMS || RAND || AMF) where RAND is the random value received in the current user authentication request and AMF is a dummy value of all zeros. and AUTS received by the VLR/SGSN in the response to that request. the VLR/SGSN sends an authentication data request with a ‘synchronisation failure indication’ to the HE/AuC. f5* and vice versa. described in this section. Upon receiving a synchronisation failure message from the user. SQNMS K RAND AMF f1* MAC-S f5* AK ⊕ SQNMS⊕AK AUTS = SQNMS ⊕ AK || MAC-S Figure 13 Construction of the parameter AUTS Re-synchronisation procedure A VLR/SGSN may send two types of authentication data requests to the HE/AuC.. CAUSE = synchronisation failure) Figure 12 Synchronisation failure The synchronisation failure message contains the parameter AUTS. the (regular) one. 13. . Conc(SQNMS) = SQNMS ⊕ f5*K(RAND) is the concealed value of the counter SQNMS in the MS.

e. The Authentication failure report contains among other parameters: subscriber identity. if the next sequence number generated SQNHE using would be accepted by the USIM. SGSN VLR RAND. Whenever the VLR/SGSN receives a new batch of authentication vectors it deletes the old ones for that user in the VLR/SGSN and the user may now be authenticated based on a new authentication vector. failure cause.Leliwa Technical Bulletin UMTS Security When the HE/AuC receives an authentication data request with a ‘synchronisation failure indication" it retrieves SQNMS from Conc(SQNMS) by computing Conc(SQNMS) ⊕ f5*K(RAND) and checks if SQNHE is in the correct range. access type. AUTN AUTS HLR/AuC RAND. SGSN VLR Authentication failure report (IMSI. i. VLR/SGSN address and RAND. failure cause code (wrong network signature / wrong user response). VLR/SGSN address and RAND) HLR Figure 15 Reporting authentication failure from VLR/SGSN to HLR The procedure is invoked by the serving network VLR/SGSN when the authentication procedure fails. authentication re-attempt. see Fig. AUTS {Qi} Figure 14 Re-synchronisation mechanism Reporting authentication failures The purpose of this procedure is to provide a mechanism for reporting authentication failures from the serving environment back to the home environment. Otherwise it verifies AUTS and if the verification is successful the HE/AuC resets the value of the counter SQNHE to SQNMS. The HE may cancel the location of the user after receiving an authentication failure report and stores the received data so that further processing to detect possible fraud situations could be performed. 14 . If SQNHE is in the correct range then the HE/AuC sends an authentication data response with a new batch of authentication vectors to the VLR/SGSN. 15.

RNC SGSN VLR Authentication CK. The data integrity of the classmark is performed. signalling confidentiality of signalling data (signalling data cannot be overheard on the radio access interface). Cipher key and integrity key setting Authentication and key setting are triggered by the authentication procedure described earlier in this chapter.UMTS Security Leliwa Technical Bulletin Confidentiality Four security features related to confidentiality are provided: • • • • cipher algorithm agreement (MS and the SN securely negotiate the algorithm that they use subsequently). This information itself is integrity protected. confidentiality of user data (user data cannot be overheard on the radio access interface). As it is the case that the RNC does not have the integrity key IK when receiving the MS/USIM Classmark this information must be stored in the RNC. The CK and IK for the CS domain and separately for PS domain are stored on the USIM and updated at the next authentication from each domain. cipher key agreement (MS and the SN agree on a cipher key that they use subsequently). The CK and IK are stored in the VLR/SGSN and transferred to the RNC when needed. 15 . the MS indicates to the network in the MS/USIM Classmark which cipher and integrity algorithms the MS supports. IK Figure 16 Cipher key and integrity key setting CK. IK integrity Ciphering and integrity mode negotiation When an MS wishes to establish a connection with the network. during the security mode set-up procedure by use of the most recently generated IK.

Leliwa Technical Bulletin UMTS Security Cipher key and integrity key identification The key set identifier (KSI) is a number which is associated with the cipher and integrity keys derived during authentication. The key set identifier is three bits (seven values are used to identify the key set and a value of ‘111’ is used by the MS to indicate that a valid key is not available for use). integrity protection Figure 17 Cipher key and integrity key identification Cipher key and integrity key lifetime Authentication and key agreement. The lifetime of cipher and integrity keys is limited by THRESHOLD values that can be set or adjust by the operator and send to the USIM inside AMF field of the authentication vector. The purpose of the key set identifier is to make it possible for the network to identify the cipher key CK and integrity key IK which are stored in the MS without invoking the authentication procedure. This is used to allow re-use of the cipher key CK and integrity key IK during subsequent connection set-ups. For that purpose the ME and the USIM have the ability to store a 16 . KSI and CKSN have the same format. which generates cipher/integrity keys. KSI in UMTS corresponds to CKSN in GSM. is not mandatory at call set-up. KSI KSI Authentication after some time KSI CK. KSI Ciphering. IK. SGSN VLR CK. The ciphering and integrity protection algorithms are driven by counters (COUNT-C and COUNT-I) that at connection establishment need to be initialised. and there is therefore the possibility of unlimited and malicious re-use of compromised keys. IK. The USIM stores one KSI/CKSN for the PS domain key set and one KSI/CKSN for the CS domain key set. The key set identifier is allocated by the network and sent with the authentication request message to the MS where it is stored together with the calculated cipher key CK and integrity key IK. The USIM therefore contains a mechanism to limit the amount of data that is protected by an access link key set.

During authentication and key agreement the START value associated with the new key set of the corresponding service domain is set to 0 in the USIM and in the ME. possible authentication and start of integrity protection and possible ciphering. Than the COUNT-C and COUNT-I is incremented at each RLC cycle. The ME and the RNC initialise the 20 most significant bits of the COUNT-C and OUNT-I to the current value of START and the remaining bits to zero at the start of ciphering. The ME marks the START values in the USIM as invalid by setting STARTCS and STARTPS to THRESHOLD.UMTS Security Leliwa Technical Bulletin START value. The ciphering sequence number COUNT-C and integrity sequence number COUNT-I are both 32 bits long. The ME and the USIM store a STARTCS value for the CS cipher/integrity keys and a STARTPS value for the PS cipher/integrity keys. integrity protection 0 8 4 7 1 0 8 4 7 1 START=THRESHOLD after some time Authentication 0 0 0 0 0 Ciphering. integrity protection 0 5 6 9 2 0 5 6 9 2 START=5692 after some time Ciphering. 17 . integrity protection Figure 18 Cipher key and integrity key lifetime setSecurity mode set-up procedure This section describes one common procedure for both ciphering and integrity protection set-up. The message sequence flow below describes the information transfer at initial connection establishment. At radio connection establishment for a particular serving network domain (CS or PS) the ME sends the STARTCS and the STARTPS value to the RNC in the RRC connection setup complete message. The length of START is 20 bits. SGSN VLR THRESHOLD=8000 Authentication 0 0 0 0 0 Ciphering.

Because of that the MS can have two ciphering and integrity key sets. Attach request. A new KSI will then also be allocated. Optionally the GSM Classmarks 2 and 3 and the START values for the CS/PS service domain are included. The VLR/SGSN initiates integrity and ciphering by sending the RANAP message Security Mode Command to SRNC that contains the IK and CK to be used. mode cmd. This is obtained by including a CN type indicator information in the Security mode command message. Before sending this message to the MS. this is indicated in the message sent to the SRNC. (CN dom. MAC-I) Verification Security mode complete (MAC-I) Verification Ciphering / deciphering Security mode complete (MAC-I) Security mode cmd. The MS verifies the 18 . Paging response etc. the SRNC generates the MAC-I (Message Authentication Code for Integrity) and attaches this information to the message. authentication of the user and generation of new security keys (IK and CK) may be performed. CM service request. The MS sends the Initial L3 message (Location update request. The START values and the UE security capability information are stored in the SRNC. User identity request. KSI) Authentication and key generation Sec.Leliwa Technical Bulletin UMTS Security SRNC RRC connection establishment (START values) SGSN VLR ‘Initial L3 message’ (user identity. (CK. Routing area update request.) to the VLR/SGSN.. The MS computes XMAC-I on the message received by using the UIA. The indication of new generated keys implies that the START value is to be reset at start use of the new keys. If a new authentication and security key generation has been performed. IK) Figure 19 Local authentication and connection set-up RRC connection establishment includes the transfer from MS to RNC of the ciphering capabilities (UEAs) and the integrity capabilities (UIAs) of the MS. it is the START value already available in the SRNC that is used. the stored COUNT-I and the received FRESH parameter. the network must indicate which key set to use. This message contains the user identity and the KSI. Otherwise. The SRNC generates the RRC message Security mode command. FRESH. The message includes the random value FRESH to be used for integrity protection.

UMTS Security Leliwa Technical Bulletin integrity of the message by comparing the received MAC-I with the generated XMAC-I. the SRNC computes the XMAC-I on the message. this and all following messages sent from the MS are integrity protected using the new integrity configuration. The Security mode command to MS starts the downlink integrity protection. If verification is not successful. The transfer of the RANAP message Security mode complete from SRNC to the VLR/SGSN ends the procedure. Ciphering method Fig. The MS compiles the RRC message Security mode complete and generates the MAC-I for this message. the Ciphering Activation time information that is exchanged between SRNC and MS during the Security mode set-up procedure sets the RLC Sequence Number/Connection Frame Number when to start ciphering in Downlink respective Uplink using the new ciphering configuration. The Security mode complete from MS starts the uplink integrity protection. this and all following downlink messages sent to the MS are integrity protected using the new integrity configuration. the procedure ends in the MS. i. i. Sender COUNT-C DIRECTION BEARER LENGTH CK f8 KEYSTREAM BLOCK PLAINTEXT BLOCK CK Receiver COUNT-C DIRECTION BEARER LENGTH f8 KEYSTREAM BLOCK CIPHERTEXT BLOCK ⊕ ⊕ PLAINTEXT BLOCK Figure 20 Ciphering of user and signalling data 19 . 20 illustrates the use of the ciphering algorithm f8 to encrypt plaintext by applying a keystream using a bit per bit binary addition of the plaintext and the keystream.e. At reception of the response message. The plaintext may be recovered by generating the same keystream using the same input parameters and applying a bit per bit binary addition with the ciphertext. When ciphering shall be started.e. The SRNC verifies the data integrity of the message by comparing the received MAC-I with the generated XMAC-I.

integrity key agreement (the MS and the SN agree on an integrity key that they use subsequently). data integrity and origin authentication of signalling data (the property that the receiving entity (MS or SN) is able to verify that signalling data has not been modified in an unauthorised way since it was sent by the sending entity (SN or MS) and that the data origin of the signalling data received is indeed the one claimed).Leliwa Technical Bulletin UMTS Security The input parameters to the algorithm are the cipher key CK. The signalling radio bearers are used for transfer of signalling data for services delivered by both CS and PS service domains. The radio bearers for CS user data are ciphered with CKCS. established between the CS service domain and the user and one CK for PS connections (CKPS) established between the PS service domain and the user. There is one BEARER parameter per radio bearer associated with the same user and multiplexed on a single 10ms physical layer frame. Based on these input parameters the algorithm generates the output keystream block KEYSTREAM which is used to encrypt the input plaintext block PLAINTEXT to produce the output ciphertext block CIPHERTEXT. Data integrity Three security features related to data integrity are provided: • • • integrity algorithm agreement (the MS and the SN securely negotiate the integrity algorithm that they use subsequently). There is one CK for CS connections (CKCS). The LENGTH indicator determines the length of the required keystream block. the direction of transmission DIRECTION and the length of the keystream required LENGTH. The DIRECTION identifier is input to avoid that for the keystreams for the uplink and for the down-link would use the identical set of input parameter values. The radio bearers for PS user data are ciphered with CKPS. a time dependent input COUNT-C. The radio bearer identifier is input to avoid that for different keystream an identical set of input parameter values is used. 20 . the bearer identity BEARER. Integrity key agreement and integrity algorithm agreement is realised by means of a mechanism that are described earlier in this chapter. These signalling radio bearers are ciphered by the CK of the service domain for which the most recent security mode negotiation took place.

The receiver computes XMAC-I on the message received in the same way as the sender computed MAC-I on the message sent and verifies the data integrity of the message by comparing it to the received MAC-I. There may be one IK for CS connections (IKCS). Sender COUNT-I DIRECTION FRESH IK COUNT-I Receiver DIRECTION FRESH MESSAGE IK f9 MAC-I MESSAGE f9 XMAC-I Figure 21 Derivation of MAC-I (or XMAC-I) on a signalling message The input parameters to the algorithm are the Integrity Key (IK). The network-side nonce FRESH is 32 bits long. This mechanism assures the network that the user is not replaying any old MAC-Is. Based on these input parameters the user computes message authentication code for data integrity MAC-I using the integrity algorithm f9. At connection set-up the RNC generates a random value FRESH and sends it to the user in the (RRC) Security mode command. The signalling radio bearers are used for transfer of signalling data for services delivered by both CS and PS service domains. 21 . The MAC-I is then appended to the message when sent over the radio access link. These signalling radio bearers are data integrity protected by the IK of the service domain for which the most recent security mode negotiation took place. The value FRESH is subsequently used by both the network and the user throughout the duration of a single connection. established between the CS service domain and the user and one IK for PS connections (IKPS) established between the PS service domain and the user. 21 illustrates the use of the integrity algorithm f9 to authenticate the data integrity of a signalling message. a random value generated by the network side (FRESH). the direction bit DIRECTION and the signalling data MESSAGE. The input parameter FRESH protects the network against replay of signalling messages by the user. The data integrity of radio bearers for user data is not protected. The rest of the input parameters have exactly the same meaning as for algorithm for ciphering described in the previous section. the integrity sequence number (COUNT-I).UMTS Security Leliwa Technical Bulletin Data integrity protection method Fig.

faulty or missing MAC) is detected after that the integrity protection is started the concerned message is discarded. CK. by the VLR/SGSN on the network side and by the USIM on the user side. In this case. IK → Kc BSC Kc GSM EA A5/x Figure 22 User attached to GSM BSS with UMTS AKA capable ME (VLR/SGSN R99+) GSM AKA is applied when the user is attached to a GSM BSS. USIM SGSN VLR RAND. IK → Kc CK. the GSM cipher key Kc is derived from the UMTS cipher/integrity keys CK and IK. the GSM user response SRES and the GSM cipher key Kc are derived from the UMTS user response RES and the UMTS cipher/integrity keys CK and IK.XRES. In case of failed integrity check (i. in case the user has a ME not capable of UMTS AKA.Leliwa Technical Bulletin UMTS Security Unsuccessful integrity check The supervision of failed integrity checks is performed both in the MS and the SRNC. AUTN RES HLR/AuC {RAND. UMTS – GSM interoperation UMTS subscriber connected to GSM BSS UMTS AKA is applied when the user is attached to a GSM BSS. IK. In this case. A R98VLR/SGSN uses the stored Kc and RES and a R99+ VLR/SGSN derives the SRES from RES and Kc from CK. 22 . in case the user has a ME capable of UMTS AKA and also the VLR/SGSN is R99+.e. AUTN} UMTS AKA CK. IK.

the USIM derives the GSM user response SRES and the GSM cipher key Kc from the UMTS user response RES and the UMTS cipher/integrity keys CK. RES → SRES {RAND. In this case. 25 shows the different scenarios that can occur with UMTS subscribers in a mixed network architecture. in case the VLR/SGSN is R98-. 23 . RES → SRES GSM AKA SRES BSC Kc GSM EA A5/x RAND CK. CK. Kc} RAND CK. RES → SRES GSM AKA SRES BSC Kc GSM EA A5/x Figure 24 User attached to GSM BSS (VLR/SGSN R99-) Fig.UMTS Security Leliwa Technical Bulletin USIM SGSN VLR HLR/AuC {RAND.XRES. IK.SRES. IK. IK → Kc. IK → Kc. RES → SRES Figure 23 User attached to GSM BSS with UMTS AKA non-capable ME (VLR/SGSN R99+) GSM AKA is applied when the user is attached to a GSM BSS. AUTN} CK. IK → Kc. IK → Kc. USIM SGSN VLR HLR/AuC CK.

IK [Kc] Release 98CK. Kc CK. Kc CK. AUTN.. IK. RES RAND. and the UMTS cipher/integrity keys CK an IK are always sent to the RNC. IK → Kc CK. AUTN.0 if XRES is shorter than 16 octets. GSM AKA is always used. Fig.Leliwa Technical Bulletin UMTS Security Release 99+ HLR/AuC Quintets CK. When in an UTRAN. IK → Kc RES → SRES [Kc] VLR/SGSN [Kc] UTRAN RAND. Figure 26 Conversion functions GSM subscribers connected to UTRAN For GSM subscribers. ciphering is applied in the GSM BSS for services delivered via the MSC/VLR.or R99+ ME in a mixed network architecture. SRES UMTS AKA capable ME CK. SRES RAND. and by the SGSN for services delivered via the SGSN. c1: RAND[GSM] = RAND c2: SRES[GSM] = XRES*1 ⊕ XRES*2 ⊕ XRES*3 ⊕ XRES*4 c3: Kc[GSM] = CK1 ⊕ CK2 ⊕ IK1 ⊕ IK2 XRES* is 16 octets long and XRES* = XRES if XRES is 16 octets long and XRES* = XRES || 0.. IK. CKi and IKi are both 64 bits long and CK = CK1 || CK2 and IK = IK1 || IK2. ciphering and integrity are always applied in the RNC. IK → Kc CK. IK → Kc RES → SRES Kc ME CK. the UMTS CK and IK are derived from the GSM cipher key Kc by the ME and the VLR/SGSN. IK → Kc RES → SRES UMTS security USIM GSM security Figure 25 Authentication and key agreement of UMTS subscribers In case of a GSM BSS. XRES*i are all 4 octets long and XRES* = XRES*1 || XRES*2 || XRES*3 || XRES*4. 28 shows the different scenarios that can occur with GSM subscribers using either R98. In the latter case the GSM cipher key Kc is not sent to the GSM BSS. In case of a UTRAN. RES GSM BSS RAND. both R99+ entities. IK → Kc RES → SRES Triplets VLR/SGSN Release 99+ CK. [AUTN]. 24 . IK → Kc UMTS AKA non-capable ME Kc CK.

the R99+ VLR/SGSN derives the UMTS cipher/integrity keys from the GSM cipher key using the following conversion functions: c4: CK[UMTS] = Kc || Kc c5: IK[UMTS] = Kc1 ⊕ Kc2 || Kc || Kc1 ⊕ Kc2 Kci are both 32 bits long and Kc = Kc1 || Kc2 Figure 28 Conversion functions CS handover (UTRAN to GERAN) If ciphering has been started when an intersystem handover occurs from UTRAN to GSM BSS. At the network side the MSC/VLR derives the GSM cipher key Kc from the UMTS cipher/integrity keys CK and IK used before the intersystem handover 25 . IK CK. the necessary information (e.g. SRES RAND. The intersystem handover will imply a change of ciphering algorithm from a UEA to a GSM A5. The integrity protection of signalling messages is stopped at handover to GSM BSS. SRES R99+ UE Kc Kc Kc R98. Kc. SRES RAND. SRES GSM BSS RAND. IK [Kc] [Kc] Release 98- VLR/SGSN [Kc] UTRAN RAND.UE Kc SIM GSM security Fig 27 Authentication and key agreement for GSM subscribers When the user is attached to a UTRAN.UMTS Security Leliwa Technical Bulletin Release 98. and to continue the communication in ciphered mode.or Release 99+ HLR/AuC Triplets Triplets VLR/SGSN Release 99+ Kc → CK. The GSM BSS includes the selected GSM ciphering mode in the handover command message sent to the MS via the RNC.UE R99+ or R98. supported/allowed GSM ciphering algorithms) is transmitted within the system infrastructure before the actual handover is executed to enable the communication to proceed from the old RNC to the new GSM BSS.

IK → Kc BSC A5/x CK. IK → Kc MSC UMTS security context UEA RNC GSM A5 BSC A5/x Kc MSC GSM security context UEA RNC Figure 29 CS handover (UTRAN to GSM BSS) The conversion is only needed if before the handover the UMTS security context was established (USIM in the ME).g. the ME applies the UMTS cipher/integrity keys CK and IK from the key set which was used before the intersystem handover. 26 . GSM A5 CK. the ME applies the derived GSM cipher key Kc from the key set which was used before the intersystem handover. CK. START value information. IK. At the user side. the UMTS cipher/integrity keys CK and IK from the key set used before the intersystem handover. supported/allowed UMTS algorithms) is transmitted within the system infrastructure before the actual handover is executed to enable the communication to proceed from the old GSM BSS to the new RNC. CS handover (GERAN to UTRAN) If ciphering has been started when an intersystem handover occurs from GSM BSS to UTRAN. At the network side. the necessary information (e. At the user side. the MSC/VLR derives. and to continue the communication in ciphered mode. The integrity protection of signalling messages is started immediately after the intersystem handover from GSM BSS to UTRAN is completed. The conversion is not needed in case when before the handover the GSM security context was established (SIM in the ME).Leliwa Technical Bulletin UMTS Security (using the conversion function c3) and sends Kc to the target BSC (which forwards it to the BTS). The intersystem handover will imply a change of ciphering algorithm from a GSM A5 to a UEA.

IK RNC Kc → CK. PS system change (UTRAN to GERAN) In case of an intersystem change to a GSM BSS. the SGSN derives the GSM cipher key Kc from the UMTS cipher/integrity keys CK and IK agreed during the latest AKA procedure and applies it.g. IK MSC GSM security context GSM A5 BSC UEA RNC CK. the ME applies the derived GSM cipher key Kc received from the USIM/SIM during the latest AKA procedure. IK MSC UMTS security context GSM A5 BSC Figure 30 CS handover (GSM BSS to UTRAN) The conversion is only needed if before the handover the GSM security context was established (e.UMTS Security Leliwa Technical Bulletin UEA Kc → CK. SIM in the ME). The conversion is not needed in case when before the handover the UMTS security context was established (USIM in the ME). At the user side. 27 .

At the user side. PS system change (GERAN to UTRAN) UMTS security context In case of an intersystem change to a UTRAN.Leliwa Technical Bulletin UMTS Security GEA CK. the ME applies the UMTS cipher/integrity keys CK and IK received from the USIM during the latest UMTS AKA procedure. in both cases. UEA RNC CK. the SGSN. the UMTS cipher/integrity keys CK and IK agreed during the latest UMTS AKA procedure are sent to the target RNC. IK → Kc RNC GEA BSC SGSN GSM security context UEA RNC Figure 31 PS system change (UTRAN to GSM BSS) The conversion is only needed if before the handover the UMTS security context was established (USIM in the ME). IK → Kc BSC SGSN UMTS security context UEA CK. The conversion is not needed in case when before the handover the GSM security context was established (SIM in the ME). IK SGSN UMTS security context GEA BSC Figure 32 PS system change (GERAN to UTRAN) – UMTS security context 28 .

the SGSN derives UMTS cipher/integrity keys CK and IK from the GSM cipher key Kc (using the conversion functions c4 and c5) agreed during the latest GSM AKA procedure and sends them to the target RNC. IK RNC Kc → CK. three cases are distinguished: a) In case of an intersystem change to a UTRAN controlled by the same SGSN. As result. in case of intersystem change to a UTRAN controlled by another R99+ SGSN.SGSN. IK SGSN GSM security context GEA BSC SIM Figure 34 PS system change (GERAN to UTRAN) – GSM security context for GSM subscriber (same SGSN) 29 . UEA Kc → CK. HLR/AuC SGSN UMTS AKA UEA RNC GSM security context R99+ USIM GEA Kc BSC SGSN R98 Figure 33 PS system change (GERAN to UTRAN) – GSM security context for UMTS subscriber Established for a GSM subscriber At the network side. The new SGSN becomes the new anchor point for the service.UMTS Security Leliwa Technical Bulletin GSM security context Established for a UMTS subscriber A GSM security context for a UMTS subscriber is established in case the user has a R99+ ME but the SGSN is R98. Since the new R99+ SGSN has no indication of whether the subscriber is GSM or UMTS. A UMTS security context using fresh quintets is then established between the R99+ SGSN and the USIM. a R99+ SGSN shall perform a new UMTS AKA when receiving Kc from a R98. the initial R98SGSN sends the GSM Kc agreed during the latest GSM AKA procedure to the new SGSN controlling the target RNC.

HLR/AuC GSM AKA UEA Kc → CK. the ME derives the UMTS cipher/integrity keys CK and IK from the GSM cipher key Kc (using the conversion functions c4 and c5) received from the SIM during the latest GSM AKA procedure and 30 .Leliwa Technical Bulletin UMTS Security b) In case of an intersystem change from a R99+ SGSN to a UTRAN controlled by another SGSN.SGSN to a UTRAN controlled by another SGSN. The new SGSN stores the GSM cipher key Kc and derives the UMTS cipher/integrity keys CK and IK which are then forwarded to the target RNC. the initial SGSN sends the GSM Kc agreed during the latest GSM AKA procedure to the (new) SGSN controlling the target RNC. the initial SGSN sends the GSM cipher key Kc agreed during the latest GSM AKA procedure to the (new) SGSN controlling the target RNC.to another SGSN) At the user side. IK Kc RNC SGSN GSM security context SIM GEA BSC SGSN R99+ Figure 35 PS system change (GERAN to UTRAN) – GSM security context for GSM subscriber (SGSN R99+ to another SGSN) c) In case of an intersystem change from an R98. IK RNC SGSN Kc GSM security context SIM GEA BSC SGSN R98- Figure 36 PS system change (GERAN to UTRAN) – GSM security context for GSM subscriber (SGSN R98. To ensure use of UMTS keys for a possible UMTS subscriber (superfluous in this case). The new SGSN becomes the new anchor point for the service. The new SGSN becomes the new anchor point for the service. a R99+ SGSN will perform a new AKA when a R99+ ME is coming from a R98-SGSN. in all cases. Kc → CK. IK UEA Kc → CK.

In case c) these keys will be over-written with a new CK. 31 .UMTS Security Leliwa Technical Bulletin applies them. IK pair due to the new AKA.

First Out GSM/EDGE Radio Access Network General Packet Radio Service Global System for Mobile Communications Home Environment Home Location Register Integrity Protection Key International Mobile Subscriber Identity Location Area / Link Adaptation Location Area Identity Media Access Control / Message Authentication Code Message Authentication Code for Integrity Mobile Equipment Mobile Station Packet Switching / Presence Service Packet TMSI Routing Area Routing Area Identity Radio Access Network RAN Application Part Random Number authentication RESponse Radio Link Control 32 .Leliwa Technical Bulletin UMTS Security Acronyms and Abbreviations 3G AK AKA AMF AUC AUTN AUTS AV BSC BSS BTS CK CKSN CN CS FIFO GERAN GPRS GSM HE HLR IK IMSI LA LAI MAC MACMAC-I ME MS PS P-TMSI RA RAI RAN RANAP RAND RES RLC Third Generation Anonymity Key Authentication and Key Agreement Authentication Management Field Authentication Centre AUthentication TokeN Automatic Update Transaction System Authentication Vector Base Station Controller Base Station System Base Transceiver Station Ciphering Key Ciphering Key Sequence Number Core Network Circuit Switching / Convergence Sublayer / Coding Scheme First In.

UMTS Security Leliwa Technical Bulletin RNC RRC SEQ SGSN SIM SN SQN SRNC TMSI UEA UMTS USIM UTRAN VLR XRES Radio Network Controller Radio Resource Control Sequence Number Serving GPRS Support Node Subscriber Identity Module Serving Network / Subscriber Number SeQuence Number Serving Radio Network Controller Temporary Mobile Subscriber Identity User Encryption Algorithm Universal Mobile Telecommunication System UMTS Subscriber Identity Module UMTS Terrestrial Radio Access network Visitor Location Register eXpected RESponse 33 .

Stage 3 34 .321 Medium Access Control (MAC) protocol specification [4] 25.Leliwa Technical Bulletin UMTS Security References This section contains the locations of various specifications.331 Radio Resource Control (RRC). Security architecture [2] 25. Protocol specification [3] 25.413 UTRAN Iu interface Radio Access Network Application Part (RANAP) signalling [6] 24.102 3G security. document references and useful information where you can learn more about this subject.322 Radio Link Control (RLC) protocol specification [5] 25. [1] 33.301 Non-Access-Stratum (NAS) protocol for Evolved Packet System (EPS).

leliwa. please send a blank e-mail with Subject="Update_request" to bulletins@leliwa.leliwa.6561° telephone: +48 32 376 63 05 fax: +48 32 376 63 07 Skype: leliwa_poland email: info@leliwa. You can store it on any servers and make it available for public download. you can download more Leliwa Technical Bulletins from the following address: http://www.com Leliwa Telecom AB Orrpelsvägen 66 SE-167 66 BROMMA Sweden GPS: N59. Leliwa assumes no responsibility for any errors that may appear in this document.3260°. This document may be freely redistributed. Information in this document is subject to change without notice. E17.com 35 . E018. In such case it must be clearly indicated that it comes from Leliwa website www.com?subject=Update_request Leliwa Sp.122 PL-44-100 Gliwice Poland GPS: N50.com/downloads If you want to be informed when the new bulletins are uploaded. z o.9464° telephone: +46 8 4459430 email: info@leliwa.com If you received only this file.com or click this link: mailto:bulletins@leliwa.2981°. Plebiscytowa 1.UMTS Security Leliwa Technical Bulletin Disclaimer This document is based on Leliwa training materials.o.