Bruce Barnett wrote:
I'd like to experiment with a new Musclecard CardEdgeApplet function where I
send the card a byte array, and get a byte array back.
I'd like to add capability for the card to store passwords to other systems.
It's (for now) a simple table look-up algorithm.
I'm looking at some of the other functions, like MSCComputeCrypt (type S)
and ReadObject (type S/R). I'm not sure I understand the subtlties.
First, am I correct that a function can't simply be given a string and
return a string, and that you need to do a separate query to get the
response? Can I have the input string sent as part of the APDU?
Hi, you're wrong. You can get a byte array as input and provide a byte
array as output. The JavaCard framework alleviates you from the burden
of transmitting the response bytes in a separate APDU (namely the ISO
GET_RESPONSE APDU). Peek at the MuscleCardApplet's ReadObject() function
for an example.
Beware that, this way, you may only transmit at most 256 bytes per-APDU
exchange (unless the card implements certain extensions of the T=0
protocol allowing larger data chunks).
This is why we introduced the Input/Output object paradigm, in the
Applet: everytime you need to transfer larger data, such as a cryptogram
to be signed, or a key blob, etc...., then you do it by using either
the Input object or the Output object. So, in the former case, the host
is supposed to fill large data chunks into the Input object, before
actually invoking the command that uses that data as input. Similarly,
a command may fill an Output object for providing large data chunks to
the host, which is supposed to retrieve such long data by subsequent
MuscleCard Read-Object apdu exchanges, specifying the Output object.
So, if your "looked-up" data is significantly shorter than 256 bytes,
you may simply use the normal JavaCard mechanism, i.e.
1. buffer = apdu.getBuffer()
2. call setIncomingAndReceive()
3. analyze buffer[] and make computations
4. overwrite buffer[] again with response data
5. call setOutgoingAndSend() providing the size of the output data
If you could provide more information on the commands you're going to
implement, I would be more than happy in helping designing this new
mechanism. I'd like to understand first how it would be useful to
applications (I guess this is a subset of what ISO7816-6 -- or 7 --
allows to do by sending SQL-like queries to a card and getting only
the requested data, and not the entire data set). Especially, I'd
like to understand why a simple object storing all of your data is
not suitable for this kind of "lookup-table"-based storage/retrieval
paradigm.
or do I need to write an object first? Which function would be best
suited as a starting point for code "borrowing?"
Second, any suggestions on how to do manage a look-up table?
The ObjectManager functionality confuses me a little.
If you explain me better what you are supposed to lookup, and
what you are supposed to retrieve, I may certainly try to help you.
Hope this helps, bye,
T.
Tommaso Cucinotta <cucinotta �/at\# sssup.it>
Computer Engineering PhD
Scuola Superiore Sant'Anna, Pisa (Italy)
Pointers in the right direction would help.
Thanks
- Bruce
_______________________________________________
Muscle mailing list
[EMAIL PROTECTED]
http://lists.drizzle.com/mailman/listinfo/muscle
_______________________________________________
Muscle mailing list
[EMAIL PROTECTED]
http://lists.drizzle.com/mailman/listinfo/muscle
