search

rekha-k / seek-for-android

Automatically exported from code.google.com/p/seek-for-android
0 stars 0 forks source link

Transaction.protocolTransmit() filtering 63xx response code for non GP GET STATUS command #61

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
What's the problem?

Transaction.protocolTransmit() is filtering SW 63xx and issuing GET RESPONSE 
command automatically (in SCAPI v2.3.2 Samsung S3 at least). For the SCAPI 
3.0.0 I believe code has been changed to just check 6310.

This behaviour works for GP GET STATUS but may trigger unexpected behabious in 
other cardlets (in a case we're working on the function returned 6d 00 because 
it didn't support GET RESPONSE).

I think this behaviour was introduced to solve issue 13, but it had undesired 
secondary effects.

What steps will reproduce the problem?
1. Send any command to SE that returns a 63xx
2.
3.

What is the expected output? What do you see instead?
63xx. In our case it's a 63c2, as it is a VERIFY command that implements SW 
from the ISO/IEC 7816-4 standard (it would work in SCAPI 3.0.0 I guess, but 
solution implemented there is suboptimal, I think).

What version of the product are you using? On what operating system?
SCAPI v2.3.2 Samsung S3

Please provide any additional information below.
I'd suggest that automatical GET RESPONSE is only issued when we check cmd to 
be GP GET STATUS, that is CLA vendor-specific and INS F2.

Can provide a patch to SCAPI 3.0.0 if you want, but i can't test.

Original issue reported on code.google.com by jmo...@gmail.com on 1 Jul 2013 at 6:43

GoogleCodeExporter commented 9 years ago 
The problem with 63Cx return codes was solved in SCAPI-3.0.0 with checking for 
6310.

Do you still see the need for verification of the previous command for 
INS=0xF2? I have not seen a 6310 response in other cases.

Original comment by Daniel.A...@gi-de.com on 5 Jul 2013 at 2:27

GoogleCodeExporter commented 9 years ago 
Daniel,

Thank you for answer.

I do think that verifying both for INS==0xf2 *and* CLA bit 8 set
(proprietary class) is needed.

ISO/IEC 7816-4 defines 63XX as "State of non-volatile memory has changed
(further qualification in SW2)".
ISO/IEC 7816-4 also defines some interindustry SW2 (IRRC, for the moment
6300, 63Cx, 6382).
However, this doesn't mean that it doesn't in the future or that any
application can't use non-defined ones, as GP does with 6310.

This is still suboptimal, of course, as another card application could
potentially use a proprietary F2 command and return a 6310 with a
different meaning. But chances of meeting this case are greatly reduced
compared to only checking for 6310.

BTW: Just curious, why isn't the second GET STATUS issued as application
level? Why should seek implement concepts for specific applications?
This case is very different than the ISO/IEC 7816-3 61xx/GET RESPONSE case.

Original comment by jmo...@gmail.com on 7 Jul 2013 at 10:50