Project

General

Profile

Bug #3043

A5/3 encryption fails

Added by jbruckner 3 months ago. Updated about 2 months ago.

Status:
New
Priority:
Normal
Assignee:
-
Target version:
-
Start date:
03/08/2018
Due date:
% Done:

0%

Estimated time:
Spec Reference:

Description

This was discussed a bit on the mailing list already: http://lists.osmocom.org/pipermail/openbsc/2018-March/011811.html

I'm attaching the Wireshark traces from the mails. Please see the respective mail from the archive for a description of what has been recorded there.

Here's my initial mail:
-------------
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.
-------------

a5_1.pcapng a5_1.pcapng 11.4 KB http://lists.osmocom.org/pipermail/openbsc/2018-March/011811.html jbruckner, 03/08/2018 10:12 AM
a5_1_3_with_LU_Auth.pcapng a5_1_3_with_LU_Auth.pcapng 94.1 KB http://lists.osmocom.org/pipermail/openbsc/2018-March/011816.html jbruckner, 03/08/2018 10:12 AM
a5_3.pcapng a5_3.pcapng 68 KB http://lists.osmocom.org/pipermail/openbsc/2018-March/011811.html jbruckner, 03/08/2018 10:12 AM
attach_a5_0_1_3.pcapng attach_a5_0_1_3.pcapng 85.6 KB http://lists.osmocom.org/pipermail/openbsc/2018-March/011823.html jbruckner, 03/08/2018 10:12 AM
a5_3_Cipher_Mode_Reject.txt a5_3_Cipher_Mode_Reject.txt 7.1 KB jbruckner, 04/18/2018 01:14 PM

Related issues

Related to OsmoBSC - Bug #3183: BSC_Tests.ttcn lacks tests for BSSMAP Cipher Mode ControlResolved2018-04-18

Related to OsmoBTS - Bug #3184: BTS_Tests.ttcn is lacking test for encryptionResolved2018-04-18

Related to OsmoMSC - Bug #2947: OsmoMSC crashes with A5/3 configured and MS sending no Classmark 2 in LU RequestResolved2018-02-15

Related to OsmoBSC - Bug #3186: cipher mode reject may be sent with invalid cause codeNew2018-04-19

Related to OsmoMSC - Bug #3187: rx cipher mode reject from BSS brokenNew2018-04-19

Related to OsmoMSC - Feature #2795: Handle UTRAN_CLSM_CHG in MSCNew2017-12-29

History

#1 Updated by jbruckner 2 months ago

Attaching log from the MSC as described on the mailing list.

#2 Updated by laforge 2 months ago

pespin: Is osmo-gsm-tester testing with different encryption settings? If not, I think it would be a rather easy-to-do but important improvement if we'd have at least one test in each current-day encryption mode (a5/0, a5/1, a5/3). In the end, it's the same test case, just running with one modified field in the config file.

@jbruckner: What we're testing on the BSC level is:
  • BSC_Tests.TC_assignment_fr_a5_0
  • BSC_Tests.TC_assignment_fr_a5_1
  • BSC_Tests.TC_assignment_fr_a5_3
  • BSC_Tests.TC_assignment_fr_a5_4

so we're quite confident the BSC is doing what it's supposed to do, if it receives a related ASSIGNMENT CMD from the MSC.

On the MSC sidde, we have
  • MSC_Tests.TC_lu_imsi_auth_tmsi_encr_013_2
  • MSC_Tests.TC_lu_imsi_auth_tmsi_encr_13_13
  • MSC_Tests.TC_lu_imsi_auth_tmsi_encr_13_2
  • MSC_Tests.TC_lu_imsi_auth_tmsi_encr_1_13
  • MSC_Tests.TC_lu_imsi_auth_tmsi_encr_3_1
  • MSC_Tests.TC_lu_imsi_auth_tmsi_encr_3_13
  • MSC_Tests.TC_lu_imsi_auth_tmsi_encr_3_1_log_msc_debug
  • MSC_Tests.TC_lu_imsi_auth_tmsi_encr_3_1_no_cm

So we're equally sure that the selection of the right encryption algorithm is performed as intended.

What's missing are tests for
  • BSC in non-assignment case (ciphering mode)
  • BTS tests for both assignment and non-assignment cases

I'll add separate tickets for the missing TTCN-3 tests

#3 Updated by laforge 2 months ago

  • Related to Bug #3183: BSC_Tests.ttcn lacks tests for BSSMAP Cipher Mode Control added

#4 Updated by laforge 2 months ago

  • Related to Bug #3184: BTS_Tests.ttcn is lacking test for encryption added

#5 Updated by neels 2 months ago

  • Related to Bug #2947: OsmoMSC crashes with A5/3 configured and MS sending no Classmark 2 in LU Request added

#6 Updated by neels 2 months ago

We still have a problem with A5/3, namely that the indication whether A5/3 is
supported is not contained in the classmark IE received upon Location Updating.
Recently, a code change was introduced that ensures the ciphering we initiate
is indeed supported by the MS, which of course denies A5/3 if we don't have the
information that A5/3 is indeed supported.
http://git.osmocom.org/osmo-msc/commit/?id=71330720b6efdda2fcfd3e9c0cb45f89e32e5670

What is needed here is that the MSC sends a Classmark Request to the BSS, so
that we will subsequently receive a Classmark Update containing the A5/3
support indicator.

In practice, we have thus broken A5/3 until this gets implemented. This was
mentioned in issue #2947, but I notice now that unfortunately the Classmark
Request part was lost in resolving the segfault part.

Thanks for re-raising this.

#7 Updated by neels 2 months ago

  • Related to Bug #3186: cipher mode reject may be sent with invalid cause code added

#8 Updated by neels 2 months ago

  • Related to Bug #3187: rx cipher mode reject from BSS broken added

#9 Updated by laforge about 2 months ago

On Thu, Apr 19, 2018 at 12:52:14PM +0000, neels [REDMINE] wrote:

What is needed here is that the MSC sends a Classmark Request to the BSS, so
that we will subsequently receive a Classmark Update containing the A5/3
support indicator.

this is only required if the MS is not sending the CLASSMARK CHANGE anyway,
which 99.9% of the phones do.

In practice, we have thus broken A5/3 until this gets implemented. This was
mentioned in issue #2947, but I notice now that unfortunately the Classmark
Request part was lost in resolving the segfault part.

Are you sure that it fails even when CLASSMARK CHANGE is received from the phone?
it contains CM3.

#10 Updated by neels about 2 months ago

I can say for sure that the Samsung S4mini wasn't able to subscribe with A5/3.
IIRC we fail to accept the Classmark Update while the conn is still being established. Need to test for specific details...
I dimly remember to have opened an issue to accept that in osmo-msc, but can't seem to find it anymore.

(btw, about the naming, it seems to be a CLASSMARK CHANGE on Abis, and Classmark Update on BSSMAP)

#11 Updated by laforge about 2 months ago

On Mon, Apr 23, 2018 at 09:57:38PM +0000, neels [REDMINE] wrote:

(btw, about the naming, it seems to be a CLASSMARK CHANGE on Abis, and Classmark Update on BSSMAP)

yes. That's why it makes sense to always prefix with the protocol, such
as "RR CLASSMARK CHANGE". RR CLASSMARK CHANGE can happen both as unidirectional
un-solicited report by the MS, as well as in response to a RR CLASMARK ENQUIRY by
the BSC.

#12 Updated by neels about 2 months ago

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)