1 / 9

Replay protection for CAVE based AKA when moving R-UIM between mobiles

Replay protection for CAVE based AKA when moving R-UIM between mobiles. High level of proposal. At re-synchronization, a mobile generates a 64 bit random number that is sent to network.

odessa
Download Presentation

Replay protection for CAVE based AKA when moving R-UIM between mobiles

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

E N D

Presentation Transcript

  1. Replay protection for CAVE based AKA when moving R-UIM between mobiles

  2. High level of proposal • At re-synchronization, a mobile generates a 64 bit random number that is sent to network. • When forming challenge the network must use this number and also include a sequence number (16 bits) to ensure no replays with the mobiles random number • Mobile can check correct random number was used to form challenge and challenge has not been seen before by checking sequence number

  3. Solution – Storage Requirements • HSS store the following for each mobile: • HSS_AUTS* (128 bits) • latest successfully received re-synchronization • HSS_SQN (16 bits) • Replay counter for use of HSS_AUTS* in forming challenges • AKA_KEY • The key used in last challenge in case of re-synchronizations • MS stores the following • MS_AUTS* (128 bits) • Latest sent re-synchronization • MS_SQN (16 bits) • The largest successfully received sequence value for the current MS_AUTS*

  4. Solution – Initialization • If HSS has no values stored for the particular R-UIM, it generates random values for its unknown parameters and forms the challenge. • If mobile has no stored values for the current UIM, then it checks MAC and if successful it performs a resynchronization.

  5. Solution – Resynchronization • For resynchronization procedure, mobile does the following: • Generates a 64 bit random number RAND • Calculates 64 bit MAC using AKA_KEY, AKA_RAND and RAND • Note: could use standardized AKA function here for MAC calculation by using RAND to populate AMF and SQN field • Forms AUTS = RAND | MAC and send to network • Note: here AUTS is 128 bits whereas normally it is only 96 bits. If this is an issue, just the leading bits can be sent but all the bits should be stored and used at both ends. • Sets MS_AUTS* = AUTS and MS_SQN = 0 • HSS checks AUTS as follows: • Uses stored AKA_KEY to check MAC • AKA_RAND is returned to HSS along with AUTS • If successful sets HSS_AUTS* = AUTS and HSS_SQN = 0

  6. Solution – Forming Challenge • Network generates challenge as follows • AKA_KEY calculated from CAVE parameters • AKA_RAND = CAVE_RAND (32 bits) | HSS_RAND (96 bits) • AUTN = MS_VERIFY (48 bits) | HSS_SQN (16 bits) | MAC (64 bits) • MS_VERIFY = prf (HSS_AUTS*, AKA_RAND) • Increase HSS_SQN by 1 • Calculate 64 bit MAC using AKA_KEY to cover AKA_RAND, MS_VERIFY and SQN • Note: this can use normal AKA MAC function by setting AMF and SQN from MS_VERIFY and HSS_SQN. • Calculate XRES, CK and IK from TEMP_AKA_KEY, AKA_RAND and HSS_AUTS* • This is the one deviation from the normal AKA functions in that CK etc are made dependent on the HSS_AUTS* as well. This means the CK and IK are dependent on information from a particular mobile.

  7. Solution – Checking Challenge • Mobile checks the challenge as follows: • Mobile gets CAVE_RAND from AKA_RAND • Mobile sends CAVE_RAND to UIM to get AUTHR, SMEKEY etc • Mobile calculates AKA_KEY • Mobile checks MAC • MAC failure result in network authentication failure • Mobile checks MS_VERIFY = prf( MS_AUTS*, AKA RAND) and MS_SQN <SQN<=MS_SQN+4 • Failure here leads to resynchronization error (also done if no stored MS_AUTS* and MS_SQN for this UIM or MS_SQN is getting to limit) • Note: +4 for range is only example and could be different • Mobile sets MS_SQN to SQN • Mobile calculates RES, CK and IK from AKA_KEY, AKA_RAND and MS_AUTS*

  8. Attacking proposal • Generate new challenge • Must get 64-bit MAC correct • Replay old challenge randomly • 48 bit MS_VERIFY and SQN must be correct • But then IK dependent on 128-bit MS_AUTS* which includes 64 bits from mobile • Hence probability it work is less than 2^64 • Forces re-synchronizations to get repeated random from mobile • At best birthday paradox, i.e. 2^32, but • MS_AUTS* (and hence MS_VERIFY and IK) depends on challenge sent so even if mobile reselects same random there is 1 in 2^64 chance that MS_AUTS* will be the same unless responding to same challenge as original. In latter case only actual random number from mobile will work. • Hence approx 2^64

  9. Attacking Proposal (cont) • DoS Attack • Attacker replays old challenge to force re-synchronization attempt at mobile to change it stored MS_AUTS* • If considered serious, MS can store TEMP_MS_AUTS* in addition to other data until this is successfully used • Anonymity • No privacy protection currently in IMS, but could use AK and AK* to protect privacy (in terms of analysing challenge) from passive attackers if needed

More Related