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~
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-resea... 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@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~
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
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~
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~
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~
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~
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@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@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~
sorry https://imgur.com/a/sgaLLza Le lun. 22 août 2022 à 11:07, Bastien Baranoff <bastienbaranoff@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@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@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~
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@gmail.com> a écrit :
sorry https://imgur.com/a/sgaLLza
Le lun. 22 août 2022 à 11:07, Bastien Baranoff <bastienbaranoff@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@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@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~
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@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@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~
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@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@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@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~
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:
https://github.com/bbaranoff/telco_story/blob/main/README.md
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@osmocom.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
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
participants (6)
-
Bastien Baranoff -
bastien baranoff -
Harald Welte -
Mychaela Falconia -
Neels Hofmeyr -
Tomcsanyi, Domonkos