Hi everyone 
So long story short, I’ve got my trezor one not so long ago. I was wandering around in the source code of the firmware and I realized that many of the algorithms needed for new coins (Solana, TRX, etc…) are just there. Like ed25519 and Base58. But currently the firmware aims at decoding and understanding all data from all the coins. Is this a good idea to add new functions which interact directly with these algorithms to potentially support every coin without needing to update the firmware. Like with generic get_address(curve, hash, encoding) and sign_hash(curve, hash) functions exposed from the trezor?
I don’t know about the security measures of this approach but I would like to know if it’s a good idea or not in general?
Cheers
You can’t build a generic get_address, because the address encoding is different between blockchains, and most of those are very custom (so your encoding parameter wouldn’t work).
What you can do is extract the appropriate public keys. This is pretty much already in Trezor: you can call GetPublicKey with any path and any curve specified, this gives you the public keys, and you can encode them to the appropriate format on your PC.
Having a generic sign_hash is cosmically bad idea.
I’ll write the following malware for your wallet:
- whenever the user click “Sign on Trezor”, I will replace the hash to be signed with a hash of a tx that sends all funds to my (malware owner) address. Because Trezor doesn’t know which coin you’re spending, I’ll just pick whichever coin I like – so if your savings are in Bitcoin, and you want to send some Ethereum, I’ll just generate a Bitcoin transaction and send it to Trezor to sign.
- Trezor shows you a transaction hash to confirm. The malware will replace this hash both on your PC screen and in what’s shown on Trezor. You will check that the PC is showing the same thing as Trezor, and click Yes
- now your Bitcoin savings are mine
- ???
- PROFIT
1 Like
Dear @matejcik,
First of all, Thank you for your comprehensive explanation.
The PublicKey part completeley makes sense. I have already tried it with trezorctl and it works perfect.
About the sign_hash:
The BIP-32 path can be limited to the unknown coins. With this we can prevent cross sign hash signing so the things that trezor already knows how to handle won’t be affected. But still your concern is valid about those other unsupported coins. And before user continues, he/she can be warned on the trezor that “this transaction is not trusted, Confirm at your own risk”.
The other thing is some coins like Solana, have transactions cannot be (easily) interpreted on the trezor device so in the end users have to trust the wallet they are using not to forge a transaction.
What do you think?
This would be reasonable, if the goal was “do this inherently unsafe thing as safely as possible.” But in the end, it’s only marginally better than not doing the inherently unsafe thing and just keeping your funds in a hot wallet. (The main difference being, with a hot wallet, a malware can steal your seed and drain your funds at any time, while with the “authentication token”, it must wait until you want to make a legitimate transaction.)
Also, what I didn’t realize at first, the problem actually starts at the address side. If Trezor itself is incapable of correctly encoding the address, you can’t display it on screen for confirmation. Malware can easily attack this step and just give out fake receiving addresses controlled by the attacker.
This can even be sophisticated in that you think you are using Trezor, the right confirmation screens pop up at the right time, etc., but in fact the account is under full control of the attacker the whole time and they can drain it the moment you reach a balance threshold.
So at that point, it would be difficult to claim that Trezor is anywhere near “securely handling your coins”. A much more secure solution is to get an old Android phone, install a nice hot wallet on it, turn on Airplane mode and transfer to and from the main PC via QR codes or Bluetooth or something like that.
1 Like
Trezor is designed so that you don’t actually submit a transaction to be parsed. Instead, you submit metadata (amounts, destinations, etc.) that Trezor uses to construct the transaction internally.
So basic HODLing support (receive + simple send) can pretty much always be implemented.
1 Like
This makes complete sense. I guess this option may only be useful for developers but looks more like a smart card approach.
The sad thing about trezor to me was the firmware doesn’t support solana, tron and nano and I understand adding more coins without adapting them in suite is not practical. I was thinking of maybe using this approach we can have early access for people with enough technical knowledge but again if they want, they can make their own firmware.
I actually wanted to implement and test this on a trezor one but I don’t want to R&D on mine 
Thanks again @matejcik
You are really helpful 
1 Like