I am trying to run the production secure source code of the latest version of trezor on a linux system SBC. I am trying to use my own build of Alpine Linux for this use case. I checked the emulator code of trezor firmware but there’s a lot of warning for not using it in production due to less security. What is the best way I can compile the original trezor firmware 2.X and then run it inside my own linux distribution with all the features it provides? Please a helping guide will be much appreciated.
You can’t compile your own original firmware. The original firmware is signed by SatoshiLabs and it checks if the signature is valid, so any other signature (or none) will fail and the firmware will stop.
If you want to set up your own communication with Trezor, the take a look at the Trezor Connect API.
That means if I compile from the opensource github code, it will still fail the check? I am using Pi bootloader btw. So, there’s no firmware checking on startup. I need to run the firmware first inside my Pi before connecting it to the trezor device. I just want to run the original firmware on my pi with all functionalities even if it needs me to not compile it and just use the firmware file provided by trezor itself.
The original firmware is included inside your Trezor when you buy it, so no need to recompile it. Why would you do that? When you start your Trezor it will check if there’s a newer version of the firmware and promt you if you need to update it.
There is no best way, or even good way. Trezor firmware is very much not designed for this mode of operation. A lot of the security hinges on features of the STM32 MCU powering the Trezor device, the fact that it is a standalone device separate from your PC, and the fact that there is no operating system and no possibility of “side-loading” things onto the Trezor.
This is pretty much what the “lot of warnings” are telling you.
If you want to run an air-gapped PC, instead of using the Trezor emulator, you should choose a good hot wallet application that is designed with this environment in mind.
There is a reason that I want to put trezor on my custom built OS distro and also I am aware of side-loading problems and other types of security problems that might occur from this. Why does it seem so hard to run the firmware on top of a linux distro? I just don’t understand the point of having an open source firmware on github if you guys do not have a better way to let that firmware run on other devices. The Trezor devices come with prebuilt binaries which are signed by you guys. So, there is no way to verify if the binaries you guys provide are the same as the source code available in Github other than some sort of decompilation. I have some of my own security features that I wanna implement without disclosing them in a forum on top of trezor firmware with a linux distro. That’s why looking for a way to just deploy the firmware from source that you guys provide in github on a linux machine.
Because you didn’t say it until just now? You must be specific if people are going to understand you.
About building your own Trezor from scratch, I don’t think that’s possible and I’d advice you not to pursue that path as it’s only going to make you headaches and lead nowhere.
I’m going to leave it at that and let @matejcik continue this discussion with you, if he wants to.
I am trying to run the production secure source code of the latest version of trezor on a linux system SBC. I am trying to use my own build of Alpine Linux for this use case. I checked the emulator code of trezor firmware but there’s a lot of warning for not using it in production due to less security. What is the best way I can compile the original trezor firmware 2.X and then run it inside my own linux distribution with all the features it provides? Please a helping guide will be much appreciated.
Thank you so much.
The above was my first message. I was very specific on my requirement. I think you better read what I asked properly before giving a solution to an unknown problem.
You might be well aware of problems that come with running a “hot” wallet on a Linux distro in general.
Unfortunately, running a device firmware, designed to run on bare metal chip with particular set of features, brings with it a completely separate set of issues.
Ultimately, the Trezor firmware is not an application that you can plop down into an operating system. It is a firmware for a hardware device.
There is the Trezor emulator, which is relatively easy to build and you are absolutely free to use it in lieu of the real thing. But there is no advantage to doing it that way, the emulator is not designed to be used “as if the real thing”, and there are additional security considerations which would not be an issue if you were to use an actual application designed to run in an actual operating system.
Firmwares are usually not designed to run on “other devices”, because a general property of a “firmware” is that it is closely tied to the hardware for which it is intended.
However, you can absolutely build a Trezor dev kit at home without buying the official Trezor device. Here is a webpage with some instructions: TREZOR Model T Dev Kit
You would need certain amount of hardware skills though.
This is actually completely untrue. You can build the image at home and verify that it is the same thing as the officially distributed one: Reproducible builds - Trezor Firmware
I completely understand what you are saying @matejcik Thanks a lot for your comprehensive reply. Really appreciate it.
So, may I know if it is possible to compile the trezor firmware and specific bootloader and flash it into a ARM Cortex-M0+ CPU(SAMD21G18) running at up to 48MHz + 256KB Flash + 32KB SRAM microcontroller board? And have all the features of Trezor Model T running inside this microcontroller?
How much total wallets can I store here including the fake wallets to prevent the wrench attack and how many gpg or ssh key pairs I can store in this kind of limited flash memory size you think?
Have you checked the pitrezor firmware which is build on top of yocto linux and kernel? As far as I can see, the trezor firmware is utilizing 2 buttons and one I2C display output for providing the functionalities in a microcontroller. What if the same Model T source code is compiled for aarch64 architecture and somehow just map the display and those 2 buttons from I2C to HDMI or an emulated screen onto the linux OS itself. I don’t see trezor using any other hardware features of the STM microcontroller but I might be wrong. Please correct me if I am wrong.
For the emulator, is it possible to just run the full fledged firmware using emulator exactly how it runs inside the STM microcontroller and just show the trezor firmware screen inside the emulator itself with all the high security features and crpyto methods that trezor model T firmware usually provides?
I am planning to add extra security features to my hardware wallets that trezor does not provide which requires me to add a linux distro to make those things happen.
This is unfortunately not nearly big enough for TT. A Bitcoin-only image is around 1 MB, the full thing is over 1.5 MB. You also need at least 128 kB of RAM, 196 kB is preferable.
The STM32F407 that is in TT runs at 168 MHz, but the speed isn’t an issue anywhere except FIDO, so in theory a slower chip would work just as well (albeit that much slower, of course).
Also if you go with anything other than STM, you would need to modify a bunch of drivers first (USB, RNG, display, input)
Infinite. You only need enough storage for the seed phrase (or 128bit secret in case of Shamir). Everything else is generated on the fly. There is no data stored on the device though, so the general workflow (for ssh/gpg) is ask the device for the public part of the key and then use it. You can’t put your existing keys on a Trezor like you would with, e.g., YubiKey.
This can be done, but you’d need to do essentially the same work that PiTrezor did, i.e., adapt the relevant drivers to the hardware. Unfortunately the Trezor One codebase is very different from Trezor T.
An important part is the USB interface. I don’t know what PiTrezor does on that front so I can’t say more about it.
Another important part is the hardware TRNG, but that’s just a matter of hooking it up to /dev/urandom or something.
Crypto methods, yes. The exact same cryptography runs in the emulator as on the real thing.
Security features, basically no. A lot of it is setting up the STM chip in just the right way – the emulator just dumps the storage file on your disk. It’s encrypted with your PIN, same as on the device, but that is easy to brute-force if you have the raw file. The PIN bad attempt counter is also completely ineffective when you can just copy over an old version of the storage file; wipe code doesn’t help you if an attacker can grab an un-wiped copy of the storage, etc.
What’s the difference between normal seed phrases and the 128bit secret (Shamir) as you say?
Is it possible to generate brand new edcsa key pairs just like we can do with puttygen with provided length and algorithms? In terms of ssh keys, the workflow I wanna use is to ask the trezor wallet to generate the key pairs with my provided algorithmic specifications and then authenticate my putty session everytime I wanna login to my server using ssh. Because in my server-side the server itself carries the publickey so I need the private key to authenticate my sessions.
PiTrezor is based on yocto but I want to run the whole thing inside my own distribution and own kernel build. Also, PiTrezor dont have Model T build. Really was looking for that Model T firmware with all the latest features.
So, if I install my linux distro and then run the Model T firmware using the provided emulator from trezor, will the emulated version have the same exact functionalities and every features available just like a Model T? If this can be done, then some guidelines and workaround can be made for patching the other security problems that comes with running the firmware emulated inside a linux distro. Just want to make sure all the features of Model T are available on the emulator and then we can discuss about the hardware related security problems and fix them as we go.
you might run into trouble: the Windows SSH agent has been dead for many years, I don’t think it’s currently working.
That is too bad then.
As I said before:
I am not sure what other answer you are hoping for here.
Software-wise, there is no magic piece of code that is hidden away in the official hardware.
But there are many thing that don’t make sense unless you are running in hardware.
First of all I would like to point out that it is you who will be fixing your problems
What you are doing is similar to bolting wheels on a sailboat and trying to run it on a road to save on fuel. It can work with enough effort, problems can be patched over. It is never going to be a better solution than (a) using an actual car or (b) running the sailboat on water. You are not getting the best of both worlds.
I can answer some technical questions but I will not be doing the security research and design for you.
I also strongly recommend you buy the real thing if you intend to store any significant amounts of money.
yeah I will fix the problems don’t worry. I will make it work with proper security inside the pi and will share the code if successful. I will store significant amount of money and I know how to secure the linux distro properly and the pi hardware in general. I will probably not share my own security methods but only the trezor firmware patched for RPI.
