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
***************************************************************
