> I think we can discuss on this bug. I agree we discuss on this bug.
By the way, thanks for your review for Gecko side to https://bugzilla.mozilla.org/show_bug.cgi?id=890694. But Gaia side was not checked reviewed. Could you check Gaia side patch also ? 2013/8/8 Dimi Lee <[email protected]>: > Hi Massahi Honma > I check the bugzilla and found there is already a bug related to EPA SIM > bug 830309 > https://bugzilla.mozilla.org/show_bug.cgi?id=830309 > > I think we can discuss on this bug. > Please let me know if there are any problem > > BR > Dimi > > ----- Original Message ----- > From: "Masashi Honma" <[email protected]> > To: "Dimi Lee" <[email protected]> > Cc: "Jonas Sicking" <[email protected]>, "Kyle Machulis" > <[email protected]>, "dev-b2g" <[email protected]> > Sent: Friday, August 2, 2013 10:12:49 PM > Subject: Re: [b2g] EAP-SIM Architecture proposal > >> 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 <[email protected]>: >> 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" <[email protected]> >> To: "Dimi Lee" <[email protected]> >> Cc: "Kyle Machulis" <[email protected]>, "dev-b2g" >> <[email protected]> >> 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 <[email protected]> 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" <[email protected]> >>> To: "Dimi Lee" <[email protected]>, "Kyle Machulis" <[email protected]> >>> Cc: "dev-b2g" <[email protected]> >>> 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 <[email protected]> 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 >>>> [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
