How can you verify the firmware's source code?

[BlackHatCoiner]

This is a question that's scrambled my head lately. I know how to use the search engine, the thing is none of those results gives a proper answer.

When a software is open-source, it means you can download the source code, the necessary libraries and a compiler. That's enough to build the executable and verify yourself that what you're using is what it's saying. So, how can you build a firmware using a source code? How can you verify that it doesn't generate predictable entropy or that it's malicious in another way?

[1714745059]

1714745059

[1714745059]

1714745059

[dkbit98]

When a software is open-source, it means you can download the source code, the necessary libraries and a compiler. That's enough to build the executable and verify yourself that what you're using is what it's saying. So, how can you build a firmware using a source code? How can you verify that it doesn't generate predictable entropy or that it's malicious in another way?

This can be done for all publicly released codes, even if they are not open source, like in the case of newer ColdCard wallets.
You can build it by following instructions posted by wallet developers, and it's not exactly the same process for all wallets.
Instead of doing this for yourself you could also use websites like walletscrutiny.com or bitcoinbinary.org that are doing this work for you.
Note that in some cases it happens that new version of wallets can't be verified, so you would have to do this check with every new release.

[n0nce]

The basic idea is to compile it yourself from source code and comparing the hash of what you compiled to the hash of the signed firmware file that they publish on their webpage. I believe the way they get the signatures to match without you knowing the signing key varies from brand to brand.

It's also worth mentioning that some devices like the Foundation Passport allow you to 'unlock' the device and upload your own build (without their signature on it). The device will then always show a warning message on startup, but I can see how some people would prefer to not only verify the firmware the vendor provides, but actually to run the firmware they themselves compiled.

[BlackHatCoiner]

I want to focus into this:

How can you verify that it doesn't generate predictable entropy or that it's malicious in another way?

Sure, you can verify that once you build the source code, it's the same executable as the one that's signed, but how can you verify that the functions that are used to generate entropy aren't executed improperly, outside the firmware? Excuse me for my complete lack of hardware knowledge, but isn't there a part of it that is used exclusively for producing randomness?

Generally, aren't there parts that are used along with the firmware to make it work?

[Pmalek]

I only did a quick search For Trezor's firmware and found this GitHub page of the full history of all the released firmware. Maybe what you are looking for can be found there. 
https://github.com/trezor/webwallet-data/tree/master/firmware/1

Hashes and fingerprints can be found here:
https://github.com/trezor/webwallet-data/blob/master/firmware/1/releases.json

[PawGo]

So, how can you build a firmware using a source code? How can you verify that it doesn't generate predictable entropy or that it's malicious in another way?

I am not sure if I understand you correctly, but in my opinion you ask 2 different questions:
1) technical problem - to build code you would probably need some documentation from the code authors, description how to do it, how to sign it, load into device etc. Trezor has a quite good documentation about that, they describe what you may do with a device with "non-original" firmware etc.
2) logical problem - here the problem is more complicated, because as I understand it requires the knowledge about all the touched aspects. Personally I think I would not be able to answer the question if entropy is predictable or not, if result is "good enough" etc. But on the other hand, I think it would be quite obvious or at least "visible" for someone with programming experience to find that there is a try to influent the result. Every part which has impact on seed, random number generation etc. could be suspected.
And of course the other issue is if the whole code is written "in house" or if it depends on external libraries, which audit could be even more complicated.

[BlackHatCoiner]

logical problem - here the problem is more complicated, because as I understand it requires the knowledge about all the touched aspects.

Forget the logical problem. I'll open a thread in the proper board about it.

Thanks for your answers!

[n0nce]

I want to focus into this:

How can you verify that it doesn't generate predictable entropy or that it's malicious in another way?

Sure, you can verify that once you build the source code, it's the same executable as the one that's signed, but how can you verify that the functions that are used to generate entropy aren't executed improperly, outside the firmware? Excuse me for my complete lack of hardware knowledge, but isn't there a part of it that is used exclusively for producing randomness?

Generally, aren't there parts that are used along with the firmware to make it work?

You're right; we have to verify the code is good (no backdoors etc.), but there are also 'parts used along the firmware' - the secure element hardware, indeed. This one is not reprogrammed and the firmware just interfaces with it, similar to an API. If that element is used as a randomness source and the randomness is bad / has weak entropy / has a backdoor, ..., then it could be an attack vector.
That's why it would be huge if Trezor really follows through with that open-source secure chip they are teasing. I'm not sure how you verify that what's in the silicon matches the (open sourced) spec sheet, though. For maximum paranoia, it would at least allow you to have the chip manufactured and build the device yourself. I believe someone already tried to build a Trezor from scratch using all the open-source hardware information.

Of course, you can also (depending on hardware wallet feature set) use your own entropy, like dice rolls and use that to generate the seed, then you don't have to trust the chip to have good entropy at all.

