Hello, It is insecure if you use an insecure card with an insecure profile which does not require PIN verification (user consent) before every operation.
It does not matter if your card is "secure" and/or the application using the PKCS#11 module is built with security and usability in mind (not all of them are). The fact is that turning this on by default will prevent people from using any other software with their smart cards, which is is no better. Security is always a tradeoff between strictness and usability. A system that can not be used is not a secure system. In real life the card capabilities, matching OpenSC card drivers, application requirements and application behavior vary a LOT. It is turned off because many/most people want to use their card with multiple PKCS#11 applications (for example, Thunderbird and Firefox) simultaneously. While there are improvements to be made in locking behavior of OpenSC PKCS#11 (for example, locking the card for the duration of API calls that form a logical unit) and multi-application access, this configuration option is not a black and white, on-off security switch. A word of warning would nevertheless be a nice thing if it was accompanied with some documentation on what are the risks, what they actually matter and what could be done about them. That would require an accurate config file warning (the lock_login feature is by default turned OFF, not ENABLED as you have it) and the implications written down in wiki. There is a section that deals with it already [1]. The "Paranoid Setup" section should also remind people to perform personalization on dedicated, disconnected machine, use a PIN code of at least 6 digits and not to put their (FIPS/CC certified) card into a reader that does not have a certified pinpad firmware. Best, [1] http://www.opensc-project.org/opensc/wiki/SecureSetup On Aug 3, 2010, at 11:05 PM, Andre Zepezauer wrote: > Dear OpenSC developers, > > in the interests of the users of OpenSC, it would be fair to apply the > following patch. > > Kind Regards > Andre Zepezauer > > > Index: etc/opensc.conf.in > =================================================================== > --- etc/opensc.conf.in (revision 4620) > +++ etc/opensc.conf.in (working copy) > @@ -347,8 +347,12 @@ > # Thus the other users or other applications is not prevented > # from connecting to the card and perform crypto operations > # (which may be possible because you have already authenticated > - # with the card). This setting is not very secure. > + # with the card). > # > + # WE (THE OPENSC DEVELOPERS) ARE VERY AWARE OF THE FACT, THAT > + # THIS FEATURE IS INSECURE. NEVERTHELESS IT IS ENABLED BY > DEFAULT, > + # BECAUSE WE DON'T CARE ABOUT YOUR (THE USERS) SECURITY NEEDS. > + # > # Also, if your card is not locked, you can enconter problems > # due to limitation of the OpenSC framework, that still is not > # thoroughly tested in the multi threads environment. > > > _______________________________________________ > opensc-devel mailing list > opensc-devel@lists.opensc-project.org > http://www.opensc-project.org/mailman/listinfo/opensc-devel -- Martin Paljak @martinpaljak.net +3725156495 _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
