1. All Rights Reserved © Alcatel-Lucent 2006, ##### 1 | Presentation Title | Month 2006 Oct 8, 2007 Sarvar Patel – Alcatel-Lucent ABSTRACT: Improving random number based replay protection mechanism for 2G RUIM Based authentication protocol. RECOMMENDATION: Review and approve. Notice: Contributors grant a free, irrevocable license to 3GPP2 and its Organization Partners to incorporate text or other copyrightable material contained in the contribution and any modifications thereof in the creation of 3GPP2 publications; to copyright and sell in Organizational Partner’s name any Organizational Partner’s standards publication even though it may include portions of the contribution; and at the Organization Partner’s sole discretion to permit others to reproduce in whole or in part such contributions or the resulting Organizational Partner’s standards publication. Contributors are also willing to grant licenses under such contributor copyrights to third parties on reasonable, non-discriminatory terms and conditions for purpose of practicing an Organizational Partner’s standard which incorporates this contribution. This document has been prepared by the contributors to assist the development of specifications by 3GPP2. It is proposed to the Committee as a basis for discussion and is not to be construed as a binding proposal on the contributors. Contributors specifically reserve the right to amend or modify the material contained herein and nothing herein shall be construed as conferring or offering licenses or rights with respect to any intellectual property of the contributors other than provided in the copyright statement above. Random Number Based Replay Protection Mechanism Improvement 3GPP2 TSG-S WG4

2. All Rights Reserved © Alcatel-Lucent 2006, ##### 2 | Presentation Title | Month 2006 Random number based QC proposal is an example of random based SQN:  We propose enhancements to the QC proposal  To address certain security concerns  Also we add new security protection measures that become possible with use of a random based SQN. First concern: QC proposal states that f2,f3,f4 functions are used to create RES,CK and IK.  This is not correct since need a keyed cryptographic function to accept both 128 bits of RANDAKA and HSS_AUTS*/MS_AUTS*.  Standard f2,f3,f4 AKA functions only take one 128 bit input beyond the key.

3. All Rights Reserved © Alcatel-Lucent 2006, ##### 3 | Presentation Title | Month 2006 Second concern: We show two entity authentication attacks that are better than 64 bits.  This shouldn’t happen in a secure protocol and we would like to address this.

4. All Rights Reserved © Alcatel-Lucent 2006, ##### 4 | Presentation Title | Month 2006 First attack (better than 64 bit). Repeat old network challenge  After a resync has happened and RANDM (i.e. RAND sent by ME) has changed.  Old MS_Verify in old challenge will be same as the ME expected MS_verify with probability 2 -48.  SQN value of old challenge can often be larger than currently expected by ME. –This can happen because with each resync the SQN resets unlike with standard AKA. For example current SQN is 0, but old challenge SQN is 2.  Thus old AUTN will be accepted with probability 2 -48  This happens with just one attempt.  A 64 bit security protocol should not allow this. Success probability of one attempt should be 2 -64 and not 2 -48. –Later use of CK and IK may catch this, but their use need not be mandatory in general setting. –Even if they are used later, a secure protocol should not allow entity authentication to pass with prob better than 2 -64.  This weakness is not dependent on any weakness due to CDMA authentication.

5. All Rights Reserved © Alcatel-Lucent 2006, ##### 5 | Presentation Title | Month 2006 Second attack (better than 64 bits) Let network legitimately create around 2 24 challenges  For some two i-th and j-th challenges, the MS_verify will be equal  This is due to the birthday paradox.  At the j-th challenge, the attacker sends the old i-th challenge.  The old challenge AUTN will be legitimately accepted since the MAC is valid and the MS_verify matches and assume SQN is in range (due to some resync SQN resets).  Furthermore, one can get an extra challenge to be accepted by ME.  Suppose SQN of i-th challenge is greater than j-th challenge  First send legitimate j-th challenge as is.  Second, repeat the old i-th challenge. –This will be accepted because MAC is valid, MS_verify matches and SQN is in range. This weakness is not dependent on CDMA weakness (e.g. small RANDU, etc).

6. All Rights Reserved © Alcatel-Lucent 2006, ##### 6 | Presentation Title | Month 2006 Lack of Secure key agreement in all proposals. All proposals, whether random, time or hardwareID based, are not truly secure session key agreement protocols.  Compromise of any past SMEKEY/PLCM renders the proposals insecure.  Past keys may have been compromised during network transfer, storage, cryptanalysis, etc.  Also a rogue shell may collect some RAND/SMEKEY/PLCMs for future attacks. Key agreement protocols should be secure against both passive and active attacks.  In particular, compromise of some past session keys or key material should not cause a weakness in future key agreements.  Ideally, even compromise of all past session keys should not result in any weakness of future key agreements.  It is sufficient that only the root key (e.g. SSD) is not compromised to carry on a secure session key agreement. Explicit mutual entity authentication may be added to the key agreement.