[BlackHatCoiner]

For maximum paranoia, it would at least allow you to have the chip manufactured and build the device yourself.

But, I don't think that's as paranoid as it sounds. It's a reasonable question a newbie, who's interested in learning more, may ask. Like "So, how do I know that the hardware is what they're telling me it is?". That's what I thought when I found out there are such wallets.

I don't want to do this with a dice; and while I had tried it wasn't as simple as it looked like. I want to ensure that the chip Trezor uses (or any other I will deliver) isn't working maliciously. Is there a way to do that?

[Pmalek]

I want to ensure that the chip Trezor uses (or any other I will deliver) isn't working maliciously. Is there a way to do that?

I don't think you can. Chips and secure elements in hardware wallets are closed-source. That would mean that any code and firmware they use isn't posted publicly because companies are required to sign NDAs forcing them to keep the information private. Even if there are vulnerabilities in these chips, hardware wallet manufacturers aren't allowed to talk about it. All that could change if Trezor and Tropic Square manage to create an open-source chip.     

[n0nce]

I don't want to do this with a dice; and while I had tried it wasn't as simple as it looked like. I want to ensure that the chip Trezor uses (or any other I will deliver) isn't working maliciously. Is there a way to do that?

It's not really possible, and the exact reason why there's an interesting discrepancy between recommendations on Twitter and recommendations on Bitcointalk (by people who know what they're talking about). While on the former, many big names tell you to buy a hardware wallet for larger amounts, here I often hear that for larger amounts it's better to generate an offline wallet with Tails. The reason is that 'original Bitcoiners' think of 'larger amounts' a bit differently than Twitter users that heard of Bitcoin the first time in 2020.

I personally still often do recommend (open source!!) hardware wallets, even if the secure elements are closed source, since they are very practical to use (and I'm a big 'using Bitcoin' advocate). The risk of secure elements actually being insecure (oversimplification for sake of brevity) is rather small in my personal opinion. However, even as a little bit of a hardware wallet fan, I don't do and don't recommend storing life-changing amounts on a device (or software stack like Linux + Bitcoin Core + Electrum) which is not fully open and verifiable.

[dkbit98]

I personally still often do recommend (open source!!) hardware wallets, even if the secure elements are closed source, since they are very practical to use (and I'm a big 'using Bitcoin' advocate).

I just want to clarify here that some secure elements like ATECC608 have Open Source hardware certifications since September 2020, and that is why it is possible to reproduce code for some hardware wallets like Passport.
Note that this doesn't mean there is no NDA signed between microchip manufacturer and hardware wallet manufacturer, but it is still much better than what other chips are doing.
Design of hardware is Open Source and here is one example of this chip being used by CERN with GPL license and documentation with datasheet is clearly available:
https://github.com/ElectronicCats/ATECC608A-Croquette

Passport hardware wallet is listed and certified by OSHWA UID US002005 in open source hardware association website:
https://certification.oshwa.org/us002005.html

EDIT:
Trezor is certified as well:
https://certification.oshwa.org/cz000005.html

[JL0]

I personally still often do recommend (open source!!) hardware wallets, even if the secure elements are closed source, since they are very practical to use (and I'm a big 'using Bitcoin' advocate).

I just want to clarify here that some secure elements like ATECC608 have Open Source hardware certifications since September 2020, and that is why it is possible to reproduce code for some hardware wallets like Passport.
Note that this doesn't mean there is no NDA signed between microchip manufacturer and hardware wallet manufacturer, but it is still much better than what other chips are doing.
Design of hardware is Open Source and here is one example of this chip being used by CERN with GPL license and documentation with datasheet is clearly available:
https://github.com/ElectronicCats/ATECC608A-Croquette

Passport hardware wallet is listed and certified by OSHWA UID US002005 in open source hardware association website:
https://certification.oshwa.org/us002005.html

EDIT:
Trezor is certified as well:
https://certification.oshwa.org/cz000005.html

What about the ATECC608B?

[dkbit98]

What about the ATECC608B?

It's almost the same secure element as ATECC608 version A, so the same thing would apply to version B, and they are nearly identical.
Only difference are some smaller improvements, security enhancements and bug fixes that prevent data corruption or issues with temperature and device identity.
Non of this issue ever affected any hardware wallets as far as I know.

- Low-Frequency I²C Issue fixed (that can cause data corruption and device responding incorrectly under)
- Device Revision Differences (package marking on Microchip security devices does not identify the device type)
- Execution Time Differences (after implementing new security enhancements)
- Enhanced Temperature Range (extended range of -40°C to +100°C)
- New Packages (3-pin RBH contact package)

https://ww1.microchip.com/downloads/en/Appnotes/Migrating-from-the-ATECC608A-to-the-ATECC608B-DS40002237A.pdf