soory again... https://imgur.com/lUjkpGp I think now it is what i want to say
Le lun. 22 août 2022 à 11:10, Bastien Baranoff <bastienbaran...@gmail.com> a écrit : > sorry https://imgur.com/a/sgaLLza > > > Le lun. 22 août 2022 à 11:07, Bastien Baranoff <bastienbaran...@gmail.com> > a écrit : > >> To be more clear on what i do >> https://imgur.com/Cl8eiy4 >> Next step is to crack Kc before T3210 ends (5s) and you have full >> impersonnation ;) >> >> Le lun. 22 août 2022 à 10:11, Tomcsanyi, Domonkos <d...@tomcsanyi.net> a >> écrit : >> >>> 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 < >>> bastienbaran...@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 < >>> bastienbaran...@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.falco...@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~ >>>>> >>>>
