The supply chain attacks/evil maid attacks are a much bigger issue, as pointed out in other comments.
As much as we'd like to believe this is the case, MITM (network or host) allows for replacement of destination addresses that show up on your screen. Redirected/malicious destination addresses showing up on your host screen will be cryptographically verified with Ledger's on-screen confirmation, but will not prevent you from sending your cryptoassets to the "wrong" endpoint.
I think this is much more of a reality if your host device is "heavily backdoored" than unencrypted HTTP, but could happen in either case. Another attack vector was BGP & DNS hijacking, which happened to My Ether Wallet in April 2018.
There are a couple caveats. First, the Ledger Nano's screen is too small to display the entire address at once, so an attacker who knows where you might send money could generate an address that appears that same on the characters that display. (The Ledger Blue shows the full address but is getting discontinued.)
Secondly, if you're on Ethereum and using a multisig contract, the destination address is just the contract and the ETH amount is zero. The function parameters which define your actual request are just displayed by the Ledger as a warning that they exist.
I've suggested to Ledger that they come up with a way to import the json.abi and display the actual parameters on device, which is what desktop clients do. They thought it was doable but I haven't seen any suggestion of it happening.
I'd be very interested to see that math, because it's unlikely that's accurate. You can get a few characters at the beginning of the address relatively easily -- the rest is in heat death of the universe territory.
Can you explain how's that a problem? The only thing you can do with a signed transaction is to either broadcast it or not.
As with MEW, as far as Ledger is concerned, a correct transaction is being signed and will in turn be broadcast. But the final outputs don't actually end up where the sender intended them to be sent because their host or network was compromised.
You cannot edit a transaction (for example by changing it's outputs) after it has been signed. That's how cryptographic signatures work, in general.
And the only way to cause an incorrect transaction to be signed on Ledger/Trezor is by tricking the user, which requires malicious code inside the device.
I completely agree with you that you cannot edit a transaction after it's been signed. I was trying to point out above that if the user is tricked, by signing a transaction they think is correct, but is in actuality not the intended destination because we assume the attacker controls what they are seeing, and where they are going.
Ledger signs transactions with a destination address. If the user can't tell (or is tricked) into believing a malicious address is the authentic one, everything will look koshor. This is similar to the level of sophistication and control required in the MEW incident. It's unlikely, but possible.
1. Install bad browser extension.
2. Visit coinbase.com.
3. Copy deposit address.
4. Paste into Ledger software.
5. Initiate transfer of funds to Coinbase.
6. Scrutinize transaction details.
Your funds are now gone, and you'll never see them again.
All cryptography worked as designed in this case. "That's how cryptographic signatures work, in general."
Substitute scenarios with receive addresses triple-notarized with medallion guarantees imprinted in blood if you wish for steps 1-3. It doesn't matter. The deputy is confused.
But also it's independent of the discussion around whether NFC or Bluetooth is a better choice for host <-> device comms.
PS. I love the term "violent agreement".
Except for that time when the attacker finds a way to bypass the on-screen confirmation process and make the changes hidden to you, of course, which has happened like only a thousand times on Windows.
I will eat my paper wallets if my meagre holdings are stolen from me like that.
One caveat is that laptops are commonly compromised and your security would depend on nobody stealing keys/passwords needed to access your database/password manager/whatever.
Having hardware token with paper backup, makes this harder. Having a lot of tokens creates a huge incentive for getting hacked.
If you have non trivial amounts of tokens under your control, you need to consider all the points of failure. Laptops get compromised in all sorts of ways and can be equipped with key loggers or worse. Unless you are a security expert, defending against a determined & skilled hacker is super hard. Most of us never get our setups audited by an expert and I'm afraid that a bog standard OS X/linux setup is probably only get you so far. Even if you turn on disk encryption and do all the rest of the things you are supposed to do.
So the advantage of a token is that it does not depend on your laptop being uncompromised and that it is a third party solution that can be scrutinized and audited. That being said, I'm not a big fan of having a proprietary software/hardware package and would prefer to trade in my ledger for a properly OSS platform. There are a few of these platforms but it is early days and I'd need it to support Stellar though. As far as I know, ledger is the only thing working with that. I own a few of those for this reason.
IMHO there's a big market opportunity for creating a secure, easy to use hardware token for ubikey/oauthn signins, managing blockchain wallets, and doing 2fa. Not impossible, but making open hardware/software platforms commercially is apparently still a big challenge. I'd buy several if the price and feature set were right . Assuming enough auditing/vetting has happened by people that are smarter than me, of course.
Maybe the ease of use isn't quite where it could be.
Also the Nano does some of that but doesn't work with e.g. Firefox. I have to use Chrome to be able to do anything with it.
An on-chain contract holds your funds and requires some number of signatures to authorize transactions (for personal use usually 2, i.e. one from your desktop computer and one from your phone). That way at least you know two separate devices would have to be compromised to cause loss of funds. This also allows for interesting key recovery strategies like having a third paper wallet that is also authorized. You could use that as a backup key that would allow authorization of a new key if your phone were stolen, etc.
Very narrow attack surface (no USB or Bluetooth, only QR codes are used for communication), and more safety against the supply chain attacks make it a viable alternative for some particular threat models.
That being said - there's virtually no privacy in most cryptocurrencies. Your Bitcoin/Ethereum/Ripple/... balance is fully public.
I switched to a more open source solution for the hardware, and for mobile mycelium.
Ledger can suck a fat one.