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
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
On Thu, Nov 22, 2012 at 7:13 PM, Holger Hans Peter Freyther <holger@freyther.de> wrote:
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
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,
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"
On Tue, Nov 27, 2012 at 01:48:12PM +0100, Yann R. Moupinda wrote: Hi,
But only accepting weak keyes is not logical.
All RAND values included in the eap request/sim/challenge message contain lowercase HEX characters.
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
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
participants (3)
-
Christoffer Jerkeby -
Holger Hans Peter Freyther -
Yann R. Moupinda