It always felt like a good idea creating a card-edge standard for tokens that only are used for login etc. That the methods for initializing cards as well as provisioning/managing credentials are even more non-standard than just "using" them was the ultimate motivator!
Slightly related. I wonder if the card industry is on the right track: http://java.sun.com/developer/technicalArticles/javacard/javacard-servlets Pardon me for interfering in the GnuPG/eToken discussions... /Anders On 2010-07-15 00:58, David Woodhouse wrote: > 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. > _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
