Good to see Bluetooth in the new hardware. Lack of real mobile support for hardware wallets has been by far the biggest pain point for me. (With regard to the best possible physical security, I would have preferred NFC over Bluetooth, but the latter is alright for everyday use.)
AFAIK given the Ledger's on-screen confirmation process it really doesn't matter what's the medium of communication between the host machine and the device. It could as well be sent via unencrypted http routed through China, then Russia and then an NSA server all while your host device is heavily backdoored.
The supply chain attacks/evil maid attacks are a much bigger issue, as pointed out in other comments.
>>It could as well be sent via unencrypted http routed through China, then Russia and then an NSA server all while your host device is heavily backdoored.
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[1][2].
Yes but the Ledger has its own screen that shows what you're actually signing. If you verify that, you're good.
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.
Just for the record, the entire address for the transaction is displayed on the screen, it just scrolls side to side. Generating another address that's similar enough to be confused easily would be prohibitively difficult at best.
Yes but the middle scrolls by pretty quickly. I once saw an article that did the math on the difficulty of making an address that matched on the easy-to-read parts of the address at beginning and end, and it amounted to less than a day's work on a modern PC. That's likely to work against most users.
It doesn't scroll quickly, it's very easy to read and verify, even for my beat up eyes.
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.
I'm treating network & host attacks as a supply chain attack where the authentic/intended destination address is replaced by the attacker with the attacker's address. Hence my air quotes around the word "wrong".
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.
Yeah this is plain wrong. Sorry but you simply don't understand how transactions work in cryptocurrencies.
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.
We're in "violent agreement". You seem to be missing my point.
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.
You're not listening. This is the case that otoburb is describing:
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.
7. Approve.
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.
I'll reply here to the three comments: I admit that you're right guys. I have to concede my point about backdoors. If you modify user's view of Coinbase DOM then no security in the Ledger/Trezor is going to help with that.
But also it's independent of the discussion around whether NFC or Bluetooth is a better choice for host <-> device comms.
Technically, only copy-paste mutations are not enough as you confirm addresses on the screen. But, for example, DOM edits from a malicious extension are enough.
> AFAIK given the Ledger's on-screen confirmation process it really doesn't matter what's the medium of communication
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.