7. All Rights Reserved © Alcatel-Lucent 2006, ##### 7 | Presentation Title | Month 2006 Creating a better random based protocol Security of new protocol should be 64 bits.  Even if some parts (e.g. RAND) of CDMA have lower security, the new protocol should not introduce the weakness. –Some CDMA weakness cannot be circumvented (e.g. if most of KEYS associated with RANDs are compromised). Mutually authenticated secure key agreement protocol  Secure even if some past CDMA keys compromised before last resync.  Ideally we would have wanted to tolerate any key compromise. Protection against rogue shells  A rogue shell which collects some CDMA key values should not be able to use them in a future attack. Use standard AKA functions  Create AKA key then only use standard AKA functions.

8. All Rights Reserved © Alcatel-Lucent 2006, ##### 8 | Presentation Title | Month 2006 Main ideas: ME creates a large enough random value, RANDM, at UIM insertion.  72 bit RANDM will suffice to protect against birthday and other attacks.  Complete RANDM is sent in the challenge from the network.  if received RANDM ≠ stored RANDM ME then ME initiates resync with RANDM ME, but does not have to generate a new RANDM. Use RANDM to create secure session key agreement  ME and HSS use part of RANDM as a CAVE RAND to create KEYS M =SMEKEY M,PLCM M. –KEYS N = SMEKEY N,PLCM N created as before using CAVE_RAND part of AKA_RAND.  AKA_KEY is based on both sets of keys: H(KEYS M,KEYS N ). –AUTHR M for RANDM is sent masked by ME in the resync message so that HSS can send RANDM/AUTHR M pair to HLR/AC and get KEYS M  Use 52 bits of RANDM for cave rand (32 bits) and 6 dialed digits (20 bits). –6 dial digits used in AUTHR,KEYS calculation in call origination type access –Actually 6 random digits are created and encoded into 20 bits. Use 16 bit incrementing SQN

9. All Rights Reserved © Alcatel-Lucent 2006, ##### 9 | Presentation Title | Month 2006 Authentication Vector generation in HSS (Figure 1) RANDM: 72 random bits generated by ME and stored at HSS: SQN, AMF and AKA_RAND set to the following: AKA_KEY=H(KEYS M,KEYS N ) –Where KEYS M gotten from HLR/AC during resync –Where KEYS N gotten from HLR/AC, as with baseline text, using RANDU from AKA_RAND. AMF (16 bits) AKA_RAND (128 bits) RANDM HSS 103 random bits RANDU (24 bits) HSS random bits (79 bits) SQN HSS (16 bits) RANDM HSS R ( 1 bit) CAVE RAND (32 bits) 6 call digits (20 bits) random (20 bits) SQN (48 bits) RANDM (72 bits)

10. All Rights Reserved © Alcatel-Lucent 2006, ##### 10 | Presentation Title | Month 2006 UIM insertion New UIM insertion into ME  ME randomly generates and stores 72 bit RANDM ME and sets SQN ME to 0;  this is also done when ME has no RANDM ME value set.  Or receives notification from HSS to regenerate via the setting of R bit. –UIM accepts R bit only if the challenge has RANDM ME and proper SQN.  Or SQN ME is reaching the limit.  At next authentication attempt, ME sends resync message with new RANDM ME  HSS verifies the resync message,  The HSS will replace the stored RANDM HSS value for the user with the received RANDM.  Also the HSS will set SQN HSS to 0.

11. All Rights Reserved © Alcatel-Lucent 2006, ##### 11 | Presentation Title | Month 2006 Authentication processing (Figure 2) ME HSS 1.AKA_RAND, AUTN 2.X MAC ==MAC? No Authentication failure Is (RANDM,SQN) In range? Yes 3.RANDM ME ==RANDM? No Resync with SQNMACS (22 bits) Resync with SQNMAC-S (64 bits) 4.SQN ME < SQN? No 5. RES RANDM ME SQN ME (16 bit) AUTHR M ⊕ MACS (18 bits) Yes RANDM ME (24 bits) 00…0 (32 bits) (48 bits)

