In my "defense in depth" orinetation, the "card" is everything - from layer 1 through layer 7 and layer8 (= cryptopolitics/deception/govtpolicy/audit-assurances etc.) This includes the wavelengths used on masking the die , the verilog (i.e. Hoare logic!) in the various controllers, the MMU supporting a COS process seperation, the io driver layer of the COS, and the applet instances(s) versus OPEN reference monitor model - in GP cards. If one reviews the research literature, its true the formal method research tends to restrict the analysis scope to operating system semantics - which is a shame.
If we take my example: I2C clock is being stretched by the card to perform low-level flow control (as a reader attempts to rx a bit) on the CIO and CCLK contacts; in parallel a 14333B packet is probably being received by the wireless controller, from the antenna loop on C4/C8.
Is the "card" sending and receiving at the same time?
The answer is surely yes - as a bit (or probably more) of tx data is sitting the inbound fifo of the wireless controller, awaiting javacard JCE driver layer's poll of the interface register, or completion of a DMA to RAM. In parallel, the smartcard controller is probably driving the levels of the I2C/SPI pins directly.While the COS tasks may be scheduled, the electronics is almost probably parallelised:I doubt one port is held in sync to another port, to enforce "inter-port synchronization." to suit a given Javacard JCE implementation. If the GP is setup right with security domain controllers, indeed the crypto for the association will be performed in the fifo handling, not the software COS, so that the hardware performs the security processing at the port level- way before the MMU even allows the plaintext to be access by a particular COS co-routine representing an applet.
If you inspect an actual javacard or mainstream COS source for uP class ICCs, are the lower layer io classes interrupt driven? In my training, the interrupt ring(s) on a classical 8bit ICC CPU are just another set of scheduled "threads" - either a traditional superloop concept, or a thread pool managed by the context switch in the irq wiring and register mapping of the controller. This context switching may not be managed by the javacard JCE (and is almost certainly not), but its there for security analysis of a "cards" signalling of data.
we have to stop thinking of smartcards in the German card design tradition - as a dedicated logic controller fronting memory or processor. When you put 1Mb of flash in a Sharp ICC, and 3 signalling ports, we have to analyse the result as a system not as a component. While javacard 2.1.x still shows vestiges of traditional smartcontroller thinking, the cards being designed to supprot .NET VMs have NO such assumptions! Its a tiny "computer" - not a "controller" We have to analyse it as such. Yes! our knowhow in evaluating systems under Common Criteria methods is really poor! Restricting the formal method analysis to the COS doesnt help, I feel.
But, as I said, its a fun question, with no right answer.
Peter.
From: "Damien Sauveron" <[EMAIL PROTECTED]>
To: "MUSCLE" <[EMAIL PROTECTED]>
Sent: Friday, December 03, 2004 2:11 PM
Subject: Re: [Muscle] send an receive data with SCardTransmit - Case 4 Short
Peter Williams a �crit :I think the answer is "no" because the OS of the smart cards are single thread and do not run applets "1", "2" and "3" in the same time.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.
Regards, -- Dr. Damien Sauveron
_______________________________________________ Muscle mailing list [EMAIL PROTECTED] http://lists.drizzle.com/mailman/listinfo/muscle
_______________________________________________ Muscle mailing list [EMAIL PROTECTED] http://lists.drizzle.com/mailman/listinfo/muscle
