1 Mar
2022
1 Mar
'22
8:16 p.m.
Bastien Baranoff wrote:
Hello all, the attack : you generate the rainbow
tables for each possibles ki
with a given rand set, send this rand (which is not random ;) the phone
respond with sres you make the operation for 3 or 4 rand and meaningly
decrease the possibility of ki. Do you think it is realisable ?
Someone please correct me if I'm wrong on this detail, but it is my
understanding that no mainstream commercial operator today (outside of
personal enthusiast tinkerers in Osmocom and similar communities)
issues native 2G SIM cards any more - instead all of their current SIM
cards are actually USIM/ISIM, and if GSM 11.11 SIM operation is
supported at all, it is only provided as a backward compatibility
mode. I reason that these "modern" SIMs must be using Milenage in
their native 3G/4G mode, thus their secret key material is not classic
Ki, but K/Ki (128 bits) plus OPc (another 128 bits), for a total of
256 bits of secret key material.
What happens when these "modern" SIMs are accessed via GSM 11.11 SIM
protocol, or when 2G authentication is requested in a USIM session?
I find it doubtful that they switch to COMP128 (any version) in this
mode, instead I reason that they use 2G mode of Milenage, which still
uses both K/Ki and OPc - thus the secret key material used even for 2G
Kc and SRES generation from RAND is still 256 bits rather than 128.
Again, someone please correct me if my reasoning is wrong here.
M~
2 Mar
2 Mar
12:29 a.m.
New subject: New attack ?
Sorry when i had the idea i thought it clever which is not the case yet.
But i may think that which choosen rand we may downgrade from 256 bits to
128 bits
but for old sims and even 128 bits are unbreackable. Sorry again and please
forget it and forgive me for it.
For those interested we can execute the attack flow like that research
(soory for the french ... google trnaslate)
https://blogs.univ-poitiers.fr/f-launay/2021/06/23/la-securite-sur-les-rese…
which your fellow has predate with
https://www.youtube.com/watch?v=XSN9oDS5TqI.
The poitiers 's research was ahead me cause i didin't get the kc. But they
have MS kept busy when connecting
to legit BTS to get rid out of this have fun with Nico Golde' paging attack.
But I wanted to go further by overkilling 2G with Ki cracking by using a3a8
algorithm
https://github.com/bbaranoff/testa3a8/ with a testcase condition of
ki|RAND<=>SRES|kc
but i had made a confusion with 128 and 64 bits for dimensionnement of the
attack ;) a little big error
which if it was possible make it impossible (at least in this state of
art). Yes I meaned 128bits and not 256 at least
up to compv3 cause with ciphering mode completed attack you forward the
rand legit bts so in the same idea you can
set a "static" rand (lol) and if the ki was 64 bits generate rainbows but
little cufion of 64bits which made the attack from
few minuts to billions years. Hope you have enjoyed the reading. And Thank
You OsmoCom(munity)
Le mar. 1 mars 2022 à 20:17, Mychaela Falconia <mychaela.falconia(a)gmail.com>
a écrit :
Bastien Baranoff wrote:
Hello all, the attack : you generate the rainbow
tables for each
possibles ki
with a given rand set, send this rand (which is
not random ;) the phone
respond with sres you make the operation for 3 or 4 rand and meaningly
decrease the possibility of ki. Do you think it is realisable ?
Someone please correct me if I'm wrong on this detail, but it is my
understanding that no mainstream commercial operator today (outside of
personal enthusiast tinkerers in Osmocom and similar communities)
issues native 2G SIM cards any more - instead all of their current SIM
cards are actually USIM/ISIM, and if GSM 11.11 SIM operation is
supported at all, it is only provided as a backward compatibility
mode. I reason that these "modern" SIMs must be using Milenage in
their native 3G/4G mode, thus their secret key material is not classic
Ki, but K/Ki (128 bits) plus OPc (another 128 bits), for a total of
256 bits of secret key material.
What happens when these "modern" SIMs are accessed via GSM 11.11 SIM
protocol, or when 2G authentication is requested in a USIM session?
I find it doubtful that they switch to COMP128 (any version) in this
mode, instead I reason that they use 2G mode of Milenage, which still
uses both K/Ki and OPc - thus the secret key material used even for 2G
Kc and SRES generation from RAND is still 256 bits rather than 128.
Again, someone please correct me if my reasoning is wrong here.
M~
1:15 p.m.
New subject: New attack ?
On Tue, Mar 01, 2022 at 11:16:50AM -0800, Mychaela Falconia wrote:
mode. I reason that these "modern" SIMs
must be using Milenage in
their native 3G/4G mode, thus their secret key material is not classic
Ki, but K/Ki (128 bits) plus OPc (another 128 bits), for a total of
256 bits of secret key material.
What happens when these "modern" SIMs are accessed via GSM 11.11 SIM
protocol, or when 2G authentication is requested in a USIM session?
Networks and user equipment capable of UTRAN a.k.a. R99+ ("release 99"), do use
full Milenage AKA even on 2G networks. 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.
Figure 18 in 3GPP 33.102 section 6.8.1.1 shows all of this in detail. I had
this chart on the wall when implementing UMTS AKA in osmo-hlr and osmo-msc.
~N
3 Mar
3 Mar
4 a.m.
New subject: New attack ?
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~
21 Aug
21 Aug
4:18 p.m.
New subject: New attack ?
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(a)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~
9:24 p.m.
New subject: New attack ?
My Bad IT WORKS !!!!!
https://www.youtube.com/watch?v=Q-fEFbX5QeE
Le dim. 21 août 2022 à 16:18, Bastien Baranoff <bastienbaranoff(a)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(a)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~
22 Aug
22 Aug
10:11 a.m.
New subject: New attack ?
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(a)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(a)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(a)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~
11:07 a.m.
New subject: New attack ?
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 <domi(a)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 <
bastienbaranoff(a)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(a)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(a)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~
>>
>
11:10 a.m.
New subject: New attack ?
sorry https://imgur.com/a/sgaLLza
Le lun. 22 août 2022 à 11:07, Bastien Baranoff <bastienbaranoff(a)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 <domi(a)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 <
> bastienbaranoff(a)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(a)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(a)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~
>>>
>>
11:20 a.m.
New subject: New attack ?
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 <bastienbaranoff(a)gmail.com>
a écrit :
sorry https://imgur.com/a/sgaLLza
Le lun. 22 août 2022 à 11:07, Bastien Baranoff <bastienbaranoff(a)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 <domi(a)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 <
>> bastienbaranoff(a)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(a)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(a)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~
>>>>
>>>
7:53 p.m.
New subject: New attack ?
https://github.com/bbaranoff/telco_story/blob/main/README.md
Idk if it will be more clear ?
Le lun. 22 août 2022 à 10:11, Tomcsanyi, Domonkos <domi(a)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 <
bastienbaranoff(a)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(a)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(a)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~
>>
>
23 Aug
23 Aug
12:34 p.m.
New subject: New attack ?
Sorry to spam ? you have here a video with explanations
https://www.youtube.com/watch?v=rSGA4oFsFrQ
Le lun. 22 août 2022 à 19:53, Bastien Baranoff <bastienbaranoff(a)gmail.com>
a écrit :
https://github.com/bbaranoff/telco_story/blob/main/README.md
Idk if it will be more clear ?
Le lun. 22 août 2022 à 10:11, Tomcsanyi, Domonkos <domi(a)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 <
> bastienbaranoff(a)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(a)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(a)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~
>>>
>>
4:48 p.m.
New subject: New attack ?
Hi Bastien,
please try to avoid spamming the mailing list with lots of single-line responses
on a single day, thanks.
On Mon, Aug 22, 2022 at 07:53:00PM +0200, Bastien Baranoff wrote:
What you are describing is a classic GSM man-in-the-middle attack,
combined with a 4G->2G downgrade. I don't see what is new here. It's
how MITM on 2G has operated basically forever: You can just 1:1 forward
the authentication, but need to crack the Kc before you can talk
encrypted from your virtual MS to the real BTS.
--
- Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
6 Jun
6 Jun
7:24 p.m.
New subject: New attack ?
Hello time goes...
What I did want to say. I was messy last time. Was talking about multiple subjects at a
time
1-Impersonnation ? (not new attack)
Can it ever be done ?? I mean we have four burst
genuine MS < - > genuine BTS
genuine MS < - > evil BTS
evil MS < - > genuine BTS
evil MS < - > evil BTS
instead of one
genuine MS < - > genuine BTS
2- My "work"
I did with a reader and a Motorola : read rand from genuine BTS catch SRes from the sim to
a fake BB which forward the SRes in response the rand asked by a fake TRX forwarded by my
evil OSMOCom-BB to genuine BTS
I used SoftSim but not like SoftSim do normaly. I have took the kc in SoftSim and pushed
it in OSMOCom-BB phone and get a connection with a genuine BTS with pushing only that from
the reader (I have cheat) but the RAND and SRES should be forwarded.
https://www.youtube.com/watch?v=rSGA4oFsFrQ&t=53s
3- What i intent to do
Like Harald Welte said I miss the kc and my question is what frame to take we have 4 in
this case instead of 1 and the number of the frame to take for find_kc tool ??
4- What I was trying to say :
If we control the rand sent to target is there a way to retrieve the Ki of the target with
such attacks I mean with sending multiple rand choosen and retrieve Ki
https://github.com/bbaranoff/Comp128/blob/master/COMP128-R3.txt
327
days inactive
789
days old
baseband-devel@lists.osmocom.org
13 comments
6 participants
participants (6)
-
Bastien Baranoff -
bastien baranoff -
Harald Welte -
Mychaela Falconia -
Neels Hofmeyr -
Tomcsanyi, Domonkos