(a) Finding the usbccid.sys for the standard product/vendor ids is hard. As yet, despite searching windows update, still no luck. Its well hidden, if its there. The description suggests its support is quite thorough, compared to other implementations Ive seen. I really want it for review; this issue is getting more interesting by the day.
(b) Only one reader is cited in the catalog as "designed for windows". Many others (including many CCID-marketed devices) are merely cited as "compatible with windows". The latter may well not use the MS driver, introducing their own class driver into the USB stack.
(c) "Designed for windows" has compliance rules, which would affect CCID modes of interfacing to muscle cards, on one of the other topics in current threads from datakey, including:
"� For cards that support Information Field Size integrated circuit Card (IFSC) requests, the first transmission�after a reset of the smart card�must start with an Information Field Size Device (IFSD) request, as defined in ISO/IEC 7816-3, Amendment 1, Section 9.5.1.2.
For cards that do not support an IFSD request (that is, the card replies with an R-Block indicating �Other error�), the transmission must continue with an I-Block.
After a successful RESYNCH request, the transmission must restart from the beginning with the first block with which the transmission originally started."
(d) If there are, in fact, covert surveillance backdoors built into CCID driver designs, where the sources are either national companies under local government control or microsoft, we can assume that microsoft either does not know of the implied backdoor in the microsoft security design, or there there is international consensus on its backdoor properties. Either way, consumers are getting a reasonable deal.
(e) for muscle, we get to review the driver source code(s). In the spirit of open source, it will improve by the virtue of the process itself, and the resources actually available to the developer(s)! What licensees actually ship in their readers, based on the muscle code, is of course a different matter. For Volume licensees such as a Red Hat, or Apple, users will soon be back into the vendor-specific case of (d), however.
(f) life can be a little dangerous in this sphere. I know one American firmware/driver author on assignment in Russia, who claims to have been subject to paralysis/unconciousness-inducing gassing, while the hotel room was (ineptly) bugged for bus signal capture, while he programmed some stuff for his customer. All for a bit of bios security code! Im sure he'd have licensed it, for less than the cost of the gassing! Few developers really understand how the bios steals cycles from the CPU for its duties, and what else it can be induced to do, once the wint kernel can no longer even see the bus, during the bios' time slice. In USB stacks that cooperate with a US manufactured bios, the CCID drivers need very a careful security review.
Does libusb() in linux ever rely on an i386 or later bios? Worth looking into.
Peter.
From: Krister Walfridsson <[EMAIL PROTECTED]>
Reply-To: MUSCLE <[EMAIL PROTECTED]>
To: MUSCLE <[EMAIL PROTECTED]>
Subject: Re: [Muscle] CCID driver distribution issues, security, covertchannels
Date: Wed, 31 Mar 2004 22:04:43 +0200 (MEST)
On Tue, 30 Mar 2004, Peter Williams wrote:
> (b) It would be interesting to see how Microsoft's CCID- class driver > handles this. Strangely, unlike the PS2 driver for PC/SC signals, the > "standard" CCID driver doesnt actually seem to come with Windows... each > CCID driver version seems to come bundled with the smartcard reader. Any > info on whats going on here? What are the issues?
Microsoft is always late in providing class drivers. (And many companies think it is better to write their own drivers anyway, since that will make it easier to work around bugs in their hardware... So there is not that big a demand for generic class drivers.)
But a generic, somewhat limited, CCID driver has been available from "Microsoft update" for some time. See
http://www.microsoft.com/whdc/hwdev/tech/input/smartcard/USB_CCID.mspx
for the details.
> What issues force a different policy for raw CCID driver distribution, > compared to the case of the raw PS2 driver (for PC/SC)�?
Windows does always come with a lot of 3rd party drivers from Microsoft partners, to make their hardware work out of the box. The PS2 PC/SC driver is, AFAIK, such a driver.
/Krister _______________________________________________ Muscle mailing list [EMAIL PROTECTED] http://lists.drizzle.com/mailman/listinfo/muscle
_________________________________________________________________
Check out MSN PC Safety & Security to help ensure your PC is protected and safe. http://specials.msn.com/msn/security.asp
_______________________________________________ Muscle mailing list [EMAIL PROTECTED] http://lists.drizzle.com/mailman/listinfo/muscle
