i am not clear about how simtrace2, specifically libcommon/source/card_emu.c seems to handle the network delay for remote sim response however, i dont understand how that would help ??? my understand of the protocol is that ME => SIM (first 5 bytes of APDU) SIM <=== PROCEDURE (either INS as ack, or 0x60 to hold up the protocol) but that does not help remote sim, as remote SIM would need the susequent bytes which will not come until we send back INS, so just holding off ME with 0x60 does not alleviate the problem of network delay
Hi Thomas, On Thu, Nov 09, 2017 at 08:59:45PM -0500, Thomas Chen wrote:
my understand of the protocol is that
ME => SIM (first 5 bytes of APDU)
SIM <=== PROCEDURE (either INS as ack, or 0x60 to hold up the protocol)
but that does not help remote sim, as remote SIM would need the susequent bytes which will not come until we send back INS, so just holding off ME with 0x60 does not alleviate the problem of network delay
you don't hold off the ME at that point. Presuming it is "RUN GSM ALGORITHM" command, then the actual command from ME to card continues here with the random challenge. Later, a GET RESPONSE is issued from ME to SIM to obtain the SRES + Kc values, and this is where we can delay with waiting time extension (0x60) until we have the result. -- - Harald Welte <laforge@gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
On 10. Nov 2017, at 14:38, Harald Welte <laforge@gnumonks.org> wrote:
Hey,
Later, a GET RESPONSE is issued from ME to SIM to obtain the SRES + Kc values, and this is where we can delay with waiting time extension (0x60) until we have the result.
and maybe to make this more clear. The 0x60 will not be transmitted by the remote SIM but by the card emulation firmware. The expiration of a hardware timer will lead to "tc_etu_wtime_half_expired" being called and if the states are right the 0x60[1] will be transmitted. cheers holger http://git.osmocom.org/simtrace2/tree/firmware/libcommon/source/card_emu.c#n...
got it.... i thought you meant that in a general term, for other APDU commands such as GET RECORD or BINARY READ sending PROCEDURE would not help as REMOTE SIM side will not start sending data until after we ACK with INS and subsequent bytes are obtained and relayed to remote before it will start answering On 11/10/17 1:38 AM, Harald Welte wrote:
Hi Thomas,
On Thu, Nov 09, 2017 at 08:59:45PM -0500, Thomas Chen wrote:
my understand of the protocol is that
ME => SIM (first 5 bytes of APDU)
SIM <=== PROCEDURE (either INS as ack, or 0x60 to hold up the protocol)
but that does not help remote sim, as remote SIM would need the susequent bytes which will not come until we send back INS, so just holding off ME with 0x60 does not alleviate the problem of network delay you don't hold off the ME at that point. Presuming it is "RUN GSM ALGORITHM" command, then the actual command from ME to card continues here with the random challenge.
Later, a GET RESPONSE is issued from ME to SIM to obtain the SRES + Kc values, and this is where we can delay with waiting time extension (0x60) until we have the result.
i am seeing some strnge stuff with SIMTRACE .. when i have a modem communicating with SIM, and simtrace in sniffer mode i see a command 0x00 0xa4 0x04 0x04 0x10 + data (0xa0 0x00 0x00 0x00 0x87 0x10 0x02 0xff 0xff 0xff 0xff 0x89 0x06 0x19 0x00 0x00) and got response + status (0x61, 0x44) but in remote SIM environment. this SIM card return 0x69 0x99 do you know what that mean ??? i dont know whether it is timing or something else ? all previous commands seem to work just fine thanks
Hi Thomas, remote SIM environment as in OTA? Selecting an AID remotely might not make sense, that's what TARs are for .. but not sure what you're trying to achieve and what context do you send the SELECT in.. Lukas On Fri, Nov 24, 2017 at 6:53 PM, Thomas Chen <tchen@on-go.com> wrote:
i am seeing some strnge stuff with SIMTRACE .. when i have a modem communicating with SIM, and simtrace in sniffer mode i see a command 0x00 0xa4 0x04 0x04 0x10 + data (0xa0 0x00 0x00 0x00 0x87 0x10 0x02 0xff 0xff 0xff 0xff 0x89 0x06 0x19 0x00 0x00) and got response + status (0x61, 0x44)
but in remote SIM environment. this SIM card return 0x69 0x99
do you know what that mean ??? i dont know whether it is timing or something else ?
all previous commands seem to work just fine
thanks
i am only trying to test whether the remote sim, and i observed mPCIe GSM modem ==> simtrace ======(local lan)====> card reader i see about 20-30 apdu flying back and forth... and everything looks normal and then the modem issue a RESET what can be the problem ??? how does one find out whether modem is not happy ???
participants (4)
-
Harald Welte -
Holger Freyther -
Lukas Kuzmiak -
Thomas Chen