12. All Rights Reserved © Alcatel-Lucent 2006, ##### 12 | Presentation Title | Month 2006 Notes: Authentication processing (I) 1.HSS forms and sends AKA_RAND, AUTN challenge - creates RANDU and gets KEYS N as in baseline text; creates HSS random bits also. - retreives RANDM HSS,KEYS M which were created and stored at last resync. If RANDM HSS has no value then create a RANDU based Cave RAND and place it in the CAVE_RAND part of RAND HSS. set ‘other’ bits randomly and set ‘Dialed digit’ bits to be all ones †. Also get KEYS M from HLR. With overwhelming probability, this will not match RANDM ME and cause resync. - creates AKA_key=H(KEYS M,KEYS N ) - increment SQN HSS and form MAC using f1 on 48bit_SQN/AMF/AKA_RAND; 2.ME Verifies MAC - extract RANDU from AKA_RAND, add MIN1 and get KEYS N from UIM. - extract RANDM; Lookup KEYS M if stored; Else calculate by setting 20 lsb as 6 dialed digits, next 32 lsb as cave rand, and give to UIM and get AUTHR M,KEYS M. - create AKA_key=H(KEYS M,KEYS N ) - calculate XMAC and verify if equal to MAC. - If MAC match fails then send authentication failure message, else goto 3. † All ones does not represent any valid 6 digits and tells the ME to treat this as a RANDU based CAVE_RAND.

13. All Rights Reserved © Alcatel-Lucent 2006, ##### 13 | Presentation Title | Month 2006 Notes: Authentication processing (II) 3a. ME sends resync with RANDM ME (if received RAND M different from RANDM ME ). - AKA_KEY=H(KEYS M,KEYS N ), based on received challenge. - MACS calculated using AKA_KEY, AKA_RAND, RANDM using f1* - place RANDM in 48bit_SQN, AMF and 8 msb of AKA_RAND. - ME sends 72 bit RANDM ME in 48bit_SQN and the rest of 24 bits in msb of MACS. - 18 bit AUTHR M is XORed with next 18 bits of MACS (see Fig 2). 3b. HSS receives resync with RANDM. - At HSS, use AKA_KEY=H(KEYS M,KEYS N ) stored from last challenge; - Unmodified AKA_RAND is sent along to the network; - Form MACS using AKA_KEY, RANDM, AKA_RAND using f1* as in 3a. - Verify 22 lsbs of MACS. Extract AUTHR M by XORing with next 18 bits of MACS. - send CAVE_RAND M /call Digits/AUTHR M to HLR/AC to verify & get KEYS M - If AUTHR M verifies then implicitly so do the 18 bits of MACS (i.e total of 40 bits). - If RANDM HSS is different then received RANDM then set RANDM HSS =RANDM and set SQN HSS to 0;

14. All Rights Reserved © Alcatel-Lucent 2006, ##### 14 | Presentation Title | Month 2006 Notes: Authentication processing (III). 4a. ME sends resync with SQN ME - if received SQN is not in range - SQN in range if SQN ME < SQN < SQN ME + Δ - Set 32 msb of 48bit_SQN to be zeroes † and set 16 lsbs to SQN ME (see Fig 2). - AKA_KEY=H(KEYS M,KEYS N ), based on received challenge. - MACS calculated using AKA_KEY, unmodified AKA_RAND, 48bit_SQN using f1*. 4b. HSS receives resync with SQN ME - Use AKA_KEY stored from last challenge; AKA_RAND was sent along to HSS. - MACS calculated as in 4a. - Since 32 msbs of 48bit_SQN are all zeroes, HSS knows the resync carries SQN ME. - Verify 64 bit MACS and then set SQN HSS to received 16 bit SQN. 5. ME sends RES - Calculate RES using f2 on AKA_RAND and using AKA_KEY created in 2 above. - Also calculate CK and IK using f3 and f4. † When ME generates RANDM it excludes values with 32 leading bits as zeroes.

15. All Rights Reserved © Alcatel-Lucent 2006, ##### 15 | Presentation Title | Month 2006 Security guarantees We expect at best 64 bits of security  Even 3G AKA has only 64 bits security because MAC is 64 bits. –ME can be made to accept a challenge by guessing the MAC with prob 2 -64. –ME can be made to accept old CK, IK by repeating old RAND with fresh SQN and a correct guess at the MAC.  64 bit CDMA keys: Akey,SSDA,SSDB,SMEKEY; RANDU,RAND length is even smaller  With q attempts security guarantees goes down to q/2 64. Worst case number of resyncs and access attempts (i.e. q) in life of ME.  We make reasonable assumptions about the worst case number of access attempt and UIM insertions in the life of the ME  Assume 2 24 or 16M attempts; this is equal to assuming one attempt per 20 seconds continuously for 10 years.  Assume 2 16 insertions; equal to assuming around 18 UIM insertions/day for 10 years  3G AKA security in worst case is 2 24 /2 64 or 2 -40 at the end life of the phone under these assumptions.  Thus we want our protocol to have 2 40 security at end of ME’s life!

