Project

General

Profile

Bug #3043

A5/3 encryption fails

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

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

0%

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 - http://lists.osmocom.org/pipermail/openbsc/2018-March/011811.html (11.4 KB) jbruckner, 03/08/2018 10:12 AM

a5_1_3_with_LU_Auth.pcapng - http://lists.osmocom.org/pipermail/openbsc/2018-March/011816.html (94.1 KB) jbruckner, 03/08/2018 10:12 AM

a5_3.pcapng - http://lists.osmocom.org/pipermail/openbsc/2018-March/011811.html (68 KB) jbruckner, 03/08/2018 10:12 AM

attach_a5_0_1_3.pcapng - http://lists.osmocom.org/pipermail/openbsc/2018-March/011823.html (85.6 KB) jbruckner, 03/08/2018 10:12 AM

a5_3_Cipher_Mode_Reject.txt Magnifier (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 Control New 04/18/2018
Related to OsmoBTS - Bug #3184: BTS_Tests.ttcn is lacking test for encryption New 04/18/2018
Related to OsmoMSC - Bug #2947: OsmoMSC crashes with A5/3 configured and MS sending no Classmark 2 in LU Request Resolved 02/15/2018
Related to OsmoBSC - Bug #3186: cipher mode reject may be sent with invalid cause code New 04/19/2018
Related to OsmoMSC - Bug #3187: rx cipher mode reject from BSS broken New 04/19/2018

History

#1 Updated by jbruckner 5 days ago

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

#2 Updated by laforge 5 days 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 5 days ago

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

#4 Updated by laforge 5 days ago

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

#5 Updated by neels 4 days 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 4 days 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 4 days ago

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

#8 Updated by neels 4 days ago

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

#9 Updated by laforge 3 days 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.

Also available in: Atom PDF