55.51 KB, image/png
We should have basic tests for accessing an SE and sending/receiving APDUs from an installed secure applet. The DOM interface would be the SE interface defined in bug 879861. The emulator shall - be able to process (predefined) APDUs, - implement a simple Ping service - provide a channel for accessing the Ping service using APDUs, - offer an AID to name the channel. Test cases can use this service for testing the SE stack. As an additional feature, access control might be implemented for the AID in Gecko.
Created attachment 8460243 [details] NFC Emulator Support for automate testing of SE-API.png An idea to enhance nfc emulator to support automate testing of SE-AP.
(In reply to Ming Yin from comment #1) > Created attachment 8460243 [details] > NFC Emulator Support for automate testing of SE-API.png > > An idea to enhance nfc emulator to support automate testing of SE-AP. The overall principle is correct, but there won't be an 'SE Emulator Connector' in Gecko. We either build this as part of RIL or as part of NFC. The hardware-side of the ACE shouldn't be a problem, since we can configure this component over telnet as well.
how can I imagine that SE emulator could be implemented as part of RIL? Would it be feasible for web app to talk to this SE-Emulator via SE-API? can you please draw me a picture of your idea?
Hi (In reply to Ming Yin from comment #3) > how can I imagine that SE emulator could be implemented as part of RIL? > Would it be feasible for web app to talk to this SE-Emulator via SE-API? > can you please draw me a picture of your idea? The picture would look exactly like the one we discussed in the meeting on Tuesday. Apps use the SE API just like on any other platform. Out test cases might need to configure the emulator using telnet, but that's unrelated to SE. And we need the patched RIL stack. It communicates with the hardware using a device file somewhere under /dev/. In the emulator's case, the hardware is implemented by software.