On 2011-12-17 21:04, Ludovic Rousseau wrote: > 2011/12/17 Anders Rundgren <anders.rundg...@telia.com>: >> Hi Guys, > > Hello,
Good evening Ludovic! > >> As you already heard (to death?), I'm working on a "smarter smart card" which >> (with my definition) is a cryptographic module explicitly designed for >> on-line >> enrollment over the web [1]. >> >> Anyway, since my core competence is architecture as well as due to limited >> funding >> the low-level part is a true challenge so I need to "cut some corners" to >> not get stuck. >> >> One possible solution seems to be reusing existing OS-drivers like CCID and >> PC/SC. >> My questions to you *real* experts out there are: >> >> 1. Would extended APDUs be a suitable way supporting a completely "alien" >> API? > > Why wouldn't it? Just asking, I'm not the expert :-) > >> 2. What would be a good choice of emulation targets (USB reader+card) for not >> having to write a single-line of OS-dependent code or custom installation >> scripts? > > If you are using a token and not a smart card + reader I suggest to > use ICCD [1] instead of CCID. ICCD is a derivation of CCID for tokens. > Some useless functions have been removed (like card movement > notification) and may be simpler to implement. > > My CCID driver support both type A and type B of ICCD. Fine. > >> 3. Does existing drivers (P11s, CSPs) actually support any number of keys? > > I would say yes. But I do not know enough the internals of OpenSC to > give a definitive answer. Ok. > >> Although writing the device code is non-trivial, compared to grasping Windows >> driver framework etc. it seems fairly reasonable, at least if you are >> equipped >> with an USB line-analyzer and some useful emulation targets. >> >> Ideally , there would be a "composite" USB interface where legacy systems >> would use CCID while newer systems would talk "native SKS". Provisioning >> can only use the latter. > >>From your document you describe an API at the C (or equivalent) language >>level. Sort of. I have mapped it into Java as well. It is when you target connected tokens you need to be specific down to the bit- level like 7816. > How is your device supposed to be used? By a PKCS#11 application? > Using its own API? This is a good question. The ideal would be if the token could use an existing set of drivers for usage with existing applications. For Windows that it means that the emulated device must be supported by Windows Update. For other OSes I guess the only prerequisite is that there are free drivers available. Driver = whole stack. Any specific device (PKI token) that would fit this description? > Please give use cases and compare with existing solutions like Firefox > + PKCS#11 + smart card. When authenticating using TLS-client-cert-auth the existing SW stack would be used as is. I would like to avoid having to start with P11s and CSPs (if possible). An *enhanced* Firefox would through NSS extensions support a souped-up GUI where certificates would typically be represented as card images. However, the important addition is the enroll stuff which will require a deep hack in Firefox to accommodate a 10-pass protocol. . > It is quiet easy to talk to a "proprietary" USB device using libusb on > Unix. This could be integrated into the SKS library. It is a bit > different on Windows Wouldn't libusb interfere with CCID or PC/SC? My (maybe naive) hope was that CCID/ICCD would serialize APDUs so that the token would simultaneously speak "traditional" with legacy apps and SKS (wrapped in extended APDUs) with "new" apps. > Bye Cheers, Anders > >> 1] "Appendix A. KeyGen2 Proxy" in: >> http://webpki.org/papers/keygen2/sks-api-arch.pdf > > [1] > http://www.usb.org/developers/devclass_docs/DWG_Smart-Card_USB-ICC_ICCD_rev10.pdf > _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
