Hi Masashi, I think the main problem is how to get Kc and SRES from SIM via RIL interface in this architecture. Even there is this solution which you talked about, we still need those RIL requests which shao-hang mentioned to get Kc and SRES.
However, I think we don't need to worry about this problem now. Every vendor has its own wpa_supplicate and RILD. They should create a connection between wpa_supplicate and RILD to transfer those authentication information for supporting EAP-SIM. Best Regards, Ken Chang -- Mozilla Taiwan Email:[email protected] Tel:+886-2-87861100 Ext.303 Mobile:+886-952-391521 ----- Original Message ----- > From: "Masashi Honma" <[email protected]> > To: "Shao-Hang Kao" <[email protected]> > Cc: [email protected], "dev-b2g" <[email protected]> > Sent: Wednesday, December 18, 2013 8:14:57 PM > Subject: Re: [b2g] EAP-SIM Architecture proposal > > I found a new functionality on wpa_supplicant master branch. > > http://hostap.epitest.fi/gitweb/gitweb.cgi?p=hostap.git;a=commitdiff;h=a5d44ac0839358f25c4586de58b4125a21e2c7b6 > http://hostap.epitest.fi/gitweb/gitweb.cgi?p=hostap.git;a=commitdiff;h=569ccf719f794d5df243f86892668995ab6d3868 > http://hostap.epitest.fi/gitweb/gitweb.cgi?p=hostap.git;a=commitdiff;h=db13605816d4ab1e15a05129e3f30316dffad67a > > If we port this patch, We can do EAP-SIM/AKA/AKA' without pcsc_func.c > modification. > > Indeed this patch is not included in wpa_supplicant in the Android. > > But this patch will be added in future release. > > So I think backporting this patch and use this is better solution. > > Regards, > Masashi Honma. > > 2013/9/30 Shao-Hang Kao <[email protected]>: > > cc mvines, > > > > we proposed another architecture without patching wpa_supplicant but > > require 3 RIL requests which may not supported on all devices: > > > > // UICC Secure Access > > this.REQUEST_SIM_OPEN_CHANNEL = 121; > > this.REQUEST_SIM_CLOSE_CHANNEL = 122; > > this.REQUEST_SIM_ACCESS_CHANNEL = 123; > > > > any suggestions? > > > > Best Regards, > > S.H. Kao > > Software Engineer, Mozilla Taiwan > > > > ----- Original Message ----- > > From: "Shao-Hang Kao" <[email protected]> > > To: [email protected] > > Sent: Monday, September 30, 2013 6:26:24 PM > > Subject: Re: [b2g] EAP-SIM Architecture proposal > > > > Just tried SIM_ACCESS_CHANNEL on Inari and looks like it's not supported: > > > > I/Gecko ( 369): -*- RadioInterface[0]: Received message from worker: > > {"channel":0,"apdu":{"cla":0,"command":164,"p1":4,"p2":0,"p3":0},"rilMessageToken":342,"rilMessageType":"iccExchangeAPDU","rilRequestType":123,"rilRequestError":6,"error":"RequestNotSupported"} > > > > If it's impossible to implement SIM_OPEN/ACCESS/CLOSE_CHANNEL with SIM_IO > > then I think it's may be almost impossible to implement EAP-SIM without a > > patch of wpa_supplicant. > > > > Best Regards, > > S.H. Kao > > Software Engineer, Mozilla Taiwan > > > > ----- Original Message ----- > > From: [email protected] > > To: [email protected] > > Sent: Friday, September 27, 2013 5:32:10 PM > > Subject: Re: [b2g] EAP-SIM Architecture proposal > > > > Hi, > > > > I'm proposing an alternative architecture without maintaining a patch over > > wpa_supplicant. > > > > Using a similar architecture to the project seek-for-android[1], we need a > > pcsc daemon (pcscd) from pcsc-lite running on B2G as a fake card reader so > > wpa_supplicant can communicate with it when EAP-SIM authentication needed. > > With some modifications in pcscd we can implement these operations (as an > > SmartCardInterface) with 3 RIL requests: SIM_OPEN_CHANNEL, > > SIM_CLOSE_CHANNEL and SIM_ACCESS_CHANNEL, and redirect them to chrome > > process via unix domain socket. For the detailed visualization of this > > architecture please refer to [2]. > > > > There're some potential problems: > > a. we need 3 requests mentioned above but the target may not support them, > > so far we only know nexus-s have these implemented and not sure for other > > devices. possible solution: use SIM_IO to implement them (reference: [3]) > > b. we have to make sure the socket connection between pcscd & chrome > > process is secured, otherwise someone my pretent they're 'fake pcscd' to > > connect and access sim card with open/close/access channel operations > > (pointed out by Yoshi Huang), possible solutions: > > 1. the domain socket will be opened in root privilege, so processes > > without root privilege can't access it and it's safe on devices not > > rooted. I'm not sure how secure we should achieve and have no idea if > > this is enough to solve this problem. > > 2. Further more, we can parse the APDU received with SIM_ACCESS_CHANNEL > > (in chrome process) and only allow EAP-SIM related commands to > > execute, basically they will be get imsi & authentication related > > commands (I'm not sure about the exact commands, need to do further > > tests) > > 3. maybe some challenge based protocols suggested by Henry Chang > > > > Any problems or suggestions are welcome, Thanks! > > > > S.H. Kao > > > > [1] http://code.google.com/p/seek-for-android/wiki/EapSimAka > > [2] > > https://docs.google.com/presentation/d/1CK6aKzw5jhAjNopqrmifGHDIgvJsfGP1bXmpwk-Z0aw/edit?usp=sharing > > [3] https://bugzilla.mozilla.org/show_bug.cgi?id=921320 > > _______________________________________________ > > dev-b2g mailing list > > [email protected] > > https://lists.mozilla.org/listinfo/dev-b2g > > _______________________________________________ > > dev-b2g mailing list > > [email protected] > > https://lists.mozilla.org/listinfo/dev-b2g > > _______________________________________________ > > dev-b2g mailing list > > [email protected] > > https://lists.mozilla.org/listinfo/dev-b2g > _______________________________________________ > dev-b2g mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-b2g > _______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