16. All Rights Reserved © Alcatel-Lucent 2006, ##### 16 | Presentation Title | Month 2006 Birthday attacks AKA_RAND repeating:  Handset impersonators can replay only if RANDAKA repeats  But this happens (using birthday arguments) only with prob < (2 24 ) 2 /2 103 = 2 -55 which is better than 2 -40 as expected with 64 bits of security and 2 24 tries.  Thus we need to focus on attacks by network impersonators. RANDM repeating:  At the end of life the ME experiences 2 16 UIM insertions and similar number of RANDM generations.  Probability of RANDM repeating is then < (2 16 ) 2 /2 72 or 2 -40.  This is the same security guarantees we expect from an ME in its life assuming 64 bit security at the start. Resync attacks:  Generally not possible to cause RANDM regeneration by causing resync.  Thus attacks not effective: e.g. replaying old challenge causes resync but no new RANDM generation.

17. All Rights Reserved © Alcatel-Lucent 2006, ##### 17 | Presentation Title | Month 2006 Tolerant to past SMEKEY compromises Protocol can tolerate revelation of some CDMA KEYS  This could be due to revelation of past used KEYS  Or a rogue shell collects some KEYS from the R-UIM.  This is a major improvement over past protocols.  Where a compromise of even one key would render the protocols insecure.  Each side generates CAVE challenges and AKA_KEY based on both CAVE KEYS.  Thus knowing one or few CDMA KEYS no longer useful.  Compromise of all or most keys associated with RAND/RANDU still problematic.  The ME only creates fresh challenge typically during UIM insertions  For further protection, a network may decide to do more frequent RANDM re- generations (e.g. once a day, week, month, etc).  The R bit mechanism gives the network the flexibility to control the tradeoffs.

18. All Rights Reserved © Alcatel-Lucent 2006, ##### 18 | Presentation Title | Month 2006 Conclusion Protocol is simpler and more secure due to the enhancments  It addresses the security concerns with existing proposals  64 bit security guarantees.  Simpler to analyze.  Enhancement make it truly a secure session key agreement because of mutual CAVE challenges.  Enhancement also protect against rogue shell attacks. The protocol is useful for UMB CAN also.  Although we have presented protocol using HSS terminology the protocol is as useful for UMB. HSS terminology should be replaced by EAP server.

19. All Rights Reserved © Alcatel-Lucent 2006, ##### 19 | Presentation Title | Month 2006 Backup Slides

20. All Rights Reserved © Alcatel-Lucent 2006, ##### 20 | Presentation Title | Month 2006 Guessing attacks on MACS All proposals send reduced length MACS values –We send 40 or 64 bits, others send 48 bits instead of full 64 bits. No security reduction due to MACS length reduction:  Suppose attacker guesses correctly the MACS value and causes HSS to set either RANDM HSS or SQN HSS to an older value. What damage can this cause? Not much:  Next time suppose HSS uses RANDMold HSS, SQNold HSS. If a legitimate ME talks with the network then it will see that values are out of range and will cause a resync.  If a handset impersonator talks to the network, he cannot form a RES or do anything because the HSS will use a large, fresh AKA_RAND value to challenge the handset; Thus there are no security implications either way.  Also HSS can crash and may begin the SQN value at an initial value (e.g. zero) which would be a repeat. Since this can happen without any attacker, it is clear that changing the SQN value at the HSS whether accidently or maliciously by an attacker is of no security consequence. –The only thing is that the MACS value should be large enough to minimize bogus resyncs. But even with a size as small as 24 bits, it would take an attacker 2 24 or millions of attempts before attacker can change the RANDM, SQN value in the HSS and the only result is to cause a resync.

21. All Rights Reserved © Alcatel-Lucent 2006, ##### 21 | Presentation Title | Month 2006 Guessing Attacks on MACS and anonymity In the resync we can optionally hide RANDM (from passive attacks)  Use AKA key of last challenge  Create AK*: this can be used to cover only 48 (e.g. lsb) bits of RANDM. –Can use H(AK*) to cover entire 72 bit RANDM.  Guessing attacks on MACS more difficult: –Suppose an attacker is trying to get the HSS to accept a specific RANDM. –Previously, he only had to guess MACS. –Now he needs to also guess AK* or else a different RANDM will be accepted at HSS. Thus effective security of MACS has gone up. In the challenge, the HSS can hide RANDM and SQN  Create AK: –AKA key cannot be based on RANDM since we are trying to hide RANDM –AKA key = H(KEY N ) –Calculate AK using f5 AKA_KEY (AKA_RAND) –Since AK is only 48 bits, H(AK) can be used to hide SQN and RANDM