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 and then input to
the signature/crypto used to secure the transaction - IOW something that
isn't orthogonal to the PIN (or, assuming they are specific to the
chipcard, the keys on the card which authenticate that user and are used
to set up the signature, and which require a PIN for access).
The reporter's case, specifically:
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.
If the issue was simply interfacing the hardware they're using
(connected over USB/bluetooth/whatever) directly with webcrypto instead
of an NPAPI plugin, I doubt that will ever work. They could use an
add-on, with a native blob and stdin/out communication via child-process
in the add-on SDK, or subprocess.jsm in an old-style add-on, or whatever
the equivalent thing is under web extensions, as an intermediary between
the hardware and webcrypto.
~ Gijs
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
