On Wed, 2010-07-14 at 21:18 +0200, Andreas Jellinghaus wrote: > eToken 72k are javacard based. > thus you need: > 1.) make sure you have a special test/developer edition, where you can > store your own javacard applet. if not, you have one with the aladdin > applet on it - which works only with the aladdin software. > (they make more money by proprietory bundeling token and client software...)
Hm. The wiki seemed to suggest that they were a *good* company, which is why I went for this when the "GnuPG v2" card failed. I assume there isn't enough interest in reverse-engineering it and providing real support? If their crap fits between a low-level communication layer that we provide, and a higher level that we also provide.... surely that shouldn't be so hard? > 2.) if you have a developer token, you can store an applet on it, that > opensc supports. once that is done, you can use it with opensc. Ah, OK. So when the wiki just says "make sure you have one that's CCID-compliant", it could do with updating? It was sent to me as a sample. I specified a CCID-compliant one, since that's what the wiki said. How would I check whether it's a special test/developer edition? > the only open source applet opensc supports is the muscle applet, > and its support is not 100% - you can get it to work, but while opensc > supports many different and complex setups with some cards, for muscle > card only a few special setups work and are supported. > > the wiki has more information on the musclecard applet (some if it might > be in the "cyberlex" section - cyberflex was the first javacard widely > available, and tools that work with it, should work with all the other > javacards and tokens with javacard inside as well). > > yes, the situation is a bit disappointing. every gread card or token > that works great with opensc is no longer sold, outdated, hard to get > etc. (cryptoflex from schlumberger was great, no longer sold. > aladdin etokens 32k/64k were great except for the cardos problems > (secret startkey) - replaced with the java based token. ikey3000 with > starcos was great - never was sold in volume as far as I know (and > most starcos cards or token are not the eraseable "test" edition that > is inside ikey 3000). > > we could improve by supporting new cards like acos5 - noone found time > for that so far - or writing/improving the javacards applet and the > driver for them - noone found time for that either. Ok, thanks for the summary (depressing though it is). I'm beginning to suspect that for someone like myself who just wants to test NSS/sysdb interaction with external PKCS#11 modules, my best option is just to crawl back under my rock and write a sane PKCS#11 plugin for a TPM¹. Or failing that, to make the GnuPG v2 card work -- at least I have docs for that and "all" I have to do is try to get a clue about ISO7816, PKCS#15 and how the opensc stack fits together. -- dwmw2 ¹ One that doesn't involve openCryptoki, and that actually works. _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
