Re: MUSCLE GPR400 ifd and T=0 vs T=1 from the driver perspective
Purchase ISO 7816 parts 3 and 4 to understand the low level communication between card and IFD (Terminal, card reader). Peter T Bristol UK - Original Message - From: Joe Phillips [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: Wolf Geldmacher [EMAIL PROTECTED] Sent: Thursday, August 02, 2001 3:43 AM Subject: MUSCLE GPR400 ifd and T=0 vs T=1 from the driver perspective I've got a mostly working GPR400 PCSC IFD. It's based on the PCMCIA driver found in the card-0.9.6.tar.gz file found on the MUSCLE website. By 'mostly working' I mean that I've used formaticc to send a few APDUs to a card and received the expected results. I'm having troubles understanding what the differences are between T=0 and T=1 from the IFD developer perspective. It's not apparent to me from looking through the other IFD source files. I have the Smart Card Developer's Kit and Java Card Technology for Smart Cards books already. I understand that T=0 and T=1 are two different protocols for communication between the reader and the card. It is not clear to me *how* they are different other than one is byte oriented and the other is block oriented. Can anyone offer any insight into the differences, if possible, from the IFD developer perspective? Can you point me to some documentation and/or code that will clear this up for me? Thanks in advance. -joe *** Unix Smart Card Developers - M.U.S.C.L.E. (Movement for the Use of Smart Cards in a Linux Environment) http://www.linuxnet.com/ To unsubscribe send an email to [EMAIL PROTECTED] with unsubscribe sclinux *** *** Unix Smart Card Developers - M.U.S.C.L.E. (Movement for the Use of Smart Cards in a Linux Environment) http://www.linuxnet.com/ To unsubscribe send an email to [EMAIL PROTECTED] with unsubscribe sclinux ***
Re: MUSCLE Is 61xx handled in your driver?
The clean way to organise this is: (a) An application in the terminal issues APDUs (b) The software layer receiving the APDU knows whether the card is being operated with T=0 or T=1, and sends information down to the card driver as appropriate; if T=0 and a case 4 APDU, the APDU is split into a Case 3 TPDU (which sends data to the card) and a Case 2 GET RESPONSE (c) The card driver interfaces with a card reader driver (d) The card reader driver handles the interface out to the card reader Change the card - change only the card driver in the PC; change the card reader - change only the card reader driver in the PC Write the layer below the application strictly to 7816-4 rules, and cards that don't comply (e.g cards that require a GET RESPONSE as part of processing every APDU (if that really is true)) are not acceptable. Its sad that we cannot yet have a universal card driver, but its going to be true for some time to come. Regards, Peter T Bristol UK - Original Message - From: Laurent Boulard [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, August 01, 2001 8:08 AM Subject: Re: MUSCLE Is 61xx handled in your driver? David Corcoran wrote: I think you should handle the Get Response if your APDU looks like the following: CLA INS p1 p2 p3 lentx xx xx xx xx xx lenrx Is this correct ? In the perfect world yes ! but, sadly, people sometimes doesn't follow correctly the ISO7816 or misunderstood it. I have cards (W4SC as an example) which send back a GET RESPONSE even for a APDU without data. This is really annoying as I have to modify my application to take care of this kind of cards. May be the highler level must be modify to hide this behaviour. But, from another point of view, it is interesting to know that you have a card with GET RESPONSE because sometimes those cards must run in terminals without management of the GET REPONSE apdus. -- Laurent Boulard Research Engineer Advanced Research SchlumbergerSema (Louveciennes) Tel: +33 (0)1 30 08 45 97 Fax: +33 (0)1 30 08 45 24 perl -e 'print(pack(h38,34f6e67627164757c6164796f6e63702b3d292))' *** Linux Smart Card Developers - M.U.S.C.L.E. (Movement for the Use of Smart Cards in a Linux Environment) http://www.linuxnet.com/smartcard/index.html *** *** Unix Smart Card Developers - M.U.S.C.L.E. (Movement for the Use of Smart Cards in a Linux Environment) http://www.linuxnet.com/ To unsubscribe send an email to [EMAIL PROTECTED] with unsubscribe sclinux ***
Re: MUSCLE Is 61xx handled in your driver?
CLA INS P1 P2 Lc data Le in 7816-4 speak (section 5.3.1 Fig 3) Peter T Bristol UK - Original Message - From: David Corcoran [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, July 31, 2001 9:26 PM Subject: Re: MUSCLE Is 61xx handled in your driver? I think you should handle the Get Response if your APDU looks like the following: CLA INS p1 p2 p3 lentx xx xx xx xx xx lenrx Is this correct ? Dave *** Linux Smart Card Developers - M.U.S.C.L.E. (Movement for the Use of Smart Cards in a Linux Environment) http://www.linuxnet.com/smartcard/index.html *** *** Unix Smart Card Developers - M.U.S.C.L.E. (Movement for the Use of Smart Cards in a Linux Environment) http://www.linuxnet.com/ To unsubscribe send an email to [EMAIL PROTECTED] with unsubscribe sclinux ***
Re: MUSCLE Error using an IBM MFC in GemPlus readers.
From ISO 7816-3:1997, ATR looks like: 3B Direct data convention EF TB1, TC1, TD1 present, 15 historical bytes 00 TB1 Vpp not used FF TC1 Min delay between character transmissions is default value (11 etu for T=1) 81 TD1 T=1 protocol only, TD2 is present 31 TD2 TB3 and TC3 present FF TB3 BWI for T=1 not as per ISO (value F is 'reserved'), CWI for T=1 = 15 65 TC3 Bit 0 says LRC used in T=1, other bits should be all be set to zero for ISO 7816 Historical bytes say: IBM MFC92292890 I seem to remember that the IBM MFC card is a CEN EN726 (telecoms standard) card, and not an ISO 7816 card. Peter T Bristol UK - Original Message - From: Rich Wareham [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, June 29, 2001 9:49 AM Subject: MUSCLE Error using an IBM MFC in GemPlus readers. Hello, I am currently porting some Windows software for the management of smartcards over to Linux, the cards in question are IBM MFC 4.22 smart cards. I get the same error on card power up from both the GemPlus 410 serial and GemPlus 430 USB card reader when using the PCSClite drivers. In both cases the drivers send the following OROS command: 12 which attempts to power up the card and return the ATR, the response is A0 3B EF 00 FF 81 31 FF 65 49 42 4D 20 4D 46 43 39 32 32 39 32 38 39 30 17 The first byte is an error code which is, according to the GemPlus docs, Error in the card reset response, such as unknown exchange protocol, or byte TA1 not recognized [sic]. The card is not supported by OROS. The card reset response is nevertheless returned. Since I'm rather new to smart-card programming, could someone tell me what this means and who is at fault. BTW, the same readers and cards work fine with PC/SC under Windows. Rich -- rich The box says 'Requires Win95 or better' so it /must/ run under Linux *** Linux Smart Card Developers - M.U.S.C.L.E. (Movement for the Use of Smart Cards in a Linux Environment) http://www.linuxnet.com/smartcard/index.html *** *** Linux Smart Card Developers - M.U.S.C.L.E. (Movement for the Use of Smart Cards in a Linux Environment) http://www.linuxnet.com/smartcard/index.html ***
Re: MUSCLE Smartcard reader from Sun
Very interesting, but the text from Sun is not at all clear. If the smart card really is connected [directly] to the I2C interface, this reader will only accept I2C interface memory cards. But because I2C is not 7816 compliant, one would expect that the reader module has a 7816-compliant slot, some electronics, and (the other side of the electronics from the card interface) an I2C interface. Then all that is needed is a driver for the smart card reader... (tongue firmly in cheek, 'cos I have designed smart card readers and tested many more). Peter T Bristol UK - Original Message - From: Olivier Bornet [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: Olivier Bornet [EMAIL PROTECTED] Sent: Saturday, June 09, 2001 8:21 PM Subject: MUSCLE Smartcard reader from Sun Hello all, I'm totaly new in the smartcard field. I have just received a SunBlade 100 workstation with a Sun smartcard reader inside, so I want to know if there is a chance to use it from a Debian GNU/Linux for SPARC distribution. I have surf a little on the MUSCLE web site, and on the mailing list archive, but it seem the supported reader are only serial, USB or PCMCIA reader. Here is a small abscract with a description of the reader (comming from http://docs.sun.com/htmlcoll/coll.724.1/iso-8859-1/SBLADE100SVC/appdC.htm#10 8318 ) : == The smart card reader interface is ISO 7816 compliant. The smart card reader is mounted to the peripheral assembly at the front of the system chassis. A 10-pin ribbon cable connects the smart card PCB to the connector of the riser board. The smart card will connect to the on-board I2C (SMBus) interface on the SouthBridge ASIC. == Thanks in advance. Olivier -- Olivier Bornet | français : http://puck.ch/f Swiss Ice Hockey Results | english : http://puck.ch/e http://puck.ch/| deutsch : http://puck.ch/g [EMAIL PROTECTED] | italiano : http://puck.ch/i Get my PGP-key at http://puck.ch/pgp or at http://wwwkeys.pgp.net *** Linux Smart Card Developers - M.U.S.C.L.E. (Movement for the Use of Smart Cards in a Linux Environment) http://www.linuxnet.com/smartcard/index.html *** *** Linux Smart Card Developers - M.U.S.C.L.E. (Movement for the Use of Smart Cards in a Linux Environment) http://www.linuxnet.com/smartcard/index.html ***
Re: MUSCLE Work Waiting Time question
On 7 June 2001 Carlos Prados wrote Re: MUSCLE Work Waiting Time question Hi, It seems, therefore, that changing the value of Di in the ATR does not change the value of the wwt, but changing the value of Fi does. Is this what the writers of 7816-3:1997 meant? I don't think so, because the wwt required is related to the values of clock sent to the card, the internal structure of the card's CPU and clock processing circuits, and the application algorithm programmed into the card. Changing Fi and Di doesn't change the way that the card runs its application code, and so should not change the wwt - but changing Fi does change the wwt. FI from the card, besides influencing I/O bit rate, also indicates the max clock frequency that the card can be run at. So: FI = 0 (means Fi = 372), Di = 1 gives a bit rate of 9600 in our example, a wwt of 1 sec, and indicates (Table 7) a max clock frequency of 4 MHz (typical for a card run at 3 Volts Vcc) FI = 1 (also means Fi = 372), Di = 1 gives a bit rate of 9600 in our example, a wwt of 1 sec, and indicates (Table 7) a max clock frequency of 5 MHz (typical for a low cost card run at 5 Volts Vcc) FI = 3 (means Fi = 744), Di = 2 also gives a bit rate of 9600 in our example, but changes the wwt to 2 sec, and indicates (Table 7) a max clock frequency of 8 MHz (e.g. for a Hitachi 3109 card as used by rollout spec Mondex in a single application environment) But the reader that I'm ussing provides 3.5712 MHz constant clock rate to the smartcard regardless of the ATR in the card. The clock frequency figures given in the above explanation are the maximum that the card is rated to use. The card can be run at any frequency from 1 MHz up to the maximum indicated by the value of FI indicated in the ATR. It is very rare to find a card reader that can switch frequencies (and in other places I have argued that the combined requirements of 7816-3, EMC regulations, and the desire to protect the reader's interface circuitry from static discharges, make it very difficult to design a reliable and compliant card reader that drives the card at more than 4 MHz). Cards have to be started with a clock frequency (at 5V Vcc) in the range 1 Mhz to 5Mhz, and they start with a clock to I/O bit rate ratio of 372, so 3.5712 Mhz (gives 9600 bps on I/O) or something close to that is typical. What I was showing is that a card that can only be run at up to 5 MHz will, at 3.5712 MHz clock, expect the terminal to grant it a default wwt of 1 sec. But a card that can be run at up to 8 MHz (and whose developer wishes to announce that to the terminal, in case the terminal can switch up to a higher speed) is very likely to issue an ATR that results in the terminal giving it, at 3.5712 MHz, an I/O bit rate of 9600 but a wwt of 2 seconds. If we assume that that card is identical to the other one in all respects except for being rated to run at up to 8 MHz instead of up to 5 MHz, then both cards will execute applications at exactly the same rate when run at the same clock frequency, and therefore both will need the same wwt. This points out an absurdity in 7816-3, but also shows that, when calculating the value of WI to send from the card if you want to change the wwt, you must be careful to use the correct parameters in the equation (if the card sends a value for FI in the ATR, you must use that value in the calculation). So, must I assume that if the clock rate doesn't change I must not change the wwt from the standard 1s value ? No, you choose the wwt value (choose a WI value to send from the card) to give you a long enough wwt to be sure that the card has time to execute the longest path through the code between responses from the card (remember that you can send a procedure byte from the card to reset the wwt timer in the terminal, and sometimes that is a practical solution (e.g. send a NULL), but at other times you may find you have a card whose ROM code will not let you do that). Does this apply to T=1 timeout values, BWT and CWT? BWT and CWT have their own formulae in section 9.5.3 of 7816-3:1997, and their own parameters in the ATR. BWT's formula is very odd: BWT = 11 etu + 2**BWI * 960 * (372/f) sec but CWT depends directly on F/D as well as f: CWT = (11 + 2**CWI) * (F/D) * (1/f) BWI and CWI are upper and lower nibbles from the TB interface byte after the first occurrence of a T=1 value in a TD(2) or later TD byte. wwt extension in T=1 is handled by an S-block request from the card. Who dreamt this up? Mainly the French for T=0 and the Germans for T=1. Vive le Common Market! Peter T Bristol UK *** Linux Smart Card Developers - M.U.S.C.L.E. (Movement for the Use of Smart Cards in a Linux Environment) http://www.linuxnet.com/smartcard/index.html ***
Re: MUSCLE Work Waiting Time question
Carlos, Use the current (1997) edition of 7816-3, not the obsolete (1989) edition. Its still not easy to do the calculations, so readers of this note should check it over carefully. 7816-3:1997 section 8.2 on work waiting time: wwt = 960 * WI * (Fi / f) f = card clock frequency - let us assume 3571200 Hz (3.5712 MHz) Fi is the clock rate conversion factor. It is coded as FI in the top 4 bits of ATR interface byte TA(1), and Table 7 is used to find the value of Fi. If TA(1) is not present, the default value of Fi is 372 (see below about this muddle). WI is coded in ATR specific interface byte TC(2); the default value if TC(2) is not sent by the card is 10 Using default values and the assumed card clock frequency of 3571200, we have: wwt = 960 * 10 * (372 / 3571200) = 1 second For the calculation of the etu (elementary time unit, or bit period on the I/O line), another factor comes in. 7816-3:1997 section 6.5.2: 1 etu = (F / D) * (1 / f) First, one of 7816-3's muddles must be cleared out of the way: if interface byte TA(1) is present, F = Fi as found via Table 7 (see above); if TA(1) is not present, F = Fd = 372; but if a successful PPS exchange in which the interface device sends PPS1 to request the card to accept values of F and D takes place, F = Fn as sent back by the card. (PPS is the new name for PTS) D is the extra factor: the I/O line bit rate adjustment factor (e.g. changing D from the default 1 to the value 2 halves the length of the etu, or doubles the bit rate). The same muddle as for F applies: first, it is coded as DI in the bottom 4 bits of ATR interface byte TA(1), and Table 8 is used to find the value of Di; if TA(1) is not present, the default value of Di is Dd = 1; and a PPS exchange can change D just as it can change F. So, using default values and a clock rate of 3.5712 MHz: 1 etu = (372 / 1) * (1 / 3571200) = 1.04167 sec (104.167 microsec or, of course, 1/9600 sec) It seems, therefore, that changing the value of Di in the ATR does not change the value of the wwt, but changing the value of Fi does. Is this what the writers of 7816-3:1997 meant? I don't think so, because the wwt required is related to the values of clock sent to the card, the internal structure of the card's CPU and clock processing circuits, and the application algorithm programmed into the card. Changing Fi and Di doesn't change the way that the card runs its application code, and so should not change the wwt - but changing Fi does change the wwt. FI from the card, besides influencing I/O bit rate, also indicates the max clock frequency that the card can be run at. So: FI = 0 (means Fi = 372), Di = 1 gives a bit rate of 9600 in our example, a wwt of 1 sec, and indicates (Table 7) a max clock frequency of 4 MHz (typical for a card run at 3 Volts Vcc) FI = 1 (also means Fi = 372), Di = 1 gives a bit rate of 9600 in our example, a wwt of 1 sec, and indicates (Table 7) a max clock frequency of 5 MHz (typical for a low cost card run at 5 Volts Vcc) FI = 3 (means Fi = 744), Di = 2 also gives a bit rate of 9600 in our example, but changes the wwt to 2 sec, and indicates (Table 7) a max clock frequency of 8 MHz (e.g. for a Hitachi 3109 card as used by rollout spec Mondex in a single application environment) Regards, Peter Tomlinson 34 Strathmore Road, Horfield, Bristol BS7 9QJ, UK phone fax +44 (0)117 951 4755, mobile +44 (0)7968 947021 email [EMAIL PROTECTED] , web www.iosis.co.uk - Original Message - From: Carlos Prados [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, June 02, 2001 6:39 PM Subject: MUSCLE Work Waiting Time question Hi, I need some advice to interpretate the ISO 7816-3 normative: ISO 7816-3 states that the Work Waiting Time for T=0 is calculated as follows: wwt = 960 * D * WI * work etu. I use this value as timeout for receiving chars from the card. I'm not sure how to calculate this value when etu = 1/9600 s (default value when there is no PTS): a) work etu = (1/D) * (F/fs) where fs=3571200 So wwt is equals to: wwt = 960 * WI * F / 3571200 For a cyberflex this gives 1376 ms and for cryptoflex 3200 ms. b) Use the actual work etu (1/9600 seconds): wwt = 960 * D * WI * (1/9600) For cyberflex this gives 8000 ms and for cryptoflex 3200 ms. Any advice is welcomed. Thanks, Carlos. __ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.com/ *** Linux Smart Card Developers - M.U.S.C.L.E. (Movement for the Use of Smart Cards in a Linux Environment) http://www.linuxnet.com/smartcard/index.html *** *** Linux Smart Card Developers - M.U.S.C.L.E. (Movement for the Use of Smart Cards in a Linux Environment) http://www.linuxnet.com/smartcard/index.html ***
Re: MUSCLE pcsc configuration question answered
While there are some RS232 powered readers, they cannot be ISO 7816 compliant for Vcc supply to the card (cannot supply enough current). But if you purchase both the readers and the cards from the same supplier, he may be able to guarantee performance of his cards with his readers (which means that his cards take less power current than the maximum limit in the ISO spec). However, be sure to test card and reader with the type of PC that you are going to use, because different types of driver ICs in the PC have different source impedances. Regards, Peter Tomlinson, Bristol UK - Original Message - From: Christian CARNAT [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, April 27, 2001 1:24 PM Subject: RE: MUSCLE pcsc configuration question answered what do you think about a RS232 powered reader ? (versus keyboard connection) Christian CARNAT Smart Card Interfaces Business Unit Marketing Manager Net Devices direct : + 33 (0) 442 366 691 fax: + 33 (0) 442 365 545 mobile : + 33 (0) 607 986 590 GEMPLUS Card International please note : GEMPLUS DEVELOPER CONFERENCE 2001 June 20-21 - Paris - France http://www.gemplus.com/gdc2001 -Original Message- From: Logi Ragnarsson [mailto:[EMAIL PROTECTED]] Sent: Friday, April 27, 2001 10:38 AM To: [EMAIL PROTECTED] Subject: MUSCLE pcsc configuration question answered Hi all, I found the problem to my symptom on my own and then, of course, the solution was obvious. The reader I had connected to the serial port did not match the driver I was using. Both are Utimaco readers with no markings and the only visible difference is that one draws power from the keyboard connector while the other just uses the power from the serial port. I connected the correct reader (which I found by chance laying in storage) and everything works. -- Logi Ragnarsson - [EMAIL PROTECTED] Some day we all shall be out of scope *** Linux Smart Card Developers - M.U.S.C.L.E. (Movement for the Use of Smart Cards in a Linux Environment) http://www.linuxnet.com/smartcard/index.html *** *** Linux Smart Card Developers - M.U.S.C.L.E. (Movement for the Use of Smart Cards in a Linux Environment) http://www.linuxnet.com/smartcard/index.html *** *** Linux Smart Card Developers - M.U.S.C.L.E. (Movement for the Use of Smart Cards in a Linux Environment) http://www.linuxnet.com/smartcard/index.html ***
Re: MUSCLE Uploading and activating Cardlet on a Schlumberger Access (Newbie question)
Bitter experience is showing that card software (OS) developers are treating ISO 7816-4 as a smorgasbord, choosing what they want to implement, and even choosing which parts of a command definition to implement. Towards the end of 7816-4, in the area of optional methods for a card to indicate what it does and does not support, such practices are given some encouragement, for example by allowing a card to indicate whether or not it implements direct AID addressing to select an application (that in particular is the one annoying me as I try to help make sense of the (draft) ITSO public transport spec at www.itso.org.uk). If you want to build a card scheme, the rule has to be to only use the features of a card that the supplier documents as part of the contract to supply the card. Unfortunately, many of the required documents are subject to non-disclosure agreements, which doesn't help when trying to spec an interoperable set of schemes. Can anyone provide a dual interface ISO 7816 and 14443 card platform that supports direct AID addressing for application selection? Regards (or should it be commiserations?), Peter Tomlinson - Original Message - From: "Friendly Aless" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, April 02, 2001 7:18 AM Subject: Re: MUSCLE Uploading and activating Cardlet on a Schlumberger Access (Newbie question) Jan, Many thanks for your response - also all the others - many thanks. I agree that the error status indicates the length of the APDU to wrong. However, the APDU in question that is generated in the example code starts with the bytes [00 08 00 00 1B 1B bytes]. I already verified the APDU size and the length 1B is correct. Isn't it possible that this APDU is not know to the Cyberflex Access card but to the Cyberflex 16k only? The reason why I am asking this is that there is no [00 08 00 ...] APDU documented in the Cyberflex Access Software Developer's Kit 2 Release Notes (page 117f). The other thing I do not understand a 100% yet is the signing of the applet. Do I need to sign the applet only or do I need to sign the whole container? What's the key to use and what's the algorithm/tool to use? (I am looking at the packages opencard.opt.applet.mgmt.* and com.slb.opencard.CyberflexAccess.* right now). --- Jan Peter Hecking [EMAIL PROTECTED] wrote: On Thu, Mar 29, 2001 at 07:08:55AM -0800, Friendly Aless wrote: makeLoadAPDU() [00 08 00 00 ...] is sent to the card. The card simply returns 6700 - what does that mean? The status words returned by the card are defined in ISO 7816-4. Search the web to find the full document. 0x6700 means "Wrong length" so the Le (length expected) byte of your APDU seems to be incorrect. __ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/?.refer=text *** Linux Smart Card Developers - M.U.S.C.L.E. (Movement for the Use of Smart Cards in a Linux Environment) http://www.linuxnet.com/smartcard/index.html *** *** Linux Smart Card Developers - M.U.S.C.L.E. (Movement for the Use of Smart Cards in a Linux Environment) http://www.linuxnet.com/smartcard/index.html ***
Re: MUSCLE Transaction times
David, Why reset the card twice? ISO doesn't say that the card must always give the same ATR from a warm reset as from a cold reset, and EMV in particular take advantage of this to insist that the card must send a 'basic ATR' (i.e. one which says 'I will run with the startup parameters, but here is the protocol (T=0 or T=1) that you need to use') after a warm reset. The rule in schemes that I have worked with is always to go with the cold reset ATR if you can use it, and thus get the transaction over as fast as possible. Generally, a card will complete the sending of the ATR within a few hundred milliseconds. Many cards complete sending the ATR within 100 msec of lifting the reset line. ISO allows a lot longer than this before timeout in the terminal, but EMV decided (quite sensibly) to shorten that time (to 1 or is it 2 sec to complete the ATR? - can't remember exactly). Peter T Bristol UK - Original Message - From: "David Corcoran" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, February 27, 2001 3:02 PM Subject: Re: MUSCLE Transaction times Hi Michael, The Reflex 60 driver reset's the card twice most likely (cold/warm) On removal there is no reset but on insertion these reset's occur - the driver goes into a sleep waiting for this to happen - I am sure you can shorten this amount of time and I would be glad to help you if you send me a mail directly [EMAIL PROTECTED] Dave David Corcoran Purdue University 1008 Cherry Lane West Lafayette, IN 47906 [EMAIL PROTECTED] 765 - 532 - 6006 http://www.linuxnet.com *** Linux Smart Card Developers - M.U.S.C.L.E. (Movement for the Use of Smart Cards in a Linux Environment) http://www.linuxnet.com/smartcard/index.html *** *** Linux Smart Card Developers - M.U.S.C.L.E. (Movement for the Use of Smart Cards in a Linux Environment) http://www.linuxnet.com/smartcard/index.html ***
Re: MUSCLE Smartcard program?
At risk of being declared off the topic, I add the following: The situation can be even worse than Guido describes, because ISO allows a card to refuse to accept (which means that it will give an error response) standard ISO 7816-4 file handling commands unless a prior mutual authentication sequence between card and reader has been successfully carried out. Thus, even when the card contains only data files, and as someone else wrote, the card is not like a floppy disk. It is only very recently that attempts have begun to standardise the security methods so that there might be a migration to universally accessible cards and universal (or "vanilla") readers - but this standardisation is not being carried out at the level of ISO 7816; it is being carried out by a variety of groups for whom such standardisation is, or might be, useful. eEurope, CEN TC224 WG11 and national mirror groups (e.g. in France), ITSO (public transport ticketing in the UK), PKCS#15 group in the USA - these are a few that I know. We are really looking for standard application algorithms and associated standard security procedures (both for the app and for the card platforms that those apps may wish to reside on) - and it may be necessary for cards to carry related platform level and application level security scheme and key set ID in a standard manner in order to implement this. For those in the UK, the Smart Card Club (Smartex Ltd, www.smartex.com) and ITSO (www.itso.org.uk) will be places to look, and I am coordinating the collection of information for Smartex. More generally in Europe, eEurope Trailblazer 7 on multi app cards is the place to go. Peter T Bristol UK - Original Message - From: "Treutwein Guido" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, February 06, 2001 8:01 AM Subject: AW: MUSCLE Smartcard program? -Ursprngliche Nachricht- Von: Angie Mitchell [mailto:[EMAIL PROTECTED]] Gesendet am: Dienstag, 6. Februar 2001 03:31 An: [EMAIL PROTECTED] Betreff: MUSCLE Smartcard program? It seems that a lot of the apps ive found are application specific.. a gsm card viewer, dss software, blahblahblah. I jus want something that will show me whats on the card, regardless of what kind of card it is. I am prolly asking for a lot and I am new to this so if there is something I'm missing, please enlighten me :) Much thanks.. Angie.M Hi, unfortunately the generic application to show everything on a ISO or GSM processor card is impossible. The only command, which is guaranteed to work in ISO is "Select File", because that is independent of the security status. This will only give you the information, that a file with the id given exists. If you are not able to determine from the response, whether it is a dedicated file, (so you apply recursion there) the journey ends here. (The response may well be proprietary, so standards don't help much and you need a manual for the card in question to interpret the response finding out file size, type, etc) Of course, the card might support the PCSC DIRECTORY command to speed up the process, but if no strictly standardised application demands that from the card ... So you end up knowing which files exist. If you have no further information about the application you will also not know, which access rights to acquire using which pins or keys, so you might not be able to read anything. But a tree view of the files on the card with non-descriptive ids is not overly impressive. Shortly summarised: a card is no floppy disk, and being designed to keep information for itself any application will have a hard job to visualise something. hth [EMAIL PROTECTED] *** Linux Smart Card Developers - M.U.S.C.L.E. (Movement for the Use of Smart Cards in a Linux Environment) http://www.linuxnet.com/smartcard/index.html *** *** Linux Smart Card Developers - M.U.S.C.L.E. (Movement for the Use of Smart Cards in a Linux Environment) http://www.linuxnet.com/smartcard/index.html ***
Re: MUSCLE Checksum for T=1 protocol
C.V., You must get yourself copies of ISO 7816 part 3 (current edition published in 1997) and part 4 if you are to be sure of implementing its features correctly. Your national standards organisation should be able to sell you these documents. If you are having trouble getting the documents, please email me, including information about which country you are in, and we will see what we can do to help you from the UK. Regards, Peter Tomlinson Bristol UK email [EMAIL PROTECTED] , web www.iosis.co.uk - Original Message - From: "ChongVa Cheong" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, February 07, 2001 2:41 AM Subject: MUSCLE Checksum for T=1 protocol Dear all, What kind of checksum will be use for the T=1 protocol ? (CRC or BCC ? how many bytes should be ?) Is the checksum type defined in the ATR string ? Thanks for any help. Regards, C.V. Cheong *** Linux Smart Card Developers - M.U.S.C.L.E. (Movement for the Use of Smart Cards in a Linux Environment) http://www.linuxnet.com/smartcard/index.html *** *** Linux Smart Card Developers - M.U.S.C.L.E. (Movement for the Use of Smart Cards in a Linux Environment) http://www.linuxnet.com/smartcard/index.html ***
Re: MUSCLE Protocal Specs..
T=14 is the indicator for proprietary protocols. Information about a particular card's T=14 protocol can only come from the supplier. EMV does indeed have a description of a protocol called T=1, but its a bit different (in control parameter definitions and error recovery) from ISO - but neither ISO nor EMV implement a complete state machine for T=1. ISO standards are copyright of ISO. Peter T - Original Message - From: "Angie Mitchell" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, January 30, 2001 7:25 AM Subject: MUSCLE Protocal Specs.. Hi all.. I'm fairly new to programming/scard technology and what not, but I'm looking for the Protocal Specification on the T=0, T=1 and the T=14 protocals. Does anyone know where I could find this information? I've searched the web an I havent found a lot on it.. I've found bits an pieces.. but nothing that looks like a full spec.. perhaps I'm mistaken..? Any information would be gratefull.. thanks in advance.. angieM *** Linux Smart Card Developers - M.U.S.C.L.E. (Movement for the Use of Smart Cards in a Linux Environment) http://www.linuxnet.com/smartcard/index.html *** *** Linux Smart Card Developers - M.U.S.C.L.E. (Movement for the Use of Smart Cards in a Linux Environment) http://www.linuxnet.com/smartcard/index.html ***
Re: MUSCLE PTS commmand
Yes, Jim, I agree. But it should also tell the app in the terminal what it has selected. Peter Tomlinson Bristol UK - Original Message - From: "Jim Rees" [EMAIL PROTECTED] To: "Smart Muscleheads" [EMAIL PROTECTED] Sent: Sunday, January 07, 2001 10:38 PM Subject: Re: MUSCLE PTS commmand I think the driver should take care of protocol selection, and choose the "best" available (highest speed, prefer T=1) without bothering the application with the details. That's how my Todos/PC3 driver is written. Does anyone agree with me? *** Linux Smart Card Developers - M.U.S.C.L.E. (Movement for the Use of Smart Cards in a Linux Environment) http://www.linuxnet.com/smartcard/index.html *** *** Linux Smart Card Developers - M.U.S.C.L.E. (Movement for the Use of Smart Cards in a Linux Environment) http://www.linuxnet.com/smartcard/index.html ***
Re: MUSCLE how to get the size of a memorycard?
Do you know if your cards comply with ISO 7816? Or perhaps they use one of
the other interface protocols not recognised by ISO (e.g. I2C). Or maybe its
the other way round: your cards are 7816 compliant but the reader is not.
Memory cards are an area where you have to be sure that the card and reader
match each other, and that means you have to have the suppliers'
specifications.
Peter
- Original Message -
From: "Henning Koester" [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Friday, December 08, 2000 12:31 PM
Subject: Re: MUSCLE how to get the size of a memorycard?
Hi,
Ok thanks. But I've got a problem. I have 3 memorycards. 2 "normal" ones
and
one card with a PIN authentification mechanism. Only this card returns a
ATR when I send:
unsigned char GET_ATR[] = { 0x20, 0x12, 0x01, 0x01, 0 };
What's the problem?
Thanks
On Fri, Dec 08, 2000 at 09:05:04AM -, Guillaume LAISNEY wrote:
Hello,
You can get the size of a memory card from the second byte of its ATR.
According to ISO 7816-3, the 3 LSB of this byte define the length of
data
units (in bits), and its 4 next bits, the number of data units as :
= No size specified
0001 = 128 data units
0010 = 256
0011 = 512
0100 = 1024
0101 = ???
...
Example :
ATR = 92 23 10 91
23 - 0 0100 011 -0100 data units , 011 bits per data unit
This card is a 1 kb memorycard...
Regards.
Guillaume.
***
Linux Smart Card Developers - M.U.S.C.L.E.
(Movement for the Use of Smart Cards in a Linux Environment)
http://www.linuxnet.com/smartcard/index.html
***
***
Linux Smart Card Developers - M.U.S.C.L.E.
(Movement for the Use of Smart Cards in a Linux Environment)
http://www.linuxnet.com/smartcard/index.html
***
