Topic: [ESHOP launched] Trezor: Bitcoin hardware wallet - page 234. (Read 966173 times)

Yes if your phone supports USB OTG (aka USB host).

Just put in a pre-order; it looks great and I'm excited to see how people use it!

Would one be able to use a Trezor to sign transactions from an android phone, with a two-sided microUSB cable?

I believe the PINs are one time use only. The reason it's not entered on the Trezor is that it only has two buttons.

edit... Whoops, I was confusing the PIN with the OTP. Still... 2 buttons = annoying to type a decimal PIN.

I'd say because it'd be pretty much annoying to enter a PIN code on a device with 2 buttons and it doesn't provide more security to enter the PIN on the device itself here, as an attacker still has to steal the device to use the PIN code he collected from a compromised computer

Unfortunately the speech does nothing to alleviate my concerns. In fact, it is what triggered them in the first place. Antonin merely demonstrates that the PIN code is entered on the computer, claiming it is a safety measure in case the device gets stolen. The scenario I mentioned is not discussed in the presentation.


That does not explain why the PIN code is not entered on the Trezor itself, as suggested in my original post.

I recommend watching this speech from Bitcoin 2013 conference https://www.youtube.com/watch?v=3t18a-wXBnw
The guy explains the Trezor and shows how the PIN code works and why it's there.

You make a new one with the seed you wrote down.

What happens if you lose it?

I'm confused as to why the PIN code is entered into the wallet application, rather than the device itself - surely that increases the risk of a successful physical theft. Assuming the PIN code is not changed on a regular basis, using the device on an infected workstation would essentially render the PIN code useless if attacked through a combination of both digital and physical means. On the other hand, if the code was to be entered on the Trezor itself, such a scenario is not possible unless the PIN code is provided by the owner under duress.

You're confusing bitcoin keys with the certificate and key used for the address verification protocol. They are not the same. You'd still generate the bitcoin seed yourself.

The payment protocol was designed with Trezor in mind - it embeds the X.509 chain into the payment request itself. The host device streams the entire request to the device which can then verify all the signatures itself.


Obviously in a world in which exchanges sell Trezor's, you would not be able to withdraw to any address you want. It'd have to be a Trezor address.

You can still generate your own private key. All that is required is that the Trezor has its own certificate signed by the manufacturer, and that this cert chain was snapshotted by the exchange prior to shipping. You can generate or provide your own seed after receiving it, no problem. When the Trezor takes part in the reverse payment protocol it simply provides its certificate chain proving that it contains the private key for the address in question.

I'm sure that currently you don't have such problems. Currently we don't seem to have problems with local encrypted wallets getting stolen either, even though we've known since the feature was first shipped that all it does is raise the bar. But we will have these problems sooner or later. As the amount of money in the Bitcoin community gets higher and higher, even 2-factor authentication as practiced today won't be sufficient. We know this without a doubt because banks already experience such attacks on a routine basis.

Trezor and the payment protocol are long term, high-difficulty projects that the community is putting in place because we know what's coming.

I'd hope for Trezor to spit out the signed raw transaction, without the computer automatically publishing it, so you can decoderawtransaction just to make sure. Of course the software would display it in a very user-friendly way, so the grandmas wouldn't have to actually use the debug console / bitcoind.

But then this is a non issue since he can already withdraw to any address he wishes. I mean if that's the case I don't even understand what threat we are talking about anymore. In case you didn't notice, I work for an exchange and we don't have problems with people getting their Bitcoin addresses swapped right under their noses, we do have a problem when occasionally users get their account access information compromised and an attacker logs into their account robbing them, something 2FA and now email confirmation deal with very effectively.


Anyway.. I would never ever buy and use a hardware wallet for which the seed wasn't generated by me. Period.

Well you go ahead and offer your solution, I don't accept it because I do not want you or anyone else to know my private key.

The virus can just put itself in the middle of the communication. It sends the attacker's key to the exchange, but display your own to you.

If the exchange uses a second channel (like SMS) to confirm the public key, then perhaps it might work safely enough, as we can consider it unlikely for the attacker to control both channels.


We're always assuming the user's system is under control of an attacker, so yeah, the attacker is in control of your account in the exchange as well.

I hadn't considered this aspect of using the Trezor in such a way. I agree that it makes this use case pretty unlikely to occur. Though people happily hand their credit cards over to total strangers, giving them all the information they would need to empty their checking accounts...

In order to get the full benefits of the (normal) payment protocol, does the Trezor itself need to understand it, or can the host computer (even possibly infected) do so an reliably pass the payment information to the Trezor? I'm thinking it wouldn't be useful to the Trezor since it can't independently grab and verify the X509 certificate. Is that correct?

Remember that the threat model here is a compromised computer. So how do you tell the exchange your public key? Through their website? Not going to work. Phone them up and read it out over the phone? Could work, but hardly user friendly.

The simplest way is to just order the hardware from the exchange company itself. This is good for everyone - the exchange gets a new way to make a bit of money, TREZOR gets free advertising and a new source of orders, users are made aware of the availability of the security hardware and have a one-click purchasing option that automatically sets up their exchange account with the correct public key.

Hence - reverse payment protocol, which is what Chris suggested.

Neoranga, the device shows you the fee, I believe. There's some stuff in the protocol so it can calculate that. The device won't sign the transaction if the change address doesn't belong to itself.

The real risk is of course that the address you see in your web browser and on the device are identical, but not actually owned by the person/company you think you're paying (they were both substituted by a virus). That's what the payment protocol is for.

I think, and hope that Trezor would display all inputs and all outputs

I have a doubt about the construction of the operation and confirming the information on the Trezor.
The images and videos I saw so far show that Trezor displays the address you send money to and the amount you send, but there are several things in that transaction that a malicious client (modified by an attacker) can modify and I need to review in the Trezor in order to accept the transaction.

My doubt is, how do I know when signing on the Trezor that the fee is not incredibly high or the change address is not mine (attacker redirecting the founds to another address)?