Dear list,
I'm having trouble using the A5/3 encryption in my setup. A5/1 works perfectly fine [attachment a5_1.pcapng]. As soon as I switch to A5/3 and e.g. send an SMS, the last valid message I see in the Wireshark traces of the GSMTAP of osmo-bts-trx is the Ciphering Mode Command requesting A5/3. After that, several messages arrive at the bts, but it seems like it can't make any sense of them. The MS repeatedly tries to send the SMS but never succeeds [attachment a5_3.pcapng]. Both MSs are connected to the same bts.
According to the Classmarks of all MSs, A5/1 as well as A5/3 are supported.
This is my Setup:
- USRP N210
- osmo-trx
- osmo-bts-trx
- osmo-nitb
- osmo-pcu
- osmo-sgsn
- osmo-ggsn
I'm using a Debian 9 VM and tried both the packages from osmocom-latest as well as osmocom-nightly.
The MSs I've tested are two Nexus 6 and one Samsung Galaxy S I9000. All three with sysmocom nano USIMs.
Could the decryption at the bts be incorrect? Has anyone tested/used it recently?
I'll be happy to provide additional information if needed.
Thanks,
Jan
Hi Jan,
Do you have traces of the attach/authentication? It seems like for some reason your MS don't like A5/3, because they are supposed to reply with Cipher Mode Complete. So top of my head I had the thought there might be something wrong with the initial establishment of the keys.
Cheers, Domi
- márc. 6. dátummal, 10:58 időpontban Bruckner Jan (ETAS-SEC/ECT-Mu) Jan.Bruckner@escrypt.com írta:
Dear list,
I’m having trouble using the A5/3 encryption in my setup. A5/1 works perfectly fine [attachment a5_1.pcapng]. As soon as I switch to A5/3 and e.g. send an SMS, the last valid message I see in the Wireshark traces of the GSMTAP of osmo-bts-trx is the Ciphering Mode Command requesting A5/3. After that, several messages arrive at the bts, but it seems like it can’t make any sense of them. The MS repeatedly tries to send the SMS but never succeeds [attachment a5_3.pcapng]. Both MSs are connected to the same bts.
According to the Classmarks of all MSs, A5/1 as well as A5/3 are supported. This is my Setup:
USRP N210osmo-trxosmo-bts-trxosmo-nitbosmo-pcuosmo-sgsnosmo-ggsnI’m using a Debian 9 VM and tried both the packages from osmocom-latest as well as osmocom-nightly. The MSs I’ve tested are two Nexus 6 and one Samsung Galaxy S I9000. All three with sysmocom nano USIMs.
Could the decryption at the bts be incorrect? Has anyone tested/used it recently? I’ll be happy to provide additional information if needed.
Thanks, Jan <a5_3.pcapng><a5_1.pcapng>
Hi Domi,
I have attached another trace containing the following:
- Location Update + Authentication of the MS that will send the SMS (packets 1-45) - Sending and receiving an SMS (text: “a5/1”) with encryption set to A5/1 (packets 46-140) - works - Sending an SMS (text: “a5/3”) with encryption set to A5/3 (packets 141-730) - the MS tries to send several times until it gives up. No Ciphering Mode Complete is received. - Switching back to A5/1 and resending the SMS with text "a5/3" (packets 731-827) - works
I hope that helps.
Thanks, Jan
Hi Jan,
A5/1 works, which means that your auth keys in the SIM and subscriber database match.
In the CM Service Request, your MS indicates that it is capable of A5/3. (In the Classmark 2)
I see that you only have one Location Updating with A5/1. It should work to switch to A5/3 on-the-fly, but just for curiosity, you could try to detach and re-attach the phone after switching to A5/3.
You write that you are using osmo-nitb. Does the problem persist if you use osmo-bsc + osmo-msc + osmo-hlr instead? See: https://osmocom.org/projects/cellular-infrastructure/wiki/Osmocom_Network_In...
Other than that I can't see anything wrong with anything.
If you switch back and forth between A5/3 and /1, do the results remain stable? So it's not your SDR coincidentally clock-unsyncing in the wrong moment by coincidence?
Seems curious that recently there have been other questions about auth / ciph not working for specific osmo-bts-trx variants. There is a faint possibility that one thing or other doesn't get encoded/decoded right??
~N
Hi Neels,
I see that you only have one Location Updating with A5/1. It should work
to switch to A5/3 on-the-fly, but just for curiosity, you could try to detach and re-attach the phone after switching to A5/3.
I just tested that. It does not change the behavior. As soon as I switch to A5/3 the BTS never receives a Ciphering Mode Complete, after having sent the Ciphering Mode Command for A5/3 to the MS. This happens for SMS as well as the whole Location Update/Authentication/TMSI-Relocation procedure. Trying to attach the MS after enabling A5/3, the MS is not able to attach successfully and continuously tries to attach until it gives up. Similar to how it keeps trying to send an SMS with A5/3 enabled.
I have attached another trace of the attach and detach with A5/0 (works), then A5/1 (works) and finally A5/3 (fails, tried several times). For the A5/3 attach, there is no Authentication Request/Reply. But also in cases where the Authentication is performed the following A5/3 ciphering fails in the same way.
You write that you are using osmo-nitb. Does the problem persist if you
use osmo-bsc + osmo-msc + osmo-hlr instead? See: https://osmocom.org/projects/cellular-infrastructure/wiki/Osmocom_Network_In _The_Box
I will try to test that setup and let you know if it helps.
If you switch back and forth between A5/3 and /1, do the results remain
stable? So it's not your SDR coincidentally clock-unsyncing in the wrong moment by coincidence?
I tested it many times, switching between A5/3,1 and 0 and using different phones. A5/1 (and 0 of course) works every single time. A5/3 did not work a single time. I'd say it's safe to assume that it's not the SDR failing in some way.
Jan
On Wed, Mar 07, 2018 at 11:14:25AM +0000, Bruckner Jan (ETAS-SEC/ECT-Mu) wrote:
I just tested that. It does not change the behavior. As soon as I switch to A5/3 the BTS never receives a Ciphering Mode Complete
The details there are that the Ciphering Mode Command is asking to start ciphering on the air, and the Ciphering Mode Complete is already sent ciphered. So it might be received, but the received data may be discarded as gibberish.
It would be good if anyone out there could try to reproduce the error using an SDR based BTS.
You're also welcome to create a ticket on the osmocom.org redmine.
~N
Hi,
I migrated my setup to the new Network In The Box configuration with separated components (from latest, not nightly). I tested whether the described issue with A5/3 is resolved, but it still does not work. Though, the behavior has changed.
In the old setup a Ciphering Mode Command for A5/3 was sent, but a Ciphering Mode Complete was never received. Probably, what was happening is the following:
The details there are that the Ciphering Mode Command is asking to start ciphering on the air, and the Ciphering Mode Complete is already sent > ciphered. So it might be received, but the received data may be discarded as gibberish.
In the new setup not even the Ciphering Mode Command is sent to the MS. Instead the BSC sends a Cipher Mode Reject to the MSC, if I am reading the logs correctly:
<000a> a_iface_bssap.c:629 Rx MSC DT1 BSSMAP CIPHER MODE REJECT <000a> a_iface_bssap.c:453 BSC sends cipher mode reject (conn_id=65) <000a> a_iface_bssap.c:457 Cause code is missing -- discarding message! <0027> sms_queue.c:156 Sending SMS 13 failed 0 times.
The full log is attached to the issue [1].
I am setting the encryption to A5/3 in both the MSC and the BSC. A5/1 continues to work without any problems.
Thanks, Jan
On Wed, Apr 18, 2018 at 01:21:27PM +0000, Bruckner Jan (ETAS-SEC/ECT-Mu) wrote:
Hi,
I migrated my setup to the new Network In The Box configuration with separated components (from latest, not nightly). I tested whether the described issue with A5/3 is resolved, but it still does not work. Though, the behavior has changed.
In the old setup a Ciphering Mode Command for A5/3 was sent, but a Ciphering Mode Complete was never received. Probably, what was happening is the following:
The details there are that the Ciphering Mode Command is asking to start ciphering on the air, and the Ciphering Mode Complete is already sent > ciphered. So it might be received, but the received data may be discarded as gibberish.
In the new setup not even the Ciphering Mode Command is sent to the MS.
Commented in OS#3043 on the reason why A5/3 gets rejected. I'm continuing discussion there instead of duplicating on the mailing list.
Instead the BSC sends a Cipher Mode Reject to the MSC, if I am reading the logs correctly:
<000a> a_iface_bssap.c:629 Rx MSC DT1 BSSMAP CIPHER MODE REJECT <000a> a_iface_bssap.c:453 BSC sends cipher mode reject (conn_id=65)
This bit confuses me: how can the BSC reject a Cipher Mode if the MSC never sent a Cipher Mode Command?
The BSC would send a Cipher Mode Reject if it finds the algorithm requested by the MSC not supported in the osmo-bsc.cfg. Maybe we also do that if A5/0 (no encryption) is not listed in osmo-bsc.cfg??
<000a> a_iface_bssap.c:457 Cause code is missing -- discarding message!
Interesting. I have identified https://osmocom.org/issues/3186 and https://osmocom.org/issues/3187
A5/1 continues to work without any problems.
The root cause for all of this is most probably above missing-classmark problem, but it turns out to be a good thing that it helped us uncover a bunch of errors in error handling.
Thanks for your reports!
~N
-
Bruckner Jan (ETAS-SEC/ECT-Mu) -
Neels Hofmeyr -
Tomcsányi Domonkos