Feature #2475
XOR authentication not implemented
100%
Description
We implement COMP128v1, v2 and v3 as well as MILENAGE, but don't implement the XOR algorithm for 2G or 3G, as described in 3GPP TS 34.108 Section 8.1.2
XOR can be handy when testing against test equipment such as core/ran emulators, MS testers or the like.
Related issues
History
#1 Updated by laforge over 2 years ago
Daniel has an incomplete patch for this, please state branch name here to which this was pushed.
#2 Updated by daniel over 2 years ago
#3 Updated by daniel about 2 years ago
- Related to Support #2497: Set up SIM cards with auth algo other than comp128v1 added
#4 Updated by fixeria almost 2 years ago
- Assignee set to fixeria
- % Done changed from 0 to 40
#5 Updated by fixeria almost 2 years ago
- Status changed from New to Feedback
- % Done changed from 40 to 70
I've uploaded a modified version: https://gerrit.osmocom.org/7310/
Comments are welcome ;)
#6 Updated by fixeria almost 2 years ago
A sysmoUSIM-SJS1 was programmed to use XOR auth:
$ sysmo-usim-tool.sjs1.py -a ADM --classic -T XOR-2G:XOR-3G $ sysmo-usim-tool.sjs1.py -a ADM -K daf8d6975b9e1404e359bfcf0c93d55c
All attempts to perform manual XOR authentication are not successful:
$ ./osmo-sim-auth.py -s -r e9a9c0710597421f4363e45a2da051f9
Testing SIM card with IMSI 901700000000001
GSM Authentication
Traceback (most recent call last):
File "./osmo-sim-auth.py", line 125, in <module>
handle_sim(options, rand_bin)
File "./osmo-sim-auth.py", line 75, in handle_sim
print "SRES:\t%s" % b2a_hex(byteToString(ret[0]))
TypeError: 'NoneType' object has no attribute '__getitem__'
$ ./osmo-sim-auth.py -s -r 5635694866c671627c3bb4135e2bf7dc
Testing SIM card with IMSI 901700000000001
GSM Authentication
Traceback (most recent call last):
File "./osmo-sim-auth.py", line 125, in <module>
handle_sim(options, rand_bin)
File "./osmo-sim-auth.py", line 75, in handle_sim
print "SRES:\t%s" % b2a_hex(byteToString(ret[0]))
TypeError: 'NoneType' object has no attribute '__getitem__'
Meanwhile, the tool works fine with comp128v123... Any ideas?
#7 Updated by laforge almost 2 years ago
You need to generate an APDU trace and look at what's happening at the protocol level.
#8 Updated by fixeria almost 2 years ago
GSM Authentication [DBG] ['INTERNAL AUTHENTICATE apdu: A0 88 00 00 10 56 35 69 48 66 C6 71 62 7C 3B B4 13 5E 2B F7 DC', 'sw1, sw2: 6F 00 - checking error: no precise diagnosis', (111, 0), []]
Quick Googling:
6F 00 Command aborted - more exact diagnosis not possible (e.g., operating system error).
#9 Updated by fixeria almost 2 years ago
- Status changed from Feedback to Stalled
Any ideas are welcome...
#10 Updated by laforge about 1 year ago
I should have read this ticket first. There's now an alternative (but equally untested) implementation in the laforge/auth_xor branch of libosmocore.git. It also covers re-sync with AUTS, which Vadims implementation doesn't seem to cover.
I should have done something else :/
#11 Updated by fixeria about 1 year ago
- Assignee deleted (
fixeria)
Let's clarify a bit:
[...] which Vadims implementation doesn't seem to cover.
The initial implementation was written by Daniel, I just corrected a few things :)
No time to work on it now, so I am releasing the assignee...
#12 Updated by fixeria 2 months ago
- Status changed from Stalled to Feedback
- % Done changed from 70 to 90
Please see the updated version: https://gerrit.osmocom.org/#/c/libosmocore/+/7310/.
I migrated @laforge's changes from branch laforge/auth_xor.
Still needs to be tested though...
#13 Updated by fixeria about 2 months ago
- Status changed from Feedback to Resolved
- Assignee set to fixeria
- % Done changed from 90 to 100
Harald just tested the patch and confirmed that the it is correct. Finally merged!
