From: Karsten Ohme <[EMAIL PROTECTED]>
Reply-To: MUSCLE <[email protected]>
To: [EMAIL PROTECTED], MUSCLE <[email protected]>
Subject: Re: [Muscle] APDU issues
Date: Thu, 15 Sep 2005 01:54:06 +0200
Arthur Chiu wrote:
> Thanks for your reply Peter. I am a bit confused though (This is the
> first time I'm working on smart cards). When you say MUSCLE card, I'm
> not quite sure what you mean. I thought MUSCLE would be a library that
> deals with different types of cards?
Not exactly. Look at this:
http://www.inf.tu-dresden.de/~ko189283/MuscleCard/MuscleCardArticle.html
MUSCLE which is among other things PC/SC Lite to communicate with card
readers, also has the MuscleCard Library libmusclecard. In the
background there are different plugins for individual cards. On of this
plugin, maybe the only available is the CardEdge or MuscleCard applet. a
Java Card applet.
So, musclecards are cards which export a particular interface (as expressed
by the methods/APDUs) it supports. Its possible for an ISO card to emulate a
musclecard, because some emulator maps an ObjectWrite method call/A-PDU,
say, onto a sequence of ISO A-PDUs. How good that emulation is is of course
hard to know: does the acl scheme enforced by the ISO card while writing
"files" have exactly the same authentication/access control semantics as the
musclecard scheme which is writing "objects"?
so, in the terms of your query: musclecard is an interface. libmusclecard is
an API implementation for the calling the interface methods, remotely., on a
host The provider chooses how to implement the API according to its
discovery of the actual card its talking to. Similarly, it select a suitable
transport channel. A native musclecard requires minimal API provider
activity: an ISO card emulating a musclecard requires more from the API
provider. In David's implementation, the API provider has two layers:
generic, and a plugin for native/emulated support
The transfer of APDUs between hosts and READERs is performed according to
the Microsoft PC/SC API, via its Windows/Linux provider. The libmusclecard
plugins uses the transport centric support for communciation of bytes, and
reader-specific control signals.
Note that libmusclecard (for native msuclecards) will do host-based polling
for you, assuming its not already been done by the reader. This makes the C
API expose the the simple RPC + exception pattern, rather than provide the
application with an APDU/TPDU-style interface pattern.
> I actually have another question. After I send the APDU of 00 A4 00 00
> 02 3F 00 to the card, I get a return code of 90 00 instead of 61 xx.
> Does this mean that there is no information on the card? When I look it
> up on ISO 7816-4, it shows that 90 00 means "No Further Qualification",
> which I'm not too sure of the meaning.
90 00 means success. If this is all no further data is available. You
selected the MF. Can be OK. Look in the spec. Maybe there exist very
intelligent readers which automatically answer 61 xx responses. Or you
have used the protocol T=1. Then this is normal. (See ISO 7816-4 T=1
protocol).
So as Karsten implied, it probably means that the intervening reader
software is performing the polling command (for the results) automatically,
on receiving the 61 xx status bytes from the card. Thus you see only the
response as unfragmented from the (Set of ) polling interactions the reader
chip makes with the card, in order to recover the data msg being returned to
the host.
Karsten
> Thanks a lot for your time and help. :)
>
> Cheers,
>
> Arthur
>
> On 9/13/05, *Peter Williams* <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>
> wrote:
>
>
>
> if the card in question has support for an ISO file structure
> (MF/DFs), then
> one can navigate the hierarchy by enumerating the directory
> elements, and
> selection DFs and EFs.
>
> Muscle cards dont have ISO file formats. muscle cards have a flat
file
> structure, with a 32bit name. IF we get academic, a muscle card acts
> more
> like a persistent store for distributed objects, named within a
> 32bit field
> , than a file store backed by eeprom.
>
> I believe that one of the muscle card implementations actually maps
the
> musclecard abstractions onto a ISO card. It probably maps object
> references
> (32bits) into an DF/EF combination, beneath the ISO root.
>
> Dave can perhaps indicate if the source code for the oberthur plugin
is
> available, which will show off how one nagivates the ISO file store
> using
> the ISO APDUs, to create the muscle card object layer abstraction.
>
> >From: Arthur Chiu <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>
> >Reply-To: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>,
> MUSCLE <[email protected]
> <mailto:[email protected]>>
> >To: MUSCLE < [email protected]
> <mailto:[email protected]>>
> >Subject: [Muscle] APDU issues
> >Date: Tue, 13 Sep 2005 15:52:30 -0700
> >
> >Hi, I am currently trying to read and write to the memory within
the
> >smartcard.
> >Please correct me if I am wrong. I first have to select MF, then
> select DF,
> >then select EF and perform read binary or write binary (for
> transparency
> >file structure).
> >
> >Now the question is:
> >1) How do I know the identifier of a DF? From the return code I get
> from
> >SCardTransmit, I have 90 00, meaning no further qualification. Does
> this
> >mean that there are no further information?
> >2) If I were to create a DF or EF, how would I do so? I cant seem
> to find a
> >command in the ISO 7816-4 documentation.
> >3) How can I create an EF of different structure?
> >4) Finally, I have tried the following 2 APDU for selecting the MF
and
> >according to ISO 7816-4, I should obtain the same result. However,
> I did
> >not. The following is the code segment:
> >
> >Version 1:
> >-----------------
> >sendBuffer = (BYTE*) malloc(10*sizeof(BYTE));
> >recieveBuffer = (BYTE*)malloc(256*sizeof(BYTE));
> >
> >memcpy(sendBuffer, "\x00\xA4\x00\x00\x02\x3F\x00",7);
> >
> >dwLength = sizeof(recieveBuffer);
> >rv = SCardTransmit(CardHandle, SCARD_PCI_T0, sendBuffer, 7,
&IORequest,
> >recieveBuffer, &dwLength);
> >
> >
> >Version 2:
> >--------------------
> >sendBuffer = (BYTE*) malloc(10*sizeof(BYTE));
> >recieveBuffer = (BYTE*)malloc(256*sizeof(BYTE));
> >
> >memcpy(sendBuffer, "\x00\xA4\x00\x00",4);
> >
> >dwLength = sizeof(recieveBuffer);
> >rv = SCardTransmit(CardHandle, SCARD_PCI_T0, sendBuffer, 4,
&IORequest,
> >recieveBuffer, &dwLength);
> >
> >I get 90 00 for version 1 (which i think is correct?) and 67 00
(Wrong
> >Length) for version 2.
> >Why would this be so?
> >
> >Thanks a lot for any generous help :)
> >
> >Cheers,
> >
> >Arthur
>
>
> >_______________________________________________
> >Muscle mailing list
> >[email protected] <mailto:[email protected]>
> >http://lists.drizzle.com/mailman/listinfo/muscle
>
>
> _______________________________________________
> Muscle mailing list
> [email protected] <mailto:[email protected]>
> http://lists.drizzle.com/mailman/listinfo/muscle
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Muscle mailing list
> [email protected]
> http://lists.drizzle.com/mailman/listinfo/muscle
_______________________________________________
Muscle mailing list
[email protected]
http://lists.drizzle.com/mailman/listinfo/muscle
_______________________________________________
Muscle mailing list
[email protected]
http://lists.drizzle.com/mailman/listinfo/muscle
