1 / 12

Replay protection in AKA with 2G RUIM

Replay protection in AKA with 2G RUIM. Sarvar Patel and Zhibi Wang. Problem. No secure or synchronized time available between MEs and network. Cannot use random challenges from both sides for mutual authentication and key generation

sari
Download Presentation

Replay protection in AKA with 2G RUIM

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 in AKA with 2G RUIM Sarvar Patel and Zhibi Wang

  2. Problem • No secure or synchronized time available between MEs and network. • Cannot use random challenges from both sides for mutual authentication and key generation • Because http aka digest qop option is not mandatory and not generally depolyed. • Intermediary SPCCF(?) cannot change and only does http aka digest without qop. • ME and HSS can do special things for 2G RUIM • Goal is to have a secure AKA even when RUIM moves to different MEs.

  3. Assumptions • ME has non-volatile memory to store a sequence number.

  4. Extented Sequence number (ESQN) • Normal SQN in AKA is non-repeating value for each local UIM. • We will create a globally non-repeating SQN (i.e ESQN) for all MEs in the RUIM case. • ESQN  ‘Hardware ID of ME’ | SQN • ‘Hardware ID of ME’  56 bits IMEI/MEID / ESN • ESQN is different for each ME and for each ME, its increment for each system access, just like in normal AKA. • Thus it doesn; repeat within an ME and its different for each different ME. • ESQN is 56 + 48 = 104 bits long.

  5. General Proposal: use ESQN instead of SQN in AKA • Suppose ESQN is used instead of SQN and AKA is appropriately modified to accommodate the new size of sequence number. • Then we argue that the modified AKA would be secure from replay attacks even when RUIM changes MEs. • Modifications include using a 104 bit sequence number and modifying functions to calculate AK and MAC, MACS values. • When the ME is changed, the ME would resync the ESQN sequence number at the next AKA. • Security: • The network authenticates the UE by always issuing a fresh random challenge. • The handset authenticates the network by having the network create an authentication tag based on a previously unused sequence number. • This is true because the ESQN is globally unique and not just unique to the current ME associated with the RUIM.

  6. Problem with ESQN • Since we cannot change the sizes of sqn, we need to steal bits from other places like RAND, MACS, AMF.

  7. Counter based ESQN • For the SQN based part we can use a incrementing counter value (as oppose to time based SQN). • Problem with counter based: • Anybody with an account can update the SQN part for any ME, even to a old used value ! • A simple solution is that each ME accepts increasing SQN, but not if the jump is greater than  • Thus if someone sets the SQN to be a large value in the HSS then when this large value is sent to the ME, the ME will resync to the true value associated with its Hardware ID. • TS 33.102 has the USIM do this check also. • Generally, its okay if other people can change SQN part of ESQN in the HSS. • We can see this because its always possible that the HSS had crashed and the values are initialized to 0. • ME would resync to the correct SQN. • The use of a fresh RAND always protects the network from a replay attack. •  can be 8 for example. This will allow legitimate vectors of a batch sent to a VLR to be unused when a new batch is sent to a new VLR and the vectors are used. • Size of SQN • Suppose only 1 AKA/sec is the worst case rate and assume handset lifetime of around 15 years then we need 29 bits. If we are using the indexing mechanism for allowing interleaving of requests from different VLR then another 5 bits are needed; altogether 34 bits. • Throttling can be done to make sure that the average rate is lower than 1 per second. • Calculating MAC and MACS • MAC = f1K(ESQN || RAND || AMF) and MACS = f1*K(ESQNMS || RAND || AMF)

  8. Counter based ESQN (II) • ESQN needs to be send • From the VLR to the ME as part of RAND,AUTN • From the ME to the VLR in resync message as part of SQN, MACS pair. • The 34 bits of SQN in AUTN are used up for SQN purposes. • 14 bits of the 48 bits are available for sending the hardware ID. • Remaining 42 bits of 56 bit MEID/IMEI can be send in AMF and RAND. • AMF has 16 bits. 1 bit can be used to indicate if AMF carries hardware ID or not. Thus generally 15 bits may be available. • The remaining 27 bits can be stolen from the RAND. • Stealing from the MAC is not a good idea since security goes down directly whereas with RAND the security goes down by sqrt. • Resync • We can steal some bits from the MACS. • Security is not affected. An attacker can get the HSS to have an older SQN value, but since the network always uses a fresh RAND value, the ntwk is immume to replay attack. The legitimate ME would resync to proper SQN value anyway. • We have two options in resyncing • Resync update only hardware ID or the SQN value but not both • When SQN needs updating, no bits need to be stolen from the MACS. • A indidicator bit in the SQN is used to indicate if MEID or SQN is being updated. • If MEID is being updated then need to steal 8 bits from MACS • Resync both hardware ID and SQN value • This would require us to steal 32 bits from MACS.

  9. Time based ESQN • For the SQN part, the HSS will always use a time based value. ( as described in App C and in particular C.3.3 of TS 33.102) • Time unit of clock is .1 seconds, so no two batch request can arrive together; Array a=32 and Delta = 2^28 as in C.3.3. • We will use 47 bits for time SQN which includes 5 bits for array management. This should ensure over 65 years of operations before repeate. • Note that unlike previous time proposals: • ME is the final decider of legitimate ESQN, if the SQN is lower than SQNme then ME will send a resync message. • Each ME stores ESQN and calculates MAC and MAC-S using ESQN as described previously.

  10. Time ESQN: RAND,AUTN • HSS has the option of sending the entire hardware ID or part of it. • 48 bits of SQN are used to send the time based SQN. • If the entire 56 bit MEID is sent then we have to steal bits from the AMF and RAND. • We may have to steal upto 41 bits from RAND • Partial MEID transfer • In this case we only send some bits (e.g. 16) of hash of MEID as part of RAND. • The ME recovers the SQN and calculates the MAC value using ESQN • If it verifies AKA proceeds normally. • If there is an error, including SQN not in range, hash of MEID is incorrect, or MAC is incorrect then resync is always executed. • Also when the R-UIM is inserted the resync is always executed. • It may seem that more resyncs are being created because there is no way to tell if the MAC is wrong or if the SQN is wrong. • However, the only way for MAC to have been wrong was if there was a bit error in transmission (this is very low probability) or if an attacker is sending a bogus message. But if the attacker wanted to cause a resync, he only needs to replay a previously heard RAND, AUTN pair. Thus the attacker could have as easily cause resyncs before as can be caused in this time base ESQN with partial MEID transfer proposal. • Resync • In the resync, a single indicator bit is used to indicate if the error is in SQN part of the MEID part. • The rest of 47 bits are used to always send MEID. The remaining 9 bits of MEID are send by stealing the leading 9 bits of MACS. • Details: 55 bits of MEID/IMEI are enough if we pay attention to coding.

  11. Details of time based ESQN • Generation of sequence numbers: • ESQN is MEID || SQN where MEID is 56 bits. • In its binary representation, the sequence number consists of two concatenated parts SQN = SEQ || IND. IND is 5 bits large and used as specified in Appendix C. SEQ is 42 bits large and set to the current time starting at a fixed point example January 1st 2007. • Time unit of the clock: It has to be chosen in such a way that no two requests for a batch of authentication vectors arrive during one time unit. Value = 0.1 seconds • Length of IND in bits = 5. • Start conditions: use MEID of all zeores, this should cause a resync. SQN value is set to current time. • Verification of sequence numbers in the USIM: • This is done according to the handling of sequence numbers in the USIM specified in Annex C.2. • Length of the array: a = 32.This satisfies the requirement in section 6.3.2 that the mechanism for the verification of sequence numbers shall ensure that a sequence number can still be accepted if it is among the last x sequence numbers generated. • Protection against wrap around: Choose  = 228. • User anonymity: the value of SQN does not allow to trace the user over longer periods. Therefore, there may be no need to conceal SQN by an anonymity key as specified in section 6.3. • However, the hardware ID needs to be protected for anonymity. The AK output can be used to XOR with the hardware ID in the AMF and RAND during VLRME communications. • In the case of resync, the hardware ID is 56 bits and we need to create another 8 bits to conceal the hardware ID part that is in the MAC-S. We can use another function to create the 8 bits for concealing. • The MAC-S part is shrunk to 56 bits.

  12. Conclusion • Couple of options are available to use AKA securely without changing the intermediary NEs. • The time based ESQN proposal is simpler and requires less stealing of bits. • Hence we propose that time based ESQN be used as the working proposal.

More Related