Hello all,
If you have written your own smartcard config file and you use the
SwapDrop word "sendAPDU" to send an APDU to the card, can you please
check your code to be sure that you don't depend on sendAPDU putting
any returned APDU data onto the stack? The SwapDrop spec says this
about the usage of sendAPDU (this is from the SwapDrop white-paper that
I distribute to developers writing their own config files):
sendAPDU - send the APDU {APDU} to the smartcard
{APDU} sendAPDU -- {procedure_byte} {status} {boolean}
InputParameters
{APDU} – hexvalue, APDU to send to the card
OutputParameters
{boolean }– boolean true if APDU successfully
sent to card and the card
responded
{status} – hexvalue status bytes from the card
{procedure_byte} - hexvalue procedure byte from
the card
I am doing some work on the SwapDrop code in the Auth Manager and I
noticed
that there is at least one smartcard config file written by someone
outside
of the Sun Ray group that issues a sendAPDU and then takes advantage
of a
bug in the implementation where the returned APDU data is put on the
stack
following the {procedure_byte} value, but there is no boolean to
indicate
whether or not this data exists. What I think happened was that someone
tried sendAPDU and looked at the stack (with "showstack") and noticed
that
there was returned APDU data there and then used the return data. The
proper
way to get returned data from the card is to use exchangeAPDU. The fact
that sendAPDU put returned data onto the stack following the
{procedure_byte}
is undocumented and the result of a bug in the SwapDrop implementation.
I have fixed the SwapDrop code that handles sendAPDU so that this
extra data
is not pushed on the stack and that sendAPDU now behaves as the spec
says it
should. Please look at any config files that you have written and
which use
sendAPDU and be sure they don't depend on this anomalous behavior.
I'll make
sure that any config files we (Oracle) supply are fixed in the patch
that
fixes the SwapDrop code.
If you have any questions, please drop me a line.
thanks,
mike
_______________________________________________
SunRay-Users mailing list
[email protected]
http://www.filibeto.org/mailman/listinfo/sunray-users
