1. 3

  2. 3

    I don’t think the MitM vector is clearly described on the article (or the blogpost it links to for that matter). Anyone care to elaborate why is this MitM-able?

    1. 2

      From reading the article this is better described not as MitM but as reducing the security of a popular workflow back to the level equivalent to software wallets. Although I could probably find a way to explain why it is in some sense MitM.

      The idea of hardware wallet is partially that the limitated protocols it uses make it very hard to attack; so the abilities of a worm which runs under your user account on your desktop to manipulate your payments is removed, unless it finds a vulnerability in a narrow-scope software.

      In this case, one of the workflows includes doing something in Javascript on the desktop side, while the verification on the token side is optional. This means that there is a workflow where manipulating your browser is enough to trick you into making a different payment than you expected.

      1. 2

        That I could understand, but (in my very humble opinion) that sounded more like a CSRF-like vulnerability rather than MitM. Either way, that’s just semantics :)

        1. 2

          It just depends on what you would call end-to-end. I think the idea of calling it MitM is that you don’t trust your desktop and want to trust only the hardware wallet. You still use your desktop for a part of communication, because of convenience and network connection and stuff like that. Turns out, a program taking over the desktop can take over a part of the process that should have been unmodifiable without infiltrating the hardware wallet.

          So MitM is the desktop being able to spoof too much when used to facilitate interaction between you, hardware token and the global blockchain.