Support #2497
openSet up SIM cards with auth algo other than comp128v1
Added by neels over 6 years ago. Updated over 4 years ago.
0%
Description
It appears all SIM cards currently in the osmo-gsm-tester rnd and prod setup are configured to use XOR auth.
(Edited)
We saw auth failing, but succeeding when setting the HLR to XOR.
XOR is currently not available, and the only reason that choosing XOR would lead to success is that the HLR does not provide any auth data and the MSC continues without authentication.
For authentication related test runs, we need to set 'network' / 'authentication required' in the osmo-msc.cfg,
and we should probably also set 'encryption a5 3' to see that the negotiated kc works for encryption.
We do not support XOR, and we should have more diverse auth algos in place.
Best would be one using Milenage (the 2G variant), one using comp128v1, one using comp128v3.
We then need to adjust the resources.conf and can set up different auth tests for the various algos.
Related issues
Updated by neels over 6 years ago
The important part is that we test both UMTS auth = 2G-Milenage, as well as the old GSM plain way, say comp128v3.
If comp128v3 works in the osmo-gsm-tester and the other algos pass the 'make check' tests, there is no reason why those should fail in the osmo-gsm-tester.
Note: the 2G-Milenage will only work with the new VLR, i.e. only in the AoIP tests.
Updated by laforge over 6 years ago
- 2G auth with classic 2G algorithm (COMP128x) over 2G bearer
- 2G auth with classic 2G algorithm (COMP128x) over 3G bearer, i.e. SIM
Card with no UICC application present (sysm-usim-util can remove it) - 3G auth with MILENAGE over 3G bearer
- 2G auth derived from MILENAGE over any bearer (shouldn't matter).
I'm not sure if this must be done as part of osmo-gsm-tester, as
(without using remote sim features) we cannot easily swap sim cards
and/or reprogram them on the fly.
This should be possible to test with osmo-bts-virtual + osmocom-bb, or
even by some more direct way where a small sim-card using utility
program talks BSSAP to the MSC. Whatever is the method of least effort.
BTS+BSC have no influence on the authentication, it's all in
MSC/VLR/HLR, so I don't think it's important to do this over real or
virtual radio interface.
Regarding 3G bearer: Do we yet have tickets for osmo-gsm-tester to
include 3G support testing with e.g. nano3G + osmo-hnbgw ?
Updated by neels over 6 years ago
laforge wrote:
I would argue we should ideally test:
[...]
I'm not sure if this must be done as part of osmo-gsm-tester, as
ok, so having XOR in the gsm-tester doesn't matter?
I think I'd like to have at least a little diversity in auth algos there, because we can.
Regarding 3G bearer: Do we yet have tickets for osmo-gsm-tester to
include 3G support testing with e.g. nano3G + osmo-hnbgw ?
no, and no focus on that so far, but makes sense increasingly. Let's get settled with the new repositories first and take it from there...
Updated by laforge over 6 years ago
Hi Neels,
On Thu, Sep 07, 2017 at 04:57:56AM +0000, neels [REDMINE] wrote:
I'm not sure if this must be done as part of osmo-gsm-tester, as
ok, so having XOR in the gsm-tester doesn't matter?
I don't think so, at least for sure not if we implement related testing
by some other means. As indicated, only SIM card and MSC+HLR (or:
SGSN+HLR) are involved in this anyway. It should be rather simple to
"fake" a LU / IMSI ATTACH on the A, Iu or Gb interface to trigger related
authentication transaction from a machine with a few SIM card readers
attached. This looks much easier to really test all relevant
configurations than exploding the number of (lengthy) tests on osmo-gsm-tester
and to add so many different SIM variants + related modems.
I think I'd like to have at least a little diversity in auth algos there, because we can.
Sure, if you'd like and if it doesn't significantly complicate the setup or configuration?
Updated by pespin over 6 years ago
I think I'd like to have at least a little diversity in auth algos there, because we can.
Sure, if you'd like and if it doesn't significantly complicate the setup or configuration?
It should work transparently as we already have support to subscribe each modem based on its auth algo set in the configuration file. We can even pick a modem based on its auth algo configured in the SIM card. So it's mostly spending time on changing the SIM information (never done that but I've been told is easy), then we test them for free with other tests, even if we don't spend time testing the feature explicitly.
Updated by daniel over 6 years ago
- Related to Feature #2475: XOR authentication not implemented added
Updated by pespin over 5 years ago
We are currently using algo "comp128v1" for all modems. Configuring each subscriber to use another algo in osmo-gsm-tester only requires a one-line change for each subscriber/modem in the config file.
I'm not sure if then we also require to change the SIMcard config. If that's the case, someone with physical access to the setup needs to take care of that part.
Updated by neels over 5 years ago
This issue came about due to mismatching enum values for the auth algos, so that it looked in the logs like the tester would use XOR, while the cards were in fact using COMP128vN all the time. The XOR part of this issue is moot.
To have diverse auth algos, we need to program the SIM cards in the hardware setup. If we want that. We probably do want that, but it's not super urgent, is it.
I'd suggest testing at least COMP128v3 and UMTS Milenage (yes, on GSM), maybe also COMP128v1
Updated by pespin over 5 years ago
WE should then assign this ticket to somebody who can program the simcards in there. Once that's done, I can change the config in osmo-gsm-tester to use the new algo.
Updated by laforge over 5 years ago
If the modems suport AT+CSIM or +CRSM it may even be possible to do any reprogramming "live"
while the cards are still in the modems. But I guess, if at all, we should invest time
into using "remote" SIM cards at that point.
Updated by pespin over 5 years ago
- Status changed from New to Feedback
- Assignee changed from pespin to laforge
I'm not sure how to proceed with this task then. Can we decide what do we want to do? I thought someone had to flash the simcard physically to change the IMSI, but if it can be done through the modem, I can then investigate that.
So let's take one of the 3 possibilities:
A- Investigate how to change algo parameters through modem AT commands (then assigned to me or someone else as we see).
B- Program simcards using pySim or whatever, then issue needs to be assigned to somebody with physical access to simcards
C- Setup remoteSim setup for the modems. I guess in first place we require some HW setup, so then this task should be assigned to somebody else.
Updated by laforge over 5 years ago
- Status changed from Feedback to Stalled
- Assignee changed from laforge to daniel
pespin wrote:
So let's take one of the 3 possibilities: [...]
B- Program simcards using pySim or whatever, then issue needs to be assigned to somebody with physical access to simcards
Ok, then let's go for this. daniel, please take care of this, coordinating with pespin to ensure the cards are changed at the same time as the configuration files of osmo-gsm-tester are changed.
Updated by daniel over 4 years ago
- Subject changed from Set up SIM cards with auth algo other than XOR to Set up SIM cards with auth algo other than comp128v1
Ok, so to summarize:
- All cards in osmo-gsm-tester are using comp128v1 at the moment
- We want to test different auth algos - comp128v1, v3 and milenage (for 2G and 3G?)
- 3G auth support in osmo-gsm-tester is not present (the HLR auc_3g table is never populated)
If someone points me to the card in the osmo-gsm-tester (or tells me which imsi to look for) I can change the auth algo and also program in a K/OPC.
