Last year, we paid a consultant to customize a Win32API-based activeX control,
so i would respond to reader-insert/removal events in a particular way. The
architecture required the control to sends those events through PC/SC events
...to listeners on the appropriate events. The idea was that any PC/SC reader
insertion/deletion on the browser's machine would be detected on the website -
for any PC/SC reader (not only CCID readers.) (Only pure CCID readers using
MSFT XP drivers were ever tested, tho,until recently when I investigated what
happens with Vista's "trusted" version of MSFT CCID drivers).
The hard part was ensuring (in Windows) that when a reader is inserted in a PC
connected to some host via RDP2 protocol... and then the user is using a remote
browser over RDP (wih remote activeX container!), that control can detect the
RDP-local machine's card/reader insertion events.
A different problem emerged when trying to work with open systems (going beyond
windows HAL and its own use of TPMs). How does the ultimate receiver of the
event authenticate the event's source, without asuming a vendor-independent
infrastructure such as TPM and root certs?
We were using the event to cause the ultimate webapp to start a GP auth process
with the card. Given most GP processs (on Javacard products) lockup the card
after n failed GP auths, we wanted some "assurance" to be delivered along with
the reader event and the card's ATR - before engaging in GP protocol. What we
were after was for the reader to have done its local finger/pin-auth to the
card, before releasing its own reader-insert event to the listener network. We
wanted the PC/SC event delivered to the ultimate webapp to deliver assurance of
"local control".
For now, we are simulating such "authenticated-event" infrastructure: logon to
musclecard (which has its own ping velicity logic and admin reset regime),
obtain signed challenge associated from card verified using the cert read from
the card, then engage in end-end SCP with the applet across any number
virtualized pC/SC cannels. The applet merely elegates APDU handling to he SCP
implementation library, and the app-domains keysets associated with the applets
app/security domain
> Date: Sun, 23 Mar 2008 16:11:43 +0100> From: [EMAIL PROTECTED]> To:
> muscle@lists.musclecard.com> Subject: [Muscle] new version available:
> pcsc-lite 1.4.100> > Hello,> > A new version of pcsc-lite is available [1].
> This version uses libhal> events instead of polling the USB bus to detect
> card readers> insertion/removal. pcscd will then consume zero CPU cycle when
> no> reader is connected. powertop [2] should be more happy.> >
> pcsc-lite-1.4.100: Ludovic Rousseau> 23 March 2008> - add libhal support to
> avoid polling the USB bus. libusb is still> supported but libhal is now the
> default> - improve performances in SCardConnect(), SCardReconnect(),>
> SCardDisconnect(). Thanks to Sean Wykes for the patch> - SCardListReaders():
> returns SCARD_E_NO_READERS_AVAILABLE when no> reader are available. Thanks to
> Thomas Harning for the bug report> - add support of TAG_IFD_POLLING_THREAD to
> use an asynchronous card> movements detection instead of an active polling.
> The reader driver> need to support TAG_IFD_POLLING_THREAD to use this
> feature> - CardCheckDaemonAvailability(): lower the priority of the log
> message> in case of "PCSC Not Running" or "PCSC restarted" so that nothing
> is> logged by default. PCSCLITE_DEBUG can be defined to see the message.>
> Programs linked with libpcsclite will not display anything if pcscd is> not
> running. Solves Red Hat bug 428299.> - default log level is
> PCSC_LOG_CRITICAL+1 so that NO log is sent to> stderr by default. You need to
> explicitly set PCSCLITE_DEBUG to have> logs. (in a library stderr(2) can be
> any file opened with fd=2 so> should not be used)> - ifdhandler-3.tex: more
> details about deviceName argument of> IFDHCreateChannelByName()> - some other
> minor improvements and bug corrections> > Regards,> > [1]
> https://alioth.debian.org/frs/?group_id=30105&release_id=1149> [2]
> http://www.lesswatts.org/projects/powertop/> > -- > Dr. Ludovic Rousseau>
> _______________________________________________> Muscle mailing list>
> Muscle@lists.musclecard.com> http://lists.drizzle.com/mailman/listinfo/muscle
_________________________________________________________________
How well do you know your celebrity gossip?
http://originals.msn.com/thebigdebate?ocid=T002MSN03N0707A
_______________________________________________
Muscle mailing list
Muscle@lists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle
