Hi guys, Sorry for being mute, I had to work on other stuff. To answer the questions: our current setup uses an NSAPI plugin to handle all the authentication stuff. PIN (as you have guessed) is only used to "open up" the chipcard, all the cryptography magic happens inside the card's chip.
We present a well calculated hash based on the transaction, and input it to the plugin. The plugin connects to the chipcard through a chipcard / USB driver As the connection setup requires the PIN, the plugin pops up an input window for the user to enter it. If everything goes as planned, the chipcard returns with a code, which is communicated though the plugin to the html page, which is auto-posted to the server side, where the responses are checked. The connection to the chipcard driver is closed by the plugin, so next time anybody wants to sign something, the PIN has to be re-entered. Anyways, I checked quickly the current state of this stuff, and I can see some light at the end of the tunnel - the signTextJS plugin's source gives me lot's of hints. Too bad this topic is not really covered on the net. If I run into some problems, I'll let you know it. Thanks for your effort, much appreciated! hp 2015. október 12., hétfő 15:28:56 UTC+2 időpontban Eric Rescorla a következőt írta: > On Mon, Oct 12, 2015 at 5:01 AM, Gijs Kruitbosch <gijskruitbo...@gmail.com> > wrote: > > > On 12/10/2015 12:34, Eric Rescorla wrote: > > > >> On Mon, Oct 12, 2015 at 4:22 AM, Gijs Kruitbosch < > >> gijskruitbo...@gmail.com> > >> wrote: > >> > >> Are you effectively saying that you use crypto for signing financial > >>> transactions, and the PIN is used for authenticating the user but not > >>> involved in the actual signature/crypto algorithm? Therefore, if a user > >>> finds a way to invoke the same crypto without providing the PIN, they can > >>> effect financial transactions without being authenticated? > >>> > >>> Because tbh that sounds like a serious malware threat vector that you > >>> should fix in some way where it is theoretically impossible (rather than > >>> just practically difficult because of smoke and mirrors with native/NPAPI > >>> code) for the system to issue a signature without the PIN. > >>> > >>> IOW, fix your crypto, and all the other problems will go away as a > >>> consequence. > >>> > >> > >> > >> This (or at least something with a similar UX) is a totally standard > >> design: the cryptographic > >> keys are embedded in a hardware token and a local PIN Is used to obtain > >> access to the > >> token for the purpose of performing cryptographic operations with those > >> keys. The token > >> enforces the PIN check. Note that the purpose of the PIN isn't to protect > >> against > >> malware but rather to protect against loss/theft of the token. > >> > >> -Ekr > >> > > > > Sure, but the system you describe enforces the PIN assuming it outputs > > something (either directly via a USB connection/keycard/whatever, or that > > the user has to copy from the external device to an inputfield on the > > website or whatever) that is a function of the PIN > > > No, generally not. The PIN is used merely to acquire access, but if (for > instance) you > changed the PIN, it wouldn't change the output. > > > > since the most important use-case (for each operation, PIN has > >> > >>> to be entered) could not be enforced. > >>> > >> > > makes it sound like they are enforcing this orthogonally to all their > > crypto, by requiring it as input to their plugin/native chrome stuff, but > > not by actually involving it in the signature of the eventual transaction. > > That is what is broken (if I understand their setup correctly). > > > > All of the banks I've used in the past use a hardware device not linked to > > the computer that takes my chipcard, requires my PIN, and input/nonce > > identifying the transaction (number or barcode or whatever), and then > > produces output. The output I type (or screenshot or whatever) into the > > website. There's no need to use NPAPI or any other native goop to make that > > system work, but it also makes sense because the PIN (or PIN-unlocked > > crypto keys that are on the card) authenticate the transaction. > > > > The reporter's case sounds more like it's using NPAPI to obscure the fact > > that the PIN (or the card's keys) isn't (aren't) actually used to > > authenticate the transaction, but rather keys or other data that the plugin > > is holding on to. Moving all that code into JS for use with webcrypto would > > expose this, and therefore they want to keep the 'advantage' of native. > > > > What I am assuming is that they are using the NPAPI plugin to prompt for > the PIN > and then pass it to the card in order to convince the card to sign. And > that for > obvious reasons they don't want the JS to have access to the PIN. > > However, rather than perform hermeneutics on the original message, I > suggest that > we ask. Peter, can you describe in more detail how your system works and > what > you are trying to accomplish. > > -Ekr _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
