Andreas Jellinghaus wrote: First of all: congrats to the big job you and other people do with OpenSC!
>hmm, what exactly is the problem you are trying to solve? I may need to start with some background info.... If you wanted to put client-certificates in phones using processes that could be used by "mere mortals" (which is something that I work with in my day-job), you will soon find out that all devices are different and therefore this is not really possible on a major scale. So, I started out trying to define a complete infrastructure from trusted HW, middleware, to browser-based enrollment/provisioning protocols for this very purpose. However, my (negative) experiences with standardization of security protocols as well as my current work which also involves smart cards, convinced me that the project would have a better chance of succeeding if it also embraced PCs and applications like on-line banking. I theory the financial sector could have solved this but as somebody put it: "VISA has 2000 bosses" (member banks) so it seems unlikely to ever happen. Anyway, in order to provision keys with associated attributes using on-line methods rather than a CMS (Card Management System), you indeed need a "smarter smart card" because current smart cards do not have attestation keys and air-tight methods for adding attributes to keys. You are right that this project will face similar issues as existing smart cards, but there is one big difference: there is no file-system which I guess is the reason to why every EU eID seems to require a patch in OpenSC. There is just a rather simple API with typed attributes that you bind to keys. PINs and PUKs are of course fully integrated in the provisioning protocol including policy. Unlike existing smart cards, the "smarter smart card" also supports on-line management of keys by *independent* issuers using "air-tight" methods. This is of course primarily of importance in phones but I see that a universal key-ring in the form of an USB stick combining mass-storage and a gazillion keys could be interesting, at least of the add-on cost is a dollar or two. The "smarter smart card", could also serve as a perfect "replacement card" for conventional smart card deployments, since it should be possible to buy it everywhere as well as be personalizable in the field using any computer. If you feel that this was way too much of marketing BS, you may take a peek in the following document which shows the foundation for "air-tight" provisioning: http://webpki.org/papers/keygen2/session-key-establishment--security-element-2-server.pdf Regards Anders ------- sure, writing software for smart cards is hard, but inventing something to replace smart card + reader doesn't solve all the issues you need to think of. if you have a similar device, you will have mostly the same basic issues you need to tackle, no matter if you have iso 7816 and smart cards, or usb and micro processors. (for example: storage format for data, access control for all parts, encrypted or plain communication, one or several authentication layers (PIN), security schemas, role out scenarios, integration with application, concurrent alternating access or single-sign-on access mechanism, etc.). "smarter smart card" sounds strange to me, as with all the many problems I see with smart card software/solution packages, I never thought "those smart cards aren't smart enough". so why smarter? one big issue I see is the incompatibility, not-invented-here and "special" solutions everywhere (partly for historic reasons, partly for commercial reasons). adding one more "new" schema doesn't reduce that. implementing a solution without thinking aiming at compatibility, but getting a well working solution done, that could be done with current technology as well - for example java cards, ccid readers, pcscd, and a software on top, for example an enhanced opensc. so why move away from proven technology? I'm no expert on java cards, but at least ccid standard and pcscd seem to work very well, why replace them? still your work would be very interesting, if it is open and thus can be used on other plattforms. for example to run a client software providing the same usb interface on mobile phones (some simple software to keep keys, sign data, hand out public date). the very simple input/output system you presented: I don't get it. don't you need all that meta information in one way or some other? (e.g. token info, meta data such as serial number, list of certificates and their content, list of pub/priv keys, list of pin objects, etc. etc. etc.?) I don't see how you can simplify all that without reducing the typical functionality by far. or is that the goal? what functionality should be provided in the end? Regards, Andreas _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
