Project

General

Profile

Bug #2745

UMTS ciphering on GSM does not work when both 2G and 3G keys are present in the HLR.

Added by dexter 4 months ago. Updated 3 months ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
-
Target version:
-
Start date:
12/13/2017
Due date:
% Done:

100%

Resolution:

Description

When populating the hlr database with 3G keys (auc_3g), then 2G authentication stops working, while 3G authentication on nano3G still works fine. When the 3G keys are removed, then 2G authentication works again. At the moment we suspect that osmo-msc trys to perform 3G authentication on 2G (specified) and fails because it does not work.

In the attached archive one finds a trace from the connection between MSC and BSC and the complete network configuration, hlr database logs and start scripts.

no_auth_when_auc_3g_is_populated.tar.gz (598 KB) dexter, 12/13/2017 04:20 PM


Related issues

Duplicated by OsmoMSC - Bug #2765: umts auth timed out on a 2G network. Rejected 12/16/2017

History

#1 Updated by neels 4 months ago

I can reproduce the error with a sysmoUSIM set to 2G=COMP128v3 3G=MILENAGE, and both 2G and 3G data available from the HLR db.

I observe two errors:

  1. We send a UMTS AUTN challenge in the authentication request, even though 2G is set to COMP128v3.
    Nevertheless, the UMTS AKA succeeds, i.e. the SIM responds with a valid extended RES.
  2. During the BSSMAP Cipher Mode Command that follows, according to wireshark, we are sending only A5/7 as permitted, while the MSC (as well as BSC) config has 'encryption a5 3' configured.
No.     Time           Length Source                Source Port Destination           Destination Port Protocol Media Port Context-ID CN-DomainIndicator Info
    316 25.032538428   158    185                               187                                    BSSAP                                             SACK DT1 (DTAP) (MM) Authentication Request 

Frame 316: 158 bytes on wire (1264 bits), 158 bytes captured (1264 bits) on interface 1
Ethernet II, Src: 00:00:00_00:00:00 (00:00:00:00:00:00), Dst: 00:00:00_00:00:00 (00:00:00:00:00:00)
Internet Protocol Version 4, Src: 127.0.0.1, Dst: 127.0.0.1
Stream Control Transmission Protocol, Src Port: 2905 (2905), Dst Port: 50788 (50788)
MTP 3 User Adaptation Layer
Signalling Connection Control Part
BSSAP
GSM A-I/F DTAP - Authentication Request
    Protocol Discriminator: Mobility Management messages (5)
        .... 0101 = Protocol discriminator: Mobility Management messages (0x5)
        0000 .... = Skip Indicator: No indication of selected PLMN (0)
    00.. .... = Sequence number: 0
    ..01 0010 = DTAP Mobility Management Message Type: Authentication Request (0x12)
    0000 .... = Spare bit(s): 0
    Ciphering Key Sequence Number
        .... 0... = Spare bit(s): 0
        .... .000 = Ciphering Key Sequence Number: 0
    Authentication Parameter RAND - UMTS challenge or GSM challenge
        RAND value: 06cf2ddd6a55e98693e55fd01f90cb6f
    Authentication Parameter AUTN (UMTS and EPS authentication challenge)
        Element ID: 0x20
        Length: 16
        AUTN value: d18b74d5ae0e00004686a93e9bcb9687
            SQN xor AK: d18b74d5ae0e
            AMF: 0000
            MAC: 4686a93e9bcb9687

No.     Time           Length Source                Source Port Destination           Destination Port Protocol Media Port Context-ID CN-DomainIndicator Info
    333 25.965076597   118    187                               185                                    BSSAP                                             DT1 (DTAP) (MM) Authentication Response 

