----- Original Message ----- From: "Karsten Ohme" <[EMAIL PROTECTED]>
To: "MUSCLE" <[EMAIL PROTECTED]>
Sent: Thursday, December 02, 2004 2:41 AM
Subject: [Muscle] send an receive data with SCardTransmit - Case 4 Short
Can I send and receive data simultaneously from a card with SCardTransmit()?
You can assume that the underlying signalling is half-duplex, in traditional single function, single port cards. (This is the normal answer, for a 1980s-class card).
------------
Fun discussion:-
To answer the question, as actually posed, however: the answer is yes. Applet instance "1" may be sending on the wireless port, while applet instance "2" may be receiving on the I2C port. Applet instance "3" may be in one of USB's several "funny" bus state on the USB port of a smartcard uP with builtin USB SIE.
Given I2C clock stretching and USB's fixed slot timing, its more than likely that two ports tx/rx could be counterposed - so the card as a whole is both sending and receiving at the same time at layer 1.
In your code,you would need to support logical channels, by the exploiting the bit mask option of the class byte. For cards with global platform support, multiple applets (or applet instances) can be simultaenously selected, each with its own security association state variables (including session variables!) and sharedclass/owninstance application-specific session crypto variables and transient RAM pool.
When one does secure messaging, furthermore, the precise state of any of the 3 security associations is of course a layer 1 issue. Thus, a multi-port reader talking to a multi-port card, over 3 logical channels, each using a different port technology will need to maintain precise knowledge of the tx/rx state of each bus, for each SCardTransmit block setup in the PCSC resource manager.
To be fanciful, now, if one was signalling using NSAs GSAKMP approach for group keying the parameters of an FGPA-based raw RSA key enumerator - a football field of 2U 300 GFlop SRAMs in 0.18 micron technology from your own fab, say - and each "card" had 1000000 applet instances each with a 10k of ram, the multicast bus would be harder to analyse in 7816 half-duplex terms. But then, in such design work, 7816 is really not the right model, and neither would one bother with the overhead of javacard instruction emulation. One could keep the javacard in part of the mask, to make GSAKMP and data collection a PC-easy process, and have the cipher algorithm in pure logic. Fancy mode, finished.
---------------
sendBufferLength = 5 + AIDLength + 1; sendBuffer = (LPBYTE)malloc(sizeof(BYTE)*sendBufferLength); sendBuffer[i++] = 0x00; sendBuffer[i++] = 0xA4; sendBuffer[i++] = 0x04; sendBuffer[i++] = 0x00; sendBuffer[i++] = (BYTE)AIDLength; memcpy(sendBuffer+i, AID, AIDLength); i+=AIDLength; sendBuffer[i] = 0x00; result = SCardTransmit( cardHandle, SCARD_PCI_T0, sendBuffer, sendBufferLength, NULL, recvBuffer, &recvBufferLength ); if ( SCARD_S_SUCCESS != result) { errorMessage(result, "SCardTransmit"); return result; }
I get "wrong parameter". What's wrong?
At the moment I have to use a GET RESPONSE command to retrieve data from the card. Is this supported by every card?
Use a card controller that does it for you, as appropriate, by its supporting the APDU mode. No reason, usually, to signal this polling work all the way up to the PC layer.
Thanks, Karsten _______________________________________________ Muscle mailing list [EMAIL PROTECTED] http://lists.drizzle.com/mailman/listinfo/muscle
_______________________________________________ Muscle mailing list [EMAIL PROTECTED] http://lists.drizzle.com/mailman/listinfo/muscle
