Hey,

Could you elaborate a bit what is happenning on the video?

Thanks

Domonkos

21.08.2022 dátummal, 21:26 időpontban Bastien Baranoff <bastienbaranoff@gmail.com> írta:



My Bad IT WORKS !!!!!
https://www.youtube.com/watch?v=Q-fEFbX5QeE

Le dim. 21 août 2022 à 16:18, Bastien Baranoff <bastienbaranoff@gmail.com> a écrit :

Hello I admit that I mess a little with my assertion... What I mean is we have to begin by something like this, (which not work yet i don't know why...)

Cause I inject the kc to the ms and answer withe the sres to the bts
https://www.youtube.com/watch?v=J40EAVK-LHI
https://imgur.com/4PjzMjw
https://imgur.com/qWGVmOk

if you want to help you have the procedure in YT description tnahk you all

Le jeu. 3 mars 2022 à 04:02, Mychaela Falconia <mychaela.falconia@gmail.com> a écrit :

Neels Hofmeyr wrote:

> Networks and user equipment capable of UTRAN a.k.a. R99+ ("release 99"),
> do use full Milenage AKA even on 2G networks.

Important correction: "capable of UTRAN" and R99+ are NOT one and the
same.  Consider an ME implementation with GSM-only radio (no UTRAN)
that is made to R99 specs - there are several real-world examples of
such, including Nokia C3-00 and TI's LoCosto chipset (not Calypso)
with its corresponding TCS3.2 reference fw.  Are such MEs required to
support USIM protocol and 3G-style AKA?  Answer given in 3GPP TS 33.102
section 6.8.1.4: support for USIM-ME interface (and thus 3G AKA) on
such MEs is optional ("may support") for R99 and Rel-4, and only
becomes mandatory from Rel-5 onward.

In real life: Nokia C3-00 supports USIM-ME interface, but TI's TCS3.2
(LoCosto) fw does not, despite supporting R99 otherwise.

> For pre-R99 MS on a UTRAN capable
> network, the HLR and USIM may use the 3G key material as basis to generate
> shorter authentication tokens -- this is not seen in practice at all these
> days. It is reasonable to expect full Milenage Authentication and Key
> Agreement everywhere.

Consider this scenario:

* The operator's network is predominantly 3G/4G/5G, with GERAN support
only as legacy.

* Operator-issued "SIM" cards are USIM/ISIM native, with GSM 11.11 SIM
support only as a backward compatibility feature.

* However, the human end user of the mobile service principally,
philosophically and ideologically insists on using an ancient ME
implementation that is not only limited to GSM/2G in terms of radio,
but also does NOT speak UICC/USIM protocol, only speaks GSM 11.11
protocol to the SIM.

As you can surely tell, what I just outlined is my real, actual,
everyday real-life use case.  So what happens in *this* use case?
Obviously the authentication mode can only be classic GSM, as the ME
firmware doesn't speak anything else.  The authentication command sent
to the SIM is RUN GSM ALGO from GSM 11.11, the input is just RAND (no
AUTN), and the response from SIM is 8 bytes of Kc + 4 bytes of SRES.

But what does the (U)SIM actually do internally to produce this
2G-style Kc+SRES response?  Prior to my most recent careful reading of
3GPP TS 33.102, I thought there were two possibilities:

1) I thought that dual-mode SIMs had the option of using different
algorithms for 2G and 3G modes, i.e., some version of COMP128 for 2G
and Milenage for 3G.  I thought this possibility was valid because
Sysmocom USIM/ISIM cards support such configuration, and it is my
understanding that original sysmoUSIM-SJS1 cards were shipped with 2G
algo set to COMP128v1 and 3G also set to Milenage.

2) The other possibility is for the (U)SIM (and HLR correspondingly)
to have only 3G key material and Milenage internally, with 2G
authentication requests returning the result of c2 and c3 conversion
functions from 3GPP TS 33.102 section 6.8.1.2.

Now my reading of 33.102 tells me that only option 2 out of the above
is valid (see section 6.8.1.5), whereas option 1 appears to be
disallowed.  Considering the separation between HLR/AuC and MSC/VLR,
I don't see any way for an operator to implement a scheme with COMP128
for 2G and Milenage for 3G: if MSC/VLR is 3G-aware, then whenever HLR
supplies auth vectors to MSC/VLR, these vectors have to be quintets,
and if the user's ME turns out to be a refusenik, then it is MSC/VLR
and not HLR who gets to apply c2 and c3 conversion functions - hence
there is no place for the operator to apply COMP128 for 2G mode.

Two questions now:

1) Is my analysis above correct, or have I missed something or gone
astray somewhere?

2) If my analysis is correct, then why did sysmoUSIM-SJS1 cards ship
with the algorithm combination of COMP128v1 for 2G and Milenage for
3G?  Isn't this combination invalid with regard to 3GPP architecture?
And to make matters worse, some of those cards were sold at a cheaper
price without ADM keys, making this factory configuration unchangeable.
An invalid config that is also unchangeable??

Just trying to understand...

M~