Hello, On Jan 26, 2011, at 9:46 PM, Andreas Jellinghaus wrote:
> Am Mittwoch 26 Januar 2011, um 12:12:42 schrieb Nikos Mavrogiannopoulos: >> I don't understand what you mean by a reasonable enrollment system, however >> having seen the EMV protocol, I believe that the available PKCS #11 >> compatible smart-cards have a much higher security level than EMV bank >> cards. It seems the only criteria for banks evaluating protocols and >> technologies is their complexity. > > hu? can you go into details? > > I learned a lot about EMV in the past 10 months, and it doesn't seem hard > to me. Of course there is a lot of complexity involved, but it is a partly > online partly offline payment system with a very complex decission system > (accept transaction offline or online or decline based on many different > factors that can be personalized as parameters). > > a pure pkcs#11 card has something like 10% of the number of features that > an EMV card has? so comparing those two and complaining about complexity > seems to be quite unfair to me. This makes no sense. EMV cards are not general purpose crypto tokens which PKCS#11 addresses. You should know that comparing EMV to PKCS#11 is comparing apples to oranges. My personal rhetorical/sarcastic opinion is that the overall goal of EMV is more about practical risk/cost/profit balancing where change happens only when there is a possibility to lower costs or increase profits (lowering costs can mean cutting losses from 100M to 25M per month if the solution to do this costs only 74M per month) whereas the PKI we know (like SSL/TLS) is more a theoretical crypto application practice, which is based more on academical research and idealistic "air-tight" approach. Yes, there are compromises in PKI implementations as well, like storing plaintext keys, where the risk/cost calculation suggests it would be OK or where the data is protected by other processes or mechanisms. I'm 99% sure that banks would not give a s*** about crypto if they could run their businesses without it, with minimal losses, maximal sales and maximum profits and if there was no law that required it. Unlike crypto researches, who actually do care about the properties of t heir work and sound, air-tight solutions. Nevertheless, IMHO JavaCards have even more features than "EMV" or "PKCS#11" cards ;) Yet this claim makes as much sense in this context as the previous ones. > Still I think we could learn from EMV and friends, for example companies > with many employees might want a system to change cards in some remote reader > in a secure way. Some banks can do that with scripting on emv cards, and the > mechanism involved don't seem so hard. Something like that (e.g. to unblock > or change the pin on a card connected to some machine remote) could be nice > for opensc users too. Secure channel with a remote token management center? That's being worked on right now (secure messaging) but which is not thinkable as a generally available management option in OpenSC. Such management creates new risks and/or extra requirements for key management, as well as requires certain infrastructure and software which is not available for OpenSC or would be simple to set up (securely). Compare to "signing certificates with OpenSSL" vs "running a CA". Current generally available management view of OpenSC is based on PIN codes, quite static "transport codes" and a security officer (with a PIN code). For example, some tokens can be erased without any authorization. OK for some controlled environments or home uses, totally not cool in other situations. But it would be a nice addition, sure. I hope it will happen one day. I hope this will be brought up on FOSDEM as well. I'm sure I'll use the chance to discuss provisioning with Anders :) Cheers, Martin -- @MartinPaljak.net +3725156495 _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
