> But after tracing wpa_supplicant code, we found that we cannot retrieve the > notification socket in pcsc_funcs.c. > There is no API to get it and wpa_supplicant neither pass any information > through above APIs for pcsc_func to > retrieve the notification socket.
I already tried to pass UNIX domain socket file descriptor to scard_init(). But it doesn't work. To make it work, I need to make another UDP socket. Dimi Lee, could you make a thread on Bugzilla for this discussion ? Dimi Lee, could you review my patch (https://bugzilla.mozilla.org/show_bug.cgi?id=890694) ? Regards, Masashi Honma. 2013/8/2 Dimi Lee <d...@mozilla.com>: > Hi Jonas, > I will explain pcsc_funcs first and then propose possible solution in > current architecture if we want to use > existing wifi worker. > > pcsc stands for Personal Computer/Smartcard Interface. > The main usage of this component(pcsc_funcs.c) is it provide an interface > for wpa_supplicant to access USIM/GSM SIM. > And following is the APIs it provides: > > - struct scard_data * scard_init(scard_sim_type sim_type) > - void scard_deinit(struct scard_data *scard); > - int scard_set_pin(struct scard_data *scard, const char *pin); > - int scard_get_imsi(struct scard_data *scard, char *imsi, size_t *len); > - int scard_gsm_auth(struct scard_data *scard, const unsigned char *_rand, > unsigned char *sres, unsigned char *kc); > - int scard_umts_auth(struct scard_data *scard, const unsigned char *_rand, > const unsigned char *autn, unsigned char *res, size_t *res_len, unsigned char > *ik, unsigned char *ck, unsigned char *auts); > > and pcsc component will be used when wpa_supplicant is doing EAP-SIM / > EAP-AKA authentication. > As you can see scard_gsm_auth & scard_umts_auth are the authentication APIs. > > The original implementation of pcsc_funcs.c access SIM through "card > reader", it will need to link another package > called pcsc-lite and acsess SIM through card reader. > > But in our B2G we don't support card reader and we don't need such a > complicate way to get SIM information because > we can access SIM simply through RIL module. So the architecture diagram > show we modify pcsc_funcs to communicate > with WifiWorker directly and then access SIM through RadioInterfaceLayer.js. > > The best way to communicate with WifiWorker is reuse original notification > IPC channel established between > WifiWorker and wpa_supplicant so we will not need to create another worker > thread listen on another IPC channel. > > But after tracing wpa_supplicant code, we found that we cannot retrieve the > notification socket in pcsc_funcs.c. > There is no API to get it and wpa_supplicant neither pass any information > through above APIs for pcsc_func to > retrieve the notification socket. > > So if we want to re-use existing worker, i will propose modify the > scard_init API and add another parameter to let > wpa_supplicant pass it's context, and then in pcsc_func we can retrieve > notification socket through the context. > The drawback of this solution is that we changed the API, so it means we > need modify the code of wpa_supplicant. > > In this case, maybe we will need to discuss with qualcomm and apply a > mozilla patch to qualcomm wpa_supplicant, so > the wpa_supplicant will use the new API. Or we will need to maintain our > own wpa_supplicant in our repository, but > i think its a pretty bad idea to maintain our own wpa_supplicant. > > Please let me know your suggestion, thanks > > Best regards > Dimi > > ----- Original Message ----- > From: "Jonas Sicking" <jo...@sicking.cc> > To: "Dimi Lee" <d...@mozilla.com> > Cc: "Kyle Machulis" <kmachu...@mozilla.com>, "dev-b2g" > <dev-b2g@lists.mozilla.org> > Sent: Friday, August 2, 2013 12:37:53 PM > Subject: Re: [b2g] EAP-SIM Architecture proposal > > On Thu, Aug 1, 2013 at 2:33 AM, Dimi Lee <d...@mozilla.com> wrote: >> Hi Jonas, >> For first question, i would say we need another worker thread listening on >> the EAP >> IPC channel. We cannot use original wpa_supplicant IPC channel because in >> pcsc_funcs >> component, we cannot access the IPC socket already established between >> wifi worker >> and wpa_supplicant. pcsc_funcs component is fairly independent with main >> wpa_supplicant >> source code, so in that component, there is no way to get the ipc socket >> from wpa_supplicant. > > I don't really know what pcsc_funcs is or does so I don't really > understand the above. > > However starting another worker isn't really an option here I think. > Workers simply use too much memory. So we need to either figure out > how to do this from the main thread, or from the existing wifi worker. > >> The above reason is also the answer for the second question you mentioned. >> Because pcsc_funcs >> is fairly independent, we just need to implement the five API in >> pcsc_funcs component. >> No matter how OEM modify their own wpa_supplicant source. As long as they >> do not add/remove >> API for pcsc_funcs, the EAP-SIM will work correctly. > > Sounds good. I still think we need to add it to the FirefoxOS > certification suite (once that's fully established) that EAP-SIM needs > to be tested, and how to test it. This is something we should do for > the other wifi functionality too. > > / Jonas > >> >> Please let me know if you still have any concern or question. >> >> BR >> Dimi >> >> ----- Original Message ----- >> From: "Jonas Sicking" <jo...@sicking.cc> >> To: "Dimi Lee" <d...@mozilla.com>, "Kyle Machulis" <kmachu...@mozilla.com> >> Cc: "dev-b2g" <dev-b2g@lists.mozilla.org> >> Sent: Thursday, August 1, 2013 3:30:18 PM >> Subject: Re: [b2g] EAP-SIM Architecture proposal >> >> Hi Dimi, >> >> I have a couple of concerns here. >> >> First off, my understanding is that this doesn't create any new >> workers, right? This only adds additional code to the already existing >> worker that we are using to communicate with the wpasupplicant. Is >> this correct? If so that's fine. We need to avoid adding more workers, >> but adding functionality to existing ones sounds fine for now. >> >> I'm also worried about having to modify the wpa supplicant. My >> understanding is that OEMs ship their own wpa supplicant quite often. >> How will we ensure that this feature will still work on a shipped >> device? >> >> Other than that I don't have much input. But I'm very much not an >> expert in this code. cc'ing Kyle who have might more opinions. >> >> / Jonas >> >> >> >> On Wed, Jul 3, 2013 at 12:58 AM, Dimi Lee <d...@mozilla.com> wrote: >>> Hi all, >>> Currently taipei team are implementing the EAP-SIM WIFI authentication >>> protocol for B2G device. >>> We want to share current architecture to know if there are any problem or >>> suggestion of this design. >>> So any suggestion or question is welcome. >>> >>> I will briefly describe what is EAP-SIM first then introduce how we are >>> going to implement it. >>> >>> What is EAP-SIM? >>> >>> EAP-SIM protocol was developed by 3GPP and it is an authentication method >>> based on Extensible Authentication >>> Protocol(EAP) framework. It use SIM authentication algorithm between the >>> cleint and the Authentication server >>> to provide mutual authentication. >>> The basic idea is each SIM card contain a private key and this key is also >>> stored in operator's home location >>> register(HLR) which can be identified by IMSI of SIM card. So device send >>> it's IMSI to authentication server >>> so server can retrieve the private key. Because both device and server have >>> the same private key so they can >>> use challenge-response based authentication algorithm to verify each other. >>> >>> Architecture - Modification: >>> >>> wpa_supplicant support the flow to handle EAP-SIM authentication, it use a >>> component accessing card reader >>> interface to communicate with SIM card to get necessary information.But >>> this way is not supported in our B2G device. >>> >>> So what we are planing to do is use gecko RIL module instead of using card >>> read interface. >>> Although we are trying not to modify wpa_supplicant, this task cannot be >>> done without any modification of code >>> in wpa_supplicant. So we limit our changes only happen in one file >>> (pcsc_funcs.c) which the original function >>> of this file is using card reader interface to access sim card. What we do >>> here is modify this file and redirect >>> command from wpa_supplicant to gecko module to get sim information. >>> >>> The pcsc_funcs.c file provide following interface used by wpa_supplicant >>> and we will modify the implementation of each interface: >>> >>> 1.scard_init : Establish IPC connection to gecko >>> 2.scard_deinit : Close IPC channel >>> 3.scard_get_imsi : Use established IPC connection to get IMSI >>> 4.scard_gsm_auth : Use established IPC connection to notify RIL to do gsm >>> authentication >>> 5.scard_umts_auth : Use established IPC connection to notify RIL to do umts >>> authentication >>> You can use following link to get more clear view of this architecture. >>> https://docs.google.com/drawings/d/1FsY1EU_NF7Rsu_D6VU9V0KZHHSdSCXmV_MhwZ-6Mc0U/edit >>> >>> Architecture - Flow of EPA-SIM: >>> >>> When WifiManager is initialized, it firstly create a worker thread listen >>> on specific socket, We implement this component >>> in gecko/ipc/wpasupplicant to handle this job. >>> >>> When wpa_supplicant is trying to connect to an AP with EAP-SIM protocol, it >>> will call scard_init first. >>> In scard_init we will establish an IPC channel with ipc/wpasupplicant. >>> >>> When wpa_supplicant need any sim information or operation, it will call API >>> like scard_get_imsi, scard_gsm_auth ...etc >>> We use the IPC channel established before and notify WifiManager that >>> wpa_supplicant need sim operation. >>> Since WifiManager do not have the ability to access sim card, we create a >>> RIL instance in WifiManager and use API of >>> RadioInterfaceLayer to execute opeartion we need. >>> >>> Following is API we will need to add in nsIRadioInterfaceLayer.idl >>> >>> interface nsIRadioInterfaceLayer : nsISupports >>> { >>> void simGSMAuthentication(in DOMString rand); >>> void simUMTSAuthentication(in DOMString rand, in DOMString autn); >>> >>> ... >>> }; >>> >>> Please feel free to share any suggestion, we are glad to hear any feedback >>> :) >>> Thanks, >>> >>> Best regards >>> Dimi >>> >>> >>> >>> _______________________________________________ >>> dev-b2g mailing list >>> dev-b2g@lists.mozilla.org >>> https://lists.mozilla.org/listinfo/dev-b2g > _______________________________________________ > dev-b2g mailing list > dev-b2g@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-b2g _______________________________________________ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