Frame 333: 118 bytes on wire (944 bits), 118 bytes captured (944 bits) on interface 1
Ethernet II, Src: 00:00:00_00:00:00 (00:00:00:00:00:00), Dst: 00:00:00_00:00:00 (00:00:00:00:00:00)
Internet Protocol Version 4, Src: 127.0.0.1, Dst: 127.0.0.1
Stream Control Transmission Protocol, Src Port: 2905 (2905), Dst Port: 43964 (43964)
MTP 3 User Adaptation Layer
Signalling Connection Control Part
BSSAP
GSM A-I/F DTAP - Authentication Response
    Protocol Discriminator: Mobility Management messages (5)
        .... 0101 = Protocol discriminator: Mobility Management messages (0x5)
        0000 .... = Skip Indicator: No indication of selected PLMN (0)
    10.. .... = Sequence number: 2
    ..01 0100 = DTAP Mobility Management Message Type: Authentication Response (0x14)
    Authentication Response Parameter
        SRES value: 95c27877
    Authentication Response Parameter (extension) (UMTS authentication challenge only)
        Element ID: 0x21
        Length: 4
        XRES value: 98c48e56

No.     Time           Length Source                Source Port Destination           Destination Port Protocol Media Port Context-ID CN-DomainIndicator Info
    335 25.966740569   134    185                               187                                    BSSAP                                             SACK DT1 (BSSMAP) Cipher Mode Command 

Frame 335: 134 bytes on wire (1072 bits), 134 bytes captured (1072 bits) on interface 1
Ethernet II, Src: 00:00:00_00:00:00 (00:00:00:00:00:00), Dst: 00:00:00_00:00:00 (00:00:00:00:00:00)
Internet Protocol Version 4, Src: 127.0.0.1, Dst: 127.0.0.1
Stream Control Transmission Protocol, Src Port: 2905 (2905), Dst Port: 50788 (50788)
MTP 3 User Adaptation Layer
Signalling Connection Control Part
BSSAP
GSM A-I/F BSSMAP - Cipher Mode Command
    Message Type Cipher Mode Command
    Encryption Information
        Element ID: 0x0a
        Length: 9
        1... .... = GSM A5/7: Permitted
        .0.. .... = GSM A5/6: Not permitted
        ..0. .... = GSM A5/5: Not permitted
        ...0 .... = GSM A5/4: Not permitted
        .... 0... = GSM A5/3: Not permitted
        .... .0.. = GSM A5/2: Not permitted
        .... ..0. = GSM A5/1: Not permitted
        .... ...0 = No encryption: Not permitted
        Key: 818709baba205891

No.     Time           Length Source                Source Port Destination           Destination Port Protocol Media Port Context-ID CN-DomainIndicator Info
    337 25.967697395   122    187                               185                                    BSSAP                                             SACK DT1 (BSSMAP) Cipher Mode Reject 

Frame 337: 122 bytes on wire (976 bits), 122 bytes captured (976 bits) on interface 1
Ethernet II, Src: 00:00:00_00:00:00 (00:00:00:00:00:00), Dst: 00:00:00_00:00:00 (00:00:00:00:00:00)
Internet Protocol Version 4, Src: 127.0.0.1, Dst: 127.0.0.1
Stream Control Transmission Protocol, Src Port: 2905 (2905), Dst Port: 43964 (43964)
MTP 3 User Adaptation Layer
Signalling Connection Control Part
BSSAP
GSM A-I/F BSSMAP - Cipher Mode Reject
    Message Type Cipher Mode Reject
    Missing Mandatory element (0x04) Cause, rest of dissection is suspect
        [Expert Info (Warning/Protocol): Missing Mandatory element (0x04) Cause, rest of dissection is suspect]
            [Missing Mandatory element (0x04) Cause, rest of dissection is suspect]
            [Severity level: Warning]
            [Group: Protocol]
    Extraneous Data, dissector bug or later version spec(report to wireshark.org)
        [Expert Info (Note/Protocol): Extraneous Data, dissector bug or later version spec(report to wireshark.org)]
            [Extraneous Data, dissector bug or later version spec(report to wireshark.org)]
            [Severity level: Note]
            [Group: Protocol]

#2 Updated by neels 4 months ago

  • Status changed from New to In Progress
  • % Done changed from 0 to 50

https://gerrit.osmocom.org/5376 fixes passing the proper encryption algorithm on from MSC to BSC.
https://gerrit.osmocom.org/5380 fixes passing encryption algorithms other than A5/1 on from BSC to BTS.

