Hello, On Mon, Apr 25, 2011 at 15:33, jons...@terra.es <jons...@terra.es> wrote: >> About "User Consent" AKA "popping up notice windows about what the >> user is about to do" as well as ticket #232 [1]. > >> I still believe that it is mostly politics to delegate responsibility >> :) What it tries to "protect" from or inform the user of, the chosen >> technical mechanism is IMHO far from being enough. From purity vs >> practicality point of view, in the context of PKCS#11 applications for >> example, it would be the responsibility of the application to display >> application specific notices if the signature to be given is in fact >> given with an application that is meant for giving digital binding >> signatures. For example, NSS thinks that non-repudiation keys are OK >> for web authentication, giving a popup about legally binding >> signatures if the end result is a SSL session is not appropriate. > > You're right, but in the Real World very few apps take care on these > items as they should.... For instance: OpenOffice doesn't ask user > approval for signing documents; ever worse: doesn't check "key usage" > flag on the selected certificate. In the testing process of DNIe I've found > too many apps that silently sign documents... All these "funny" apps > made me change my opinion about "user consent".... > > (Notice that OpenDNIe does not ask user pin: only uses popup windows to ask > confirmation for the signature procedure, just before sending proper APDU)
Yes, there are reasons for such notifications, in this case too loosely implemented existing applications and a "fix by patching" solution to filter such possibly unwanted operations (which usually do NOT result in a binding contract). Yet I've heard that there are policies in some countries where the popups are designed as legal requirements to technically (?) protect from unwanted signatures or to have a "certified legal warning" for signature operations. Which are worthless, as long as a piece of software on the host computer can still create a "silent signature" by knowing the user PIN code. If there are no hardware based elements in this scheme, the idea is useless. Nothing can force a piece of malware to use the "official" PKCS#11 module" or equivalent if they can send arbitrary APDU-s directly to the card instead [1]. Also, It might soon become as annoying as "are you sure you want to quit?" windows of some applications that don't have the "don't ask this again" option.... >> Nevertheless, the feature has usage scenarios (like fulfilling >> questionable policies). Some things to consider: >> * Where to implement it. Current implementation in a card driver is >> not the right place maybe, if the driver is used from a Tokend, a >> PKCS#11 or minidriver, GUI availability can vary. Thus it should be >> possible to control it based on an "interface driver" (PKCS#11 vs >> minidriver for eample) rather than card driver. > > So your proposal is create a separate file to store all user consent > operations, and call them when required. I agree: that's the way to work Yes, GUI related bits and pieces (which depend on the platform) should be split into a separate entity, be it a file, a namespace or something else. (There used to be ui.h/ui.c which did not do much). But the important differentiation would be to implement it on the "interface driver" level (PKCS#11, Tokend or minidriver), because they all fit differently to the overall system. Indicating the need for user consent can be done in individual card drivers (if the PKCS#15 user_consent field is not enough to tune it) >> * What to show to the user (and how). This includes i18n. > > i18n is not only related to user consent: any xxx-tool are also > candidates. Afaik Belpic card has also same i18n issues > (btw no i18n ticket found) Agreed. >> * Integration with the rest of the platform. I really like the >> concept of "trusted windows" or "stuff that is controlled by the >> system and harder to fake for malware" like the Windows UAC. OS X and >> Windows have mechanisms for this, although I'm not sure if/how >> difficult it is to jack into them. On Linux, maybe GnomeKeyring can >> provide some help (for Gnome desktops)? If the feature is to be >> enabled, it would probably be used in a desktop environment, so tuning >> for a smooth and integrated experience would be of great value. > > A problem arises in Linux: dependancy with external libraries at compile > time. > I've solved it in linux by using pinentry as an external tool, without > libassuan, > and declare in config file how to process and wich program to use Dependencies are not bad per se, it is just that they should be evaluated for a good purpose. Creating a GUI will anyway create dependencies, be them runtime or compile time ones. libassuan was only used to trigger a GUI in the mozilla-signer module. Maybe libassuan *is* the most appropriate tool on Linux for example, I don't know. The description for it tells "Libassuan is the IPC library used by some GnuPG related software." which does not seem to suggest that it should be the best tool for displaying a GUI in software not related to GnuPG (which, I admit, is quite standard piece of software on Linux) The options on Linux are much broader than on Windows or OS X, and the definition of "close to platform" varies depending on viewpoint and personal preferences. Yet I'd be willing to sacrifice some "modular unix piping" in favor of "feels like integrated with the rest of the desktop" experience. Thus maybe Stef can suggest what GnomeKeyring does in this matter or what could be implemented in tandem. >> I can figure out at least these different popups: >> 1 - "Legal warning" + plaintext PIN entry >> 2 - "Legal warning" + "Please enter PIN on pinpad" >> 3 - "Please enter PIN on pinpad" message >> 4 - Faked secure PIN entry in PKCS#11 driver and "Please enter PIN" >> window for plaintext PIN >> 5 - "Please re-enter PIN" window, as described in #232 >> 6 - "Plaintext PIN entry forbidden by policy" > > 7 - "You'are about to emit a digital signature. Please confirm operation" I added a link to this list to the #232 ticket. [1] http://blog.eset.com/2010/11/05/dr-zeus-the-bot-in-the-hat _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
