F.5 Actions in case of compromise of a local HSS

33.4013GPP3GPP System Architecture Evolution (SAE)Release 17Security architectureTS

In case of a compromise of one local HSS, other local HSSs are not affected (because they have a different set of secrets and it is assumed that an attacker knowing K_n cannot use this information to retrieve the corresponding IOPS master subscriber key). Furthermore, there is no need for swapping all USIMs, only the compromised local HSS (or the local HSSs in the subclass sharing the same subscriber key, cf. NOTE above) needs to be newly provisioned with keys derived from the MK and a newly provisioned value in the table of the IOPS dedicated USIM.

Action can, of course, only be taken, after the compromise of a local HSS was detected. But even before detection of the compromise, the subscriber key separation mechanism ensures that the attacker can neither use the compromised key K_n to impersonate the subscriber towards another local IOPS network nor impersonate another local IOPS network towards the subscriber. Therefore, the mechanism is useful even before new provisioning has taken place. But the attacker can impersonate the local IOPS network towards the subscriber until revocation has taken place.

NOTE 1: Sequence number handling: One of the tasks of a USIM application is handling sequence numbers for the AKA protocol (cf. TS 33.401, which refers to TS 33.102 for this purpose). Often, an array is used as specified in TS 33.102, Annex C. The USIM dedicated exclusively for IOPS may use the same array for all keys K_n and increase a sequence number as if the authentication challenge came from a single HSS (instead of from several local HSSs as in the present use case). Protection against replay of challenges continues to be guaranteed as the USIM then records all sequence numbers sent by any of the local HSSs that have been successfully used.

NOTE 2: Re-synchronisation: When a UE moves from one local HSS to the next one, it could happen that the second local HSS generates authentication vectors with a sequence number that is too low as seen from the USIM with the added functions. This would then result in a re-synchronisation procedure that would be successful as the AUTS parameter in the re-synchronisation procedure causes the local HSS to update its sequence number and consequently generate an authentication vector that will be accepted by the USIM. This would then result in a successful Attach procedure, albeit at the expense of some added delay. If the delay is a concern and re-synchronisation procedures may be frequent due to frequent movements of UEs between local HSSs then this problem could be almost completely solved by using the IND value of the sequence number, cf. Annex C of TS 33.102 [4], to distinguish among local HSSs, i.e. set up the local HSSs such that they use only particular IND.

Annex G (normative):
LTE – WLAN aggregation