#3 Updated by neels 4 months ago

The remaining issue is that in the presence of both 2G and 3G tokens in the HLR db, we do UMTS AKA but send a GSM AKA Kc.

This happens because the MSC doesn't really know what algorithms have been set in the HLR db. All that the MSC sees is the presence of UMTS AKA tokens in the auth vector.

There will always be GSM AKA tokens in the vector as well: either because explicit GSM tokens are set in the HLR DB, or because the GSM tokens were derived from the 3G tokens. The 3G derived tokens and the 2G tokens take the same place in the auth vector, only one of the two will be provided, without an indication which ones they are.

So, if the MS indicates it is R99 capable on an R99 GERAN, and if there are 3G tokens available in the auth vector, we always send a UMTS challenge complete with AUTN. The response we receive is allowed to be just a GSM SRES, which the MS may decide to send when on a GERAN. But practically, what I see is, that, despite COMP128v3 set on the USIM as 2G algo, the USIM actually responds with a full UMTS AKA RES+XRES matching the 3G tokens. That works out and auth succeeds.

Next up is ciphering. On a GERAN, we always use the Kc from the auth tuple for the Ciphering Mode Command. Since the auth token received from the HLR contains a 2G Kc calculated separately from the 3G tokens, the Kc now mismatches the UMTS AKA that took place earlier. IOW, since COMP128v3 is set for that subscriber in the HLR db, that Kc has not been derived from the 3G data we used for authn, but it has been calculated from the GSM KI and uses COMP123v3. We naturally never receive a Ciphering Mode Response and reject in timeout.

How to solve this? Things that come to mind...

  • Q: the sysmo-usim-tool names the USIM settings to set auth algos "2G" and "3G". Would the naming be more accurately be "GSM" and "UMTS"? i.e. that when "2G = COMP128v3" and "3G = MILENAGE" are set on the USIM, are we instructing to use milenage on R99 capable 2G networks, and COMP128v3 only in non-R99 2G networks? (This seems to make most sense to me)
    • If this is so, we need to receive a 3G-derived Kc from the HLR independently from whether aud_2g tokens were also provided or not. Currently, a 2G Kc completely replaces the 3G derived one, instead we need both sent in the vector from the HLR.
    • So, for an R99 GERAN or MS, we would use UMTS AKA and the 3G derived Kc.
    • For a pre-R99 GERAN or MS, we would use GSM AKA and the separately calculated Kc.
  • If the MSC knew that the 2G tokens were explicitly calculated from a separate GSM algo and not derived from 3G, it could refrain from sending a UMTS challenge on 2G, even if it is R99. Hence we would use only the 2G data, the shorter SRES and the ciphering key Kc would correspond with the keys used for authentication. (This would mean we would do UMTS AKA on 2G only if no aud_2g tokens are added to the HLR DB; R99 or not. So we would not be able to dynamically choose between UMTS or GSM AKA, which makes little sense to me.)
