22 Nov
2012
22 Nov
'12
3:12 p.m.
Hi guys,
i'm still testing the eap-sim authentication and lately i got acceptable results using
a simple flat file containing the triplets of specific SIM cards. Next step will be to
enable the external radius server to use the sysmoBTS database hlr.sqlite3, so the
OpenBSC users (Users using the OpenBSC-GSM Network) can automatically access
to the internet.
i just want to ask if there are any limitations with the sysmocom SIM cards?
In fact, i noticed that by using the sysmocom sim cards, the eap-sim authentication
failed when the RAND values strong randomly chosen were, e.g
046DBA898016454aB3920C58180DA2F5 or e177842fe16c47de84784be1b4141c27.
But when i chose a RAND like this 10101010101010101010101010101010,
0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F or 00000000000000000000000000000000,
the authentication succeeded.
By using an other sim (not from sysmocom) with the same strong and weak RAND
values the authentication always succeeded.
Why does the authentication succeed buy using sysmocom sim card with weak RAND
(10101010101010101010101010101010) and fail by using strong RAND values
(e177842fe16c47de84784be1b4141c27) ?
best regards
Yann
22 Nov
22 Nov
7:13 p.m.
On Thu, Nov 22, 2012 at 03:12:32PM +0100, Yann R. Moupinda wrote:
Hi guys,
Hi,
Why does the authentication succeed buy using sysmocom
sim card with weak RAND
(10101010101010101010101010101010) and fail by using strong RAND values
(e177842fe16c47de84784be1b4141c27) ?
no idea, can you provide an example program (e.g. pySIM based) that illustrates
the issue?
holger
26 Nov
26 Nov
2:19 p.m.
On Thu, Nov 22, 2012 at 7:13 PM, Holger Hans Peter Freyther
<holger(a)freyther.de> wrote:
On Thu, Nov 22, 2012 at 03:12:32PM +0100, Yann R.
Moupinda wrote:
While agreeing that you need to give an example of what goes wrong, I
happen to notice all your "bad" RAND values contains lowercase HEX
characters while your "good" ones only contains uppercase HEX
characters. I dont know if that matters in your application.
But only accepting weak keyes is not logical.
Regards Kugg
Hi guys,
Hi,
Why does the authentication succeed buy using
sysmocom sim card with weak RAND
(10101010101010101010101010101010) and fail by using strong RAND values
(e177842fe16c47de84784be1b4141c27) ?
no idea, can you provide an example program (e.g. pySIM based) that illustrates
the issue?
holger
27 Nov
27 Nov
1:48 p.m.
Hi guys,
> no idea, can you provide an example program (e.g.
pySIM based) that illustrates
> the issue?
I happen to notice all your "bad" RAND
values contains lowercase HEX
characters while your "good" ones only contains uppercase HEX
characters. I dont know if that matters in your application.
But only accepting weak keyes is not logical.
Here the logging information from the Freeradius Server. The Client tries to authenticate
using eap-sim.
In the first case, i used strong RAND values. You can see that the client didn't reply
to the last eap-request
(containing the three RANDs) from Server and the authentication process broke up.
In the second case i used weak RAND and the authentication succeeded.
In both cases i used a Nokia E52 and a Laptop with a sysmocom sim card.
All RAND values included in the eap request/sim/challenge message contain lowercase HEX
characters.
1st case )
Ready to process requests.
rad_recv: Access-Request packet from host 192.168.10.212 port 38803, id=29, length=238
Service-Type = Framed-User
Framed-MTU = 1400
User-Name = "1901700000000654"
NAS-Port-Id = "ap_hotspot"
NAS-Port-Type = Wireless-802.11
Acct-Session-Id = "8220000e"
Acct-Multi-Session-Id =
"00-0C-42-64-41-9D-A8-7E-33-3E-9C-5B-82-20-00-00-00-00-00-0E"
Calling-Station-Id = "A8-7E-33-3E-9C-5B"
Called-Station-Id = "00-0C-42-64-41-9D:YANN"
EAP-Message = 0x020100150131393031373030303030303030363534
Message-Authenticator = 0xcf4e5f6429686cc260b16bd23d82489f
NAS-Identifier = "MT_Yann"
NAS-IP-Address = 192.168.10.212
# Executing section authorize from file /etc/freeradius/sites-enabled/default
+- entering group authorize {...}
rlm_sim_files: authorized user/imsi 1901700000000654
rlm_sim_files: Adding EAP-Type: eap-sim
++[sim_files] returns ok
++[preprocess] returns ok
++[chap] returns noop
++[mschap] returns noop
++[digest] returns noop
[suffix] No '@' in User-Name = "1901700000000654", looking up realm
NULL
[suffix] No such realm "NULL"
++[suffix] returns noop
[eap] EAP packet type response id 1 length 21
[eap] No EAP Start, assuming it's an on-going EAP conversation
++[eap] returns updated
++[files] returns noop
++[expiration] returns noop
++[logintime] returns noop
[pap] WARNING! No "known good" password found for the user. Authentication may
fail because of this.
++[pap] returns noop
Found Auth-Type = EAP
# Executing group from file /etc/freeradius/sites-enabled/default
+- entering group authenticate {...}
[eap] EAP Identity
[eap] processing type sim
[eap] Underlying EAP-Type set EAP ID to 108
++[eap] returns handled
Sending Access-Challenge of id 29 to 192.168.10.212 port 38803
EAP-Message = 0x016c0014120a00000f0200020001000011010100
Message-Authenticator = 0x00000000000000000000000000000000
State = 0x870e2a6987623891aa6e49c2b1bcc9b6
Finished request 0.
Going to the next request
Waking up in 4.9 seconds.
rad_recv: Access-Request packet from host 192.168.10.212 port 50478, id=30, length=287
EAP-Message =
0x026c0034120a000007050000c27cfb1cfa7a257c9c89796e49bca230100100010e05001031393031373030303030303030363534
Message-Authenticator = 0xc691af8b618d9da88f9e289557530f6f
NAS-Identifier = "MT_Yann"
NAS-IP-Address = 192.168.10.212
# Executing section authorize from file /etc/freeradius/sites-enabled/default
+- entering group authorize {...}
rlm_sim_files: authorized user/imsi 1901700000000654
rlm_sim_files: Adding EAP-Type: eap-sim
++[sim_files] returns ok
++[preprocess] returns ok
++[chap] returns noop
++[mschap] returns noop
++[digest] returns noop
[suffix] No '@' in User-Name = "1901700000000654", looking up realm
NULL
[suffix] No such realm "NULL"
++[suffix] returns noop
[eap] EAP packet type response id 108 length 52
[eap] No EAP Start, assuming it's an on-going EAP conversation
++[eap] returns updated
++[files] returns noop
++[expiration] returns noop
++[logintime] returns noop
[pap] WARNING! No "known good" password found for the user. Authentication may
fail because of this.
++[pap] returns noop
Found Auth-Type = EAP
# Executing group from file /etc/freeradius/sites-enabled/default
+- entering group authenticate {...}
[eap] Request found, released from the list
[eap] EAP/sim
[eap] processing type sim
[eap] Underlying EAP-Type set EAP ID to 109
++[eap] returns handled
Sending Access-Challenge of id 30 to 192.168.10.212 port 50478
EAP-Message =
0x016d0050120b0000010d00000123456789abcdef0123456789abcdef0123456789abcdef0123456789abcde00123456789abcdef0123456789abcd180b0500000bffb0f7777b066616d98519e625a531
Message-Authenticator = 0x00000000000000000000000000000000
State = 0x870e2a6986633891aa6e49c2b1bcc9b6
Finished request 1.
Going to the next request
Waking up in 4.9 seconds.
Cleaning up request 0 ID 29 with timestamp +17
Cleaning up request 1 ID 30 with timestamp +17
Ready to process requests.
2nd case )
Ready to process requests.
rad_recv: Access-Request packet from host 192.168.10.212 port 38045, id=42, length=238
Service-Type = Framed-User
Framed-MTU = 1400
User-Name = "1901700000000654"
NAS-Port-Id = "ap_hotspot"
NAS-Port-Type = Wireless-802.11
Acct-Session-Id = "82e0000a"
Acct-Multi-Session-Id =
"00-0C-42-64-41-9D-00-24-D7-0A-B1-2C-82-E0-00-00-00-00-00-0A"
Calling-Station-Id = "00-24-D7-0A-B1-2C"
Called-Station-Id = "00-0C-42-64-41-9D:YANN"
EAP-Message = 0x020100150131393031373030303030303030363534
Message-Authenticator = 0x6c5f2905cc845f4adc2990825cc65dc8
NAS-Identifier = "MT_Yann"
NAS-IP-Address = 192.168.10.212
(0) # Executing section authorize from file /usr/local/etc/raddb/sites-enabled/default
(0) group authorize {
(0) - entering group authorize {...}
(0) [preprocess] = ok
(0) [chap] = noop
(0) [auth_log] = ok
(0) [mschap] = noop
(0) [digest] = noop
(0) suffix : No '@' in User-Name = "1901700000000654", looking up realm
NULL
(0) suffix : No such realm "NULL"
(0) [suffix] = noop
rlm_sim_files: authorized user/imsi 1901700000000654
rlm_sim_files: Adding EAP-Type: eap-sim
(0) [sim_files] = ok
(0) eap : EAP packet type response id 1 length 21
(0) eap : EAP-Identity reply, returning 'ok' so we can short-circuit the rest of
authorize
(0) [eap] = ok
(0) Found Auth-Type = EAP
(0) # Executing group from file /usr/local/etc/raddb/sites-enabled/default
(0) group authenticate {
(0) - entering group authenticate {...}
(0) eap : EAP Identity
(0) eap : processing type sim
(0) eap : Underlying EAP-Type set EAP ID to 206
(0) [eap] = handled
Sending Access-Challenge of id 42 to 192.168.10.212 port 38045
EAP-Message = 0x01ce0014120a00000f0200020001000011010100
Message-Authenticator = 0x00000000000000000000000000000000
State = 0x27d04fcb271e5dceaedc556ddb0c5d7f
(0) Finished request 0.
Waking up in 0.3 seconds.
rad_recv: Access-Request packet from host 192.168.10.212 port 32878, id=43, length=287
EAP-Message =
0x02ce0034120a000007050000d28837f3ec25745202083c21313d8d29100100010e05001031393031373030303030303030363534
Message-Authenticator = 0x5dbd2219a029f2421a86fca4c24974b5
NAS-Identifier = "MT_Yann"
NAS-IP-Address = 192.168.10.212
(1) # Executing section authorize from file /usr/local/etc/raddb/sites-enabled/default
(1) group authorize {
(1) - entering group authorize {...}
(1) [preprocess] = ok
(1) [chap] = noop
(1) [auth_log] = ok
(1) [mschap] = noop
(1) [digest] = noop
(1) suffix : No '@' in User-Name = "1901700000000654", looking up realm
NULL
(1) suffix : No such realm "NULL"
(1) [suffix] = noop
rlm_sim_files: authorized user/imsi 1901700000000654
rlm_sim_files: Adding EAP-Type: eap-sim
(1) [sim_files] = ok
(1) eap : EAP packet type response id 206 length 52
(1) eap : No EAP Start, assuming it's an on-going EAP conversation
(1) [eap] = updated
(1) [files] = noop
(1) [expiration] = noop
(1) [logintime] = noop
(1) pap : WARNING! No "known good" password found for the user. Authentication
may fail because of this.
(1) [pap] = noop
(1) Found Auth-Type = EAP
(1) # Executing group from file /usr/local/etc/raddb/sites-enabled/default
(1) group authenticate {
(1) - entering group authenticate {...}
(1) eap : Request found, released from the list
(1) eap : EAP/sim
(1) eap : processing type sim
eap: EAP-Sim length = 20
eap: ID_Len = 4
eap: EAP-SIm length chosen = 32
eap: EAP-Sim length = 4
eap: ID_Len = 4
eap: EAP-SIm length chosen = 32
eap: EAP-Sim length = 20
eap: ID_Len = 16
eap: EAP-SIm length chosen = 32
(1) eap : Underlying EAP-Type set EAP ID to 207
(1) [eap] = handled
Sending Access-Challenge of id 43 to 192.168.10.212 port 32878
EAP-Message =
0x01cf0050120b0000010d0000000000000000000000000000000000000f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0ff0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f00b050000c13e9c1dcc448cf3e4028e30d28e43c4
Message-Authenticator = 0x00000000000000000000000000000000
State = 0x27d04fcb261f5dceaedc556ddb0c5d7f
(1) Finished request 1.
Waking up in 0.2 seconds.
Waking up in 4.5 seconds.
rad_recv: Access-Request packet from host 192.168.10.212 port 37021, id=44, length=263
EAP-Message = 0x02cf001c120b00000b050000eeaec0aaf45ca982cb310428eb838a8e
Message-Authenticator = 0x3ca71ae6141b80753b4ccb402cc71e5f
NAS-Identifier = "MT_Yann"
NAS-IP-Address = 192.168.10.212
(2) # Executing section authorize from file /usr/local/etc/raddb/sites-enabled/default
(2) group authorize {
(2) - entering group authorize {...}
(2) [preprocess] = ok
(2) [chap] = noop
(2) [auth_log] = ok
(2) [mschap] = noop
(2) [digest] = noop
(2) suffix : No '@' in User-Name = "1901700000000654", looking up realm
NULL
(2) suffix : No such realm "NULL"
(2) [suffix] = noop
rlm_sim_files: authorized user/imsi 1901700000000654
rlm_sim_files: Adding EAP-Type: eap-sim
(2) [sim_files] = ok
(2) eap : EAP packet type response id 207 length 28
(2) eap : No EAP Start, assuming it's an on-going EAP conversation
(2) [eap] = updated
(2) [files] = noop
(2) [expiration] = noop
(2) [logintime] = noop
(2) pap : WARNING! No "known good" password found for the user. Authentication
may fail because of this.
(2) [pap] = noop
(2) Found Auth-Type = EAP
(2) # Executing group from file /usr/local/etc/raddb/sites-enabled/default
(2) group authenticate {
(2) - entering group authenticate {...}
(2) eap : Request found, released from the list
(2) eap : EAP/sim
(2) eap : processing type sim
eap: EAP-Sim length = 20
eap: ID_Len = -1219474647
eap: EAP-SIm length chosen = 32
MAC check succeed
(2) eap : Underlying EAP-Type set EAP ID to 208
(2) eap : Freeing handler
(2) [eap] = ok
(2) # Executing section post-auth from file /usr/local/etc/raddb/sites-enabled/default
(2) group post-auth {
(2) - entering group post-auth {...}
(2) [exec] = noop
Sending Access-Accept of id 44 to 192.168.10.212 port 37021
MS-MPPE-Recv-Key = 0x9aca37a3e1743dc8c4326d6ed4e3f7e5f4178abc80cb953e6686ef57ba470624
MS-MPPE-Send-Key = 0x1b94a8624cea0d23c245b15cc227428d05202328550aa5413296d9de1039337c
EAP-Message = 0x03d00004
Message-Authenticator = 0x00000000000000000000000000000000
User-Name = "1901700000000654"
4:48 p.m.
On Tue, Nov 27, 2012 at 01:48:12PM +0100, Yann R. Moupinda wrote:
Hi,
you will need to reduce the issue but I don't think it is the RAND. Use
osmo-auc-gen to generate the RAND, Sres and Kc and run the gsm algorithm
and compare the result.
The second half is done in the following script:
#!/usr/bin/env python
from pySim.transport.serial import SerialSimLink
from pySim.commands import SimCardCommands
from pySim.transport.pcsc import PcscSimLink
from pySim.utils import swap_nibbles
#sl = SerialSimLink(device='/dev/ttyUSB0', baudrate=9600)
sl = PcscSimLink(0) #opts.pcsc_dev)
sc = SimCardCommands(sl)
sl.wait_for_card()
# Print IMSI
print sc.read_binary(['3f00', '7f20', '6f07'])
(res,_) = sc.read_binary(['3f00', '7f20', '6f07'])
print swap_nibbles(res)[3:]
# The RAND as printed by osmo-auc-gen
(res, _) = sc.run_gsm('58 f7 46 05 c9 da a9 2b 15 e7 db 7e fd 53 02
3a'.replace(' ', ''))
# SRES and Kc concatinated
print res == ('29 fd 55 45 d5 ab 99 85 56 13 b4 00'.replace(' ',
''))
I think the above RAND matches your classification for 'strong', it is returns
the expected result. Make sure that you are using the right A3A8 algorithm in
your setup, I don't think it has anything to do with the RAND.
holger
But only
accepting weak keyes is not logical.
All RAND values included in the eap request/sim/challenge message contain lowercase HEX
characters.
4 Jan
4 Jan
12:48 p.m.
New subject: sysmoBTS doesn't start
Hi guys,
I have a sysmoBTS from sysmocom and last time i used it (for 3 weeks) everything was
working well.
Yesterday i wanted to do some tests and the device didn't start up.
I think there are some problems by the booting process, here are the logging data:
Board revision: C.3
Initializing NAND flash:
Bypassing ECC checks
ID:0xA1, 8-bit bus
Blocks: 0x00400, Pages/block: 0x040, Bytes per page: 0x0800
BootMode = NAND
I_ME
UART_TIMEOUT
Image infos: Magic = 0xA1ACED77, Entry = 0x84000000, Pages = 0x000000B9, Load =
0x84000000
Starting app at: 0x84000000
U-Boot 2011.12-g5ee9b97 (Aug 15 2012 - 21:35:37)
Cores: ARM 405 MHz, DSP 810 MHz
DDR: 189 MHz
I2C: ready
DRAM: 256 MiB
WARNING: Caches not enabled
NAND: 128 MiB
Bad block table found at page 65472, version 0x01
Bad block table found at page 65408, version 0x01
nand_read_bbt: Bad block at 0x000000880000
*** Warning - bad CRC, using default environment
In: serial
Out: serial
Err: serial
Net: DaVinci-EMAC
Creating 1 MTD partitions on "nand0":
0x000000100000-0x000008000000 : "mtd=3"
UBI: attaching mtd1 to ubi0
UBI: physical eraseblock size: 131072 bytes (128 KiB)
UBI: logical eraseblock size: 129024 bytes
UBI: smallest flash I/O unit: 2048
UBI: sub-page size: 512
UBI: VID header offset: 512 (aligned 512)
UBI: data offset: 2048
UBI: attached mtd1 to ubi0
UBI: MTD device name: "mtd=3"
UBI: MTD device size: 127 MiB
UBI: number of good PEBs: 1011
UBI: number of bad PEBs: 5
UBI: max. allowed volumes: 128
UBI: wear-leveling threshold: 4096
UBI: number of internal volumes: 1
UBI: number of user volumes: 1
UBI: available PEBs: 0
UBI: total number of reserved PEBs: 1011
UBI: number of PEBs reserved for bad PEB handling: 10
UBI: max/mean erase counter: 71/16
has anybody an idea how i can overcome this problem ?
best regards
Yann
4132
days inactive
4175
days old
5 comments
3 participants
participants (3)
-
Christoffer Jerkeby -
Holger Hans Peter Freyther -
Yann R. Moupinda