Two PCSC-lite design questions come up, in the discussion context of backdoors and their opposite: assurances and the definition of the secure enforcing functions (SEFs) provided.
(a) how does the architecture support tuning of, and knowledge of, the "security" channel between PCSC resource manager and the reader? For example. the oft-cited towitoko driver adjusts a (non-security) property - the baud rate on the N-link between host and reader, as APDUs alter the tranmission properties used on the N-link between the downstream reader slot and an ICC. The frame driver could also do a PPS negotiate behind the scenes whenever it sees fit - to invoke a "propreitary" T.14 protocol, susceptible to wiretapping.
(b) how does a PCSC client or muscle client learn throgh the API what secure messaging properties are being performed by PCSC-lite deamon (or an IFD), or are available for exploitation by the applet?
In the Microsoft case of PC/SC, a client can know and test the signatures/cert on the IFD drivers and the OS DLLs, to know what the deamon is doing on its behalf. That is, the PCSC can be assured to provide a trusted path SEF to the secure messaging SEFs, when the client authorizes the infrastructure to perform secure messaging on its behalf.
Academically, the issues are a version of the traditional debate distinguishing layer 4 and layer 3 security: SSL vs IPSEC, SP4 vs SP3, DMS message vs NATO circuit switched crypto etc. Appropriately, I'm making no assumptions that the drivers for debate resolution that are appropriate for IP in WANs and LANs are the same for the network between a host and ICCs. THe channel between Pentium chip in the host and ARM chip in the ICC is exactly that - a board-level chip-to-chip design issue, not a IT system to IT system design question: the design criteria for layer placement of secure messaging and supporting API design are likely to be different.
From: "Amira Solomovici" <[EMAIL PROTECTED]> Reply-To: MUSCLE <[EMAIL PROTECTED]> To: "MUSCLE" <[EMAIL PROTECTED]> Subject: RE: [Muscle] GemPC430 on Mac OSX 10.3 problem Date: Sun, 21 Mar 2004 07:19:02 +0200
Hi,
I replaced the driver but the error persists - pcsc-lite-1.1.2beta4 does manage to load the driver.
Also, any idea why the SCardStatus fails on Mac? I tried with the older version pcsc-lite-1.0.1 and the command succeeds there, but I need the PCSCLITE_ENHANCED_MESSAGING definition in order to use extended T=1 apdus and this define doesnt exist in this old version (is it ok to simply change the value of MAX_BUFFER_SIZE?).
Thanks, Amira.
-----Original Message----- From: Ludovic Rousseau [mailto:[EMAIL PROTECTED] Sent: Thursday, March 18, 2004 9:44 PM To: MUSCLE Subject: Re: [Muscle] GemPC430 on Mac OSX 10.3 problem
Le Thursday 18 March 2004 � 13:44:04, Amira Solomovici a �crit:
> I also tried to use the latest pcsc-lite-1[1].2.0.tar.gz, but this one failed to load the driver (readerFactory.c:: RFAddReader: GemPC430 init failed).
Try again with ifd-gempc-0.9.1 [1].
Bye,
[1] http://ludovic.rousseau.free.fr/softwares/ifd-GemPC/
-- Dr. Ludovic Rousseau [EMAIL PROTECTED] -- Normaliser Unix c'est comme pasteuriser le camembert, L.R. -- _______________________________________________ Muscle mailing list [EMAIL PROTECTED] http://lists.drizzle.com/mailman/listinfo/muscle
_______________________________________________ Muscle mailing list [EMAIL PROTECTED] http://lists.drizzle.com/mailman/listinfo/muscle
_________________________________________________________________
Get reliable access on MSN 9 Dial-up. 3 months for the price of 1! (Limited-time offer) http://click.atdmt.com/AVE/go/onm00200361ave/direct/01/
_______________________________________________ Muscle mailing list [EMAIL PROTECTED] http://lists.drizzle.com/mailman/listinfo/muscle
