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