Either way it seems to me we need to extend the IEs sent via GSUP from the HLR,
  • either to add a separate 3G-derived Kc and SRES (I'm favoring this),
  • or to add a flag whether Kc was derived from 3G or not.

Am I missing something?

#4 Updated by neels 4 months ago

To clarify the status quo, a workaround is to have only one set of auth tokens in the HLR db, either remove the aud_2g or remove the aud_3g.

  • If only 2G tokens are present in the HLR db, auth and ciphering works well, using GSM AKA.
  • If only 3G tokens are present in the HLR db, auth and ciphering works well, using UMTS AKA if R99 and 3G derived Kc.
  • If both 2G and 3G tokens are present in the HLR db, authentication works (using UMTS AKA), but ciphering fails.

#5 Updated by laforge 4 months ago

Hi Neels,

On Thu, Dec 14, 2017 at 09:35:41PM +0000, neels [REDMINE] wrote:

The remaining issue is that in the presence of both 2G and 3G tokens
in the HLR db, we do UMTS AKA but send a GSM AKA Kc.

Isn't this exactly what is expected?

This happens because the MSC doesn't really know what algorithms have
been set in the HLR db. All that the MSC sees is the presence of UMTS
AKA tokens in the auth vector.

This is how I understand it should be.

So, if the MS indicates it is R99 capable on an R99 GERAN, and if
there are 3G tokens available in the auth vector, we always send a
UMTS challenge complete with AUTN.

Also fits with my understanding.

The response we receive is allowed to be just a GSM SRES, which the MS
may decide to send when on a GERAN.

This is what I'm surprised to hear. Do you have a spec reference for
that? My understanding has been that basically if the MS is UMTS-AKA
capable, then we perform UMTS AKA and should also expect a full
RES+XRES. So if we send a 3G AKA, we expect to receive 3G AK.

But practically, what I see is, that, despite COMP128v3 set on the
USIM as 2G algo, the USIM actually responds with a full UMTS AKA
RES+XRES matching the 3G tokens.

Of course. The radio technology has no relation on the way how the
phone firmware talks to the SIM card. If the phone talks to the SIM
using the USIM application (which at least any 3G capable phone will
do), then it will use the "3G algo" of the SIM. If however the phone
firmware talks to the SIM in "SIM" mode, then the card will use the "2G
algo".

Next up is ciphering. On a GERAN, we always use the Kc from the auth
tuple for the Ciphering Mode Command. Since the auth token received
from the HLR contains a 2G Kc calculated separately from the 3G
tokens, the Kc now mismatches the UMTS AKA that took place earlier.
IOW, since COMP128v3 is set for that subscriber in the HLR db, that Kc
has not been derived from the 3G data we used for authn, but it has
been calculated from the GSM KI and uses COMP123v3. We naturally never
receive a Ciphering Mode Response and reject in timeout.

This is also expected. The choice of Kc must be made based on the
authentication algorithm used. So if authentication proceeds with
UMTS AKA, then the Kc must be derived from Ck/Ik using one of those
mapping functions given in the relevant specs. According to some
notes I took years ago I think it was function "c3" in TS 33.102

btw: Please also not the similar c4/c5 functions which must be used
if a UMTS AKA is to be performed purely on GSM auth tuples (e.g. using
a classic SIM wihout USIM capability)

Only if authentication was made using the classic 2G RAND, the Kc value
received in the quintuple from the HLR/AuC must be used in the MSC!

  • Q: the sysmo-usim-tool names the USIM settings to set auth algos
    "2G" and "3G". Would the naming be more accurately be "GSM" and
    "UMTS"?

The correct naming would be "SIM application" and "USIM application".
However, we used the naming of the SIM card OS maker. The choice of
which "application" the phone firmware talks to is irrespective of which
current RAT is in use. The SIM has [normally, ignoring proactive SIM]
no knowledge on the current RAT.

i.e. that when "2G = COMP128v3" and "3G = MILENAGE" are set on
the USIM, are we instructing to use milenage on R99 capable 2G
networks, and COMP128v3 only in non-R99 2G networks? (This seems to
make most sense to me)

Correct.

  • If this is so, we need to receive a 3G-derived Kc from the HLR
    independently from whether aud_2g tokens were also provided or not.
    Currently, a 2G Kc completely replaces the 3G derived one, instead we
    need both sent in the vector from the HLR.

Why would this have to be done in the HLR? Why can't the MSC simply
derive the Kc? Changing the bits communicated between HLR and MSC to
something that's not present in GSM MAP would make it impossible to ever
interoperate with MAP.

I think all that's needed to do in the MSC in such cases is

for (i = 0; i < 8; i++)
kc[i] = ck[i] ^ ck[i + 8] ^ ik[i] ^ ik[i + 8];

See libosmocor/src/gsm/milenage/milenage.c:gsm_milenage()

  • If the MSC knew that the 2G tokens were explicitly calculated from a
    separate GSM algo and not derived from 3G, it could refrain from
    sending a UMTS challenge on 2G, even if it is R99.

Why?

Either way it seems to me we need to extend the IEs sent via GSUP from the HLR,
  • either to add a separate 3G-derived Kc and SRES (I'm favoring this),
  • or to add a flag whether Kc was derived from 3G or not.

I don't think so.

Am I missing something?

gsm_milenage

#6 Updated by neels 4 months ago

so, to recap: if on R99 capable devices and aud_3g data is present in the HLR, we use full UMTS AKA and expect the "3G" a.k.a. USIM app's auth algo to be used (not the SIM app a.k.a. "2G").

My thinko there lies in the fact that the Kc-from-UMTS-tokens formula is actually algorithm agnostic.
3GPP TS 33.103 4.2.2 "Authentication and key agreement (AKA USIM )"

The following cryptographic functions need to be implemented on the USIM:
[...]
c3: Conversion function for interoperation with GSM from Ck and IK (UMTS) to Kc (GSM).

Since c3 is algorithm agnostic, the MSC can employ it without having to know whether the HLR and USIM are using Milenage or whatever.

When using UMTS AKA, we should never use the Kc we got from GSUP. Instead, we always use c3(). (If the Kc from GSUP was derived from 3G in the HLR, incidentally that will be the same Kc as we will calculate in the MSC, and that doesn't bear any meaning; ignore the GSUP Kc, calculate it from UMTS tokens.)

If there are no aud_2g data in the HLR, the HLR will derive Kc and SRES from the UMTS tokens; that will only be used on non-R99 MS/GERAN, in which case we use the GSUP Kc for ciphering.

non-R99 GERAN / non-R99 MS R99 GERAN and R99 MS
only aud_2g in HLR,
GSUP sent only Kc and SRES
use GSUP's Kc and SRES
only aud_3g in HLR,
GSUP sent UMTS AKA tokens
as well as Kc and SRES derived from 3G AKA
use GSUP's Kc and SRES, incidentally derived from 3G keys use full UMTS AKA; MSC ignores GSUP's Kc and calculates Kc from c3() (incidentally ends up to be the same Kc as from GSUP)
aud_2g and aud_3g in HLR,
GSUP sent UMTS AKA tokens
as well as Kc and SRES from separate 2G algo
use GSUP's Kc and SRES use full UMTS AKA; MSC ignores GSUP's Kc and calculates Kc from c3() (incidentally differs from GSUP's Kc)

#7 Updated by neels 4 months ago

The response we receive is allowed to be just a GSM SRES, which the MS
may decide to send when on a GERAN.

This is what I'm surprised to hear. Do you have a spec reference for
that?

There is a code comment in that direction:

osmo-msc/src/libvlr/vlr_auth_fsm.c

                /* We have a R99 capable UE and have a UMTS AKA capable USIM.
                 * However, the ME may still choose to only perform GSM AKA, as
                 * long as the bearer is GERAN */

You added that comment on first vlr_auth_fsm.c implementation, so you may have had your reasons for that?

#8 Updated by neels 4 months ago

  • Subject changed from 2G auth does not work when 3G keys are provisioned. to UMTS ciphering on GSM does not work when both 2G and 3G keys are present in the HLR.

#9 Updated by lynxis 4 months ago

  • Related to Bug #2765: umts auth timed out on a 2G network. added

#10 Updated by neels 4 months ago

  • Related to deleted (Bug #2765: umts auth timed out on a 2G network.)

#11 Updated by neels 4 months ago

  • Duplicated by Bug #2765: umts auth timed out on a 2G network. added

#12 Updated by neels 4 months ago

  • % Done changed from 50 to 90

issue fixed by https://gerrit.osmocom.org/5470 (And patches leading up to it, see topic 'encryption' on gerrit)
https://gerrit.osmocom.org/#/q/status:open+topic:encryption

Depends on libosmocore https://gerrit.osmocom.org/5466

#13 Updated by neels 4 months ago

  • Project changed from OsmoHLR to OsmoMSC

#14 Updated by neels 3 months ago

  • Status changed from In Progress to Resolved
  • % Done changed from 90 to 100

all merged, yet #2793 may be related

Also available in: Atom PDF