Project

General

Profile

Actions

Feature #2457

closed

osmo-gsm-tester: add test case: validate "encryption" & "authentication" vty parameter

Added by pespin over 6 years ago. Updated over 6 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Target version:
-
Start date:
08/22/2017
Due date:
% Done:

100%

Spec Reference:

Description

nitb/msc have the "encryption" parameter which states which kind of authentication is requested by the core network.

Values net / encryption a5 (0|1|2|3):
- encryption a5 0 <-- no encryption.
- encryption a5 1
- encryption a5 2 <-- deprecated, we should check that we reject this.
- encryption a5 3

Currently osmo-gsm-tester uses "encryption a5 0" by default, which means ki values are not used.

We should add new tests to check different algorithms in use.

For AoIP builds, we also have net / 'authentication (optional|required)'.

Both are defined in common_cs_vty.c


Related issues

Related to OsmoMSC - Feature #2460: Change "encryption" VTY parameter to allow more than one cipherResolvedlaforge08/24/2017

Actions
Related to OsmoBSC - Feature #2461: Improve "encryption" VTY parameterResolvedlaforge08/24/2017

Actions
Actions #1

Updated by pespin over 6 years ago

  • Status changed from New to In Progress
  • % Done changed from 0 to 20

Added bits required to test this part in https://gerrit.osmocom.org/#/c/3582/ and https://gerrit.osmocom.org/#/c/3583/

I also have some tests locally to test it but I see some buggy behavior still to investigate.

Actions #2

Updated by pespin over 6 years ago

One more test added for the infra to test this: https://gerrit.osmocom.org/#/c/3584/

And I still lack a "subscriber_remove" API in hlr to have encryption tests working in AoIP. I pushed the tests I created in branch pespin/encryption of osmo-gsm-tester.

Issues I saw so far:
- On NITB, there seems to be some rance condition which makes it sometimes accept location updates instead of rejecting or asking for a challenge.
- Even if NITB/MSC rejects the registering after failed challenge (due to using wrong KI), ofono signals status "registered" for up to a few seconds before going back to unregisterd. Sometimes it signals denied. This seems to be related the issue in qmi/ofono we already saw, in which QMI sends "registered" signal too soon (lynxis this may be interesting for you). IMHO this is wrong and it should never be shown as "registered".

Actions #3

Updated by pespin over 6 years ago

  • Blocked by Bug #2458: ofono: status=registered signal sent to ofono users before being attached added
Actions #4

Updated by pespin over 6 years ago

  • Subject changed from osmo-gsm-tester: add test case: validate "encryption" vty parameter to osmo-gsm-tester: add test case: validate "encryption" & "authentication" vty parameter
Actions #5

Updated by pespin over 6 years ago

  • % Done changed from 20 to 50

I implemented generic operations required for the tests like deleting subscribers (to re-register them with correct KI after registering first with wrong KI).

I also added support for the "authentication" parameter.

As soon as I use "authentication required" in osmo-msc, the modems cannot register, they are rejected. I can see the HLR generating the challenges and expected responses, with correct KI and IMSI. I can see the request with the challenge being sent to the modem. However, the Response to the challenge from the modem seems different than the "sres" I see in the HLR log, which probably explain why it receives a Reject afterwards.

This happens even with encryption a5 0.

All updated suite tests can be found in osmo-gsm-tester pespin/encryption branch.

Actions #6

Updated by pespin over 6 years ago

It seems the sim cards we are using in the setup are using XOR algorithm, not COMP128v1. Once I change database specifying to use XOR for those auth works fine.

Let's add a "algo" param for each object of type modem in osmo-gsm-tester. Also support setting a default value. This can then be obtained by using modem.algo(), and we can pass that to subscriber_add algo parameter.

Actions #7

Updated by pespin over 6 years ago

  • Related to Feature #2460: Change "encryption" VTY parameter to allow more than one cipher added
Actions #8

Updated by pespin over 6 years ago

  • Related to Feature #2461: Improve "encryption" VTY parameter added
Actions #9

Updated by pespin over 6 years ago

  • % Done changed from 50 to 80
I added more code required (set encryption attr in bsc, auth_algo attr in modem). After that, I have 3 working tests which have been pushed to gerrit. These 3 test check if a modem can register when the core is configured with:
  1. authentication optional and encryption a5 0 (off).
  2. authentication required and encryption a5 0 (off).
  3. authentication required and encryption a5 1 (on).

Those 3 tests are to be used with AoIP setup (osmo-msc). I still see issues when using osmo-nitb: sometimes the modem is accepted even if the KI is incorrect, ie no auth is done.

I have extra tests for NITB and for AoIP testing a52 and a53 (which are not working) in branch pespin/encryption and I won't submit those for now.

Actions #10

Updated by pespin over 6 years ago

  • Blocked by deleted (Bug #2458: ofono: status=registered signal sent to ofono users before being attached)
Actions #11

Updated by pespin over 6 years ago

  • Status changed from In Progress to Resolved
  • % Done changed from 80 to 100

I think we can close this one, what we have is enough for a first round.

Tests in NITB seem to have some issue, but as far as I was told, auth code has changed from nitb->msc, and nitb is going to be deprecated soon anyway, so let's support testing this in AoIP builds for now.

Actions #12

Updated by laforge over 6 years ago

  • Status changed from Resolved to Closed
Